Hi! > Let's say your app validate user written/chosen "Date" on client side by > JavaScript. Then browser must send whatever "Date" format you impose > to client. It may be "YYYYMMDD", for example.
I'm not sure what Javascript has to do with it. Many apps don't have any client-side and have little to do with Javascript. Assuming that whole world is browser applications running Javascript (controlled by you) would be a big mistake. > Then programer should not accept "Date" format other than "YYYYMMDD" > because other format is invalid. Accepting format other than "YYYYMMDD" > does only bad and increase risks of program malfunctioning. i.e. All kinds > of injections like JavaScript, SQL, Null char, Newline, etc. What you mean by "accept" here? I think you are under impression (please correct me if I'm wrong) that there are only two ways for application to work - either treating all inputs equally, or bailing out immediately when incorrect input is detected. However, this is not the case, there are many other ways for application to handle the situation of invalid input - while knowing it is invalid - and exact manner of this handling is application-dependent. > "Input validation" should reject all of them and does not have to inform users > (attackers) to "there is invalid input". If you need to tell legitimate users I think we disagree here. I think not doing this makes my work as a developer much much harder. > "There is invalid input", then it should be treated by "Business logic", not > by > "Input validation". Wait, input validation happens before business logic has a chance to run, so if input validation bails, how business logic can treat anything? > "User name" and "Password" shouldn't have CNTRL chars or invalid char > encoding. Even when fields are plain <input>, there shouldn't be 500 chars > long inputs for them. So your proposal seems to be having two input checking procedures instead of one. I don't think people would find it very useful to have two separate input checking procedures. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
