Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 29550 invoked from network); 14 Jan 2005 13:57:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 14 Jan 2005 13:57:12 -0000 Received: (qmail 9956 invoked by uid 500); 14 Jan 2005 13:57:03 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 9935 invoked by uid 500); 14 Jan 2005 13:57:03 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 9919 invoked by uid 99); 14 Jan 2005 13:57:02 -0000 X-ASF-Spam-Status: No, hits=1.8 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from relais.videotron.ca (HELO relais.videotron.ca) (24.201.245.36) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 14 Jan 2005 05:57:01 -0800 Received: from [192.168.123.100] ([24.201.92.44]) by VL-MO-MR010.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IAB0053T810AW@VL-MO-MR010.ip.videotron.ca> for commons-user@jakarta.apache.org; Fri, 14 Jan 2005 08:55:48 -0500 (EST) Date: Fri, 14 Jan 2005 08:54:57 -0500 From: Eric Giguere Subject: Re: [commons-validator] Problems with Javascript mask validation..plz Help! In-reply-to: <064d01c4f9e0$28d00b10$0200a8c0@DELL1800> To: Jakarta Commons Users List Message-id: <41E7CF31.6050805@videotron.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) References: <20050113203550.46720.qmail@web50405.mail.yahoo.com> <064d01c4f9e0$28d00b10$0200a8c0@DELL1800> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi guys. Very good point. So, with all this, I guess there is now no way to define validation rules for a form but disabling the javascript side only for a single field (like the password in this case). Like Niall said, there is no way the engine could know that the Javascript should not be rendered for a particuliar field, unless it is specified in the XML. Anyway update planned in this area? Thx for the help. Really appreciate it. Eric. Niall Pemberton wrote: >That sounds fine in theory, but I can't see how we could actually implement >that in reality. When the validation javascript is being rendered there is >no knowledge of whether the associated form field is a "password" type or >not and just having the actual validators ignoring password fields isn't >"shipping with secure best practice" if all the rules (min/max lengths, >regular expressions etc) are still rendered in the javascript. > >Niall > >----- Original Message ----- >From: "David Graham" >To: "Jakarta Commons Users List" >Sent: Thursday, January 13, 2005 8:35 PM >Subject: Re: [commons-validator] Problems with Javascript mask >validation..plz Help! > > > > >>Even though you tell the user the password rules they still shouldn't be >>able to see the details of how you're validating the password. I believe >>validator should ship with the secure best practices implemented by >>default and make the user enable/disable as they want. >> >>David >> >>--- Niall Pemberton wrote: >> >> >> >>>Even though the current javascript mask validator ignores password >>>fields >>>the validation algorithm is still revealed since (in Struts) the >>>javascript >>>to call that validator with the appropriate regexp is still generated. >>> >>>I also think that we shouldn't restrict what validation can be specified >>>since whats a "good idea" to do (or not do) depends on the situation: >>> >>>1) For "logon forms" I agree as little information as possible should be >>>given and I would recommend that only two validation checks are made - >>>a) a >>>password must be entered (i.e. required) and b) the password entered >>>must >>>match that stored against the user. >>> >>>2) For creating/changing a password its a different matter, since if >>>there >>>are rules such as minimum/maximum lengths or a particular regexp >>>validation >>>algorithm - then the user needs to be told what the rules are if they >>>enter >>>an invalid password and I don't see a problem with having javascript >>>validations for this. >>> >>>IMO we should remove any restrictions on password validations and just >>>provide some "best practice" advice. >>> >>>Niall >>> >>>----- Original Message ----- >>>From: "David Graham" >>>To: "Jakarta Commons Users List" >>>Sent: Wednesday, January 12, 2005 8:56 PM >>>Subject: Re: [commons-validator] Problems with Javascript mask >>>validation..plz Help! >>> >>> >>> >>> >>>>Revealing detailed validation algorithms for passwords on the client >>>> >>>> >>>is a >>> >>> >>>>security issue so validator does not allow it by default. Also, you >>>>should be able to replace [a-zA-Z_0-9] with \w. >>>> >>>>David >>>> >>>>--- Matt Bathje wrote: >>>> >>>> >>>> >>>>>Eric Giguere wrote: >>>>> >>>>> >>>>>>Hi all >>>>>>I have a problemes with the commons-validator 1.1.3 javascript >>>>>>implementation for validating masks. >>>>>>I tried to validate user name and password on a form. >>>>>> >>>>>>For testing purposes, I've set both fields with the same regexp in >>>>>> >>>>>> >>>the >>> >>> >>>>>>validation.xml file: >>>>>>^[a-zA-Z_0-9][a-zA-Z_0-9!^$&%]{5,14}$ >>>>>>The username get validated ok but not the password. It is >>>>>> >>>>>> >>>possible? Is >>> >>> >>>>>>the fact that the control shows **** as data (password field) >>>>>> >>>>>> >>>breaks >>> >>> >>>>>the >>>>> >>>>> >>>>>>validation? >>>>>> >>>>>> >>>>>> >>>>>The javascript side of the mask validation only works on fields with >>>>>type hidden, text, textarea or file. >>>>> >>>>> >>>>>Matt >>>>> >>>>> >>>>> >>>>> >>>--------------------------------------------------------------------- >>> >>> >>>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >>>>>For additional commands, e-mail: >>>>> >>>>> >>>commons-user-help@jakarta.apache.org >>> >>> >>>>> >>>>> >>>>__________________________________________________ >>>>Do You Yahoo!? >>>>Tired of spam? Yahoo! Mail has the best spam protection around >>>>http://mail.yahoo.com >>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >>>>For additional commands, e-mail: commons-user-help@jakarta.apache.org >>>> >>>> >>>> >>>> >>>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >>>For additional commands, e-mail: commons-user-help@jakarta.apache.org >>> >>> >>> >>> >> >> >>__________________________________ >>Do you Yahoo!? >>Meet the all-new My Yahoo! - Try it today! >>http://my.yahoo.com >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >>For additional commands, e-mail: commons-user-help@jakarta.apache.org >> >> >> >> >> > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org >For additional commands, e-mail: commons-user-help@jakarta.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org