DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12473>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12473 password fields are not validated using javscript (lengths) [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2003-10-06 20:45 ------- Martin, While I understand your concern on revealing field length validation requirements on password fields on the client, I disagree with the decision to have the Struts Validator skip this validation altogether on the client for the following reasons: 1) The server side validation validates lengths on password fields and generates errors (which would most likely reveal the length requirements). Having the client side alone skip it is not consistent behavior (client side validation is no longer an accurate duplication of server side requirements). A hacker has to post only once with empty password fields to find out the length requirements. 2) A simple View Source of the rendered page lists all the server side requirements for password field lengths (look at the maxlength and minlength JavaScript functions). In other words, even though the JavaScript does not perform the length validation on the client side, the page source reveals all the requirements anyway. Hence, nothing is gained by not performing the client side checks. 3) Many websites list the length requirements for user ID and password on the page itself for the benefit of the users (in addition to other requirements such as certain characters are not allowed etc). I believe that this is a legitimate use (how else do you tell users what the field length should be and what the unique requirements are?). The Struts Validator pre-empts this approach. I think the decision not to enforce password lengths on the client should be left to the development team. Struts should not unilaterally make this decision for them but should facilitate this approach, if possible. A good example of taking this approach lies in the html:password tag, which contains a redisplay attribute. If a development team decides that passwords should not be sent back to the browser in clear text (on validation errors), then they can set this attribute to false. Otherwise, they can leave it at true. It would be better IMHO to have a similar functionality in the Struts Validator – provide a way to do client side length checks on the password fields (default) and a way to turn it off. If the latter approach is not possible, I would recommend turning "on" the client side length checks for password fields by default. Giri --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
