Also the server side validations reveal max/min lengths, there. Currently, the validator server sideIt is inherently insecure to reveal the specific details of password validation in client side scripting. Validator and Struts should be as secure as possible out of the box so I am -1 on this change. Please revert the changes until we come up with a better solution. Bugzilla isn't the easiest place to have this discussion so it might be better suited for commons-dev.
I thought that the length was only revealed in the error message but it is indeed shown in snippets like: this.maxlength='4'; this.minlength='4';
I agree that the best solution at the moment is not to use validator on password forms.
David
validations are loosely coupled. A solution would be to prevent the user from using max/min length
checks either client or server side would increase coupling. One possible attempt to solve this
by placing an optional attribute for the user to tell us that the field is
a password so we could disallow maxlength or minlength would not work because they would just
not mark the field as a 'password'.
A proactive step might be to have the generated javascript create a dialog if the field is a
'password' field and it attempts to validate a max/minlength constraint. It would warn them that
validating max/min fields is discouraged. A client side validation would be allowed by setting parameter
in the <html:javascript> tag. This would catch both client side and server side cases, given that javascript
is enabled.
Generally though I believe it would be cleanest if the commons-validator didn't dictate what field types
could/could not be validated. This decision could be left up to the enclosing framework, as I described
above.
--- [EMAIL PROTECTED] wrote:
rleland 2003/10/06 20:00:15jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
Modified: validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Log:
Bug#: 12473
Let max/min length also cover passwords fields.
If users don't want the password min/max parameters
revealed then they shouldn't use the validator.
Currently in struts the min/max values are still
in the html, anyway. There is no easy/clean workaround.
Just don't use validator.
Revision Changes Path
1.3 +4 -3
Index: validateMaxLength.js/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
===================================================================
RCS file:
retrieving revision 1.2jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- validateMaxLength.js 15 Aug 2003 20:22:03 -0000 1.2
+++ validateMaxLength.js 7 Oct 2003 03:00:15 -0000 1.3
@@ -13,6 +13,7 @@
var field = form[oMaxLength[x][0]];
if (field.type == 'text' ||
+ field.type == 'password' ||
field.type == 'textarea') {
var iMax = parseInt(oMaxLength[x][2]("maxlength"));
1.4 +4 -3
Index: validateMinLength.js/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
===================================================================
RCS file:
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- validateMinLength.js 15 Aug 2003 20:22:03 -0000 1.3
+++ validateMinLength.js 7 Oct 2003 03:00:15 -0000 1.4
@@ -13,6 +13,7 @@
var field = form[oMinLength[x][0]];
if (field.type == 'text' ||
+ field.type == 'password' ||
field.type == 'textarea') {
var iMin = parseInt(oMinLength[x][2]("minlength"));
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
