[Esapi-user] [Esapi-dev] ESAPI Input Validator and Exception

Thu Feb 4 18:30:31 EST 2010

The more languages you need to support, the more resource bundles break 
down.  I do not mind supporting resource bundles, but I would prefer to 
have i18n abstracted so someone can choose to implement a data-driven 
solution.

- Jim
> There's other issues to consider here.   last time I looked at the 
> code, the default was to throw an exception with the field failing and 
> the regex, but with the input value added in the logfile.  This has 
> issues too, as the input value can sometimes be considered sensitive 
> data that should not be stored anywhere, including log files (example, 
> credit card numbers)
>  
> Simply overriding this can be tricky because of the intrusion 
> detector.  Resource Bundle may be the answer, but I think it would 
> have to be a replacement string bundle entry so it can be 
> parameterized, which could mean (potentially) modifying/enhancing the 
> new Exception signature.
>
> On Tue, Feb 2, 2010 at 12:59 AM, Chris Schmidt <chrisisbeef at gmail.com 
> <mailto:chrisisbeef at gmail.com>> wrote:
>
>     *cough* ResourceBundle *cough*
>
>     For example, check out how I did it in esapi4js. There are some
>     slight syntactic differences to do it in Java, but the idea is the
>     same.
>
>     http://code.google.com/p/owasp-esapi-js/source/browse/trunk/src/main/javascript/org/owasp/esapi/reference/validation/BaseValidationRule.js#125
>
>     Basically, a ValidationRule has an associated ResourceBundle that
>     it uses, this is configured through configuration (or as a runtime
>     decision based on the client Locale). This allows for both i18n
>     support and customized messaging for errors in validation logic. :)
>
>     Just an idea.
>
>     Granted, ResourceBundles can generally be a pain in the butt, but
>     they work well once they are implemented.
>
>
>     On Mon, Feb 1, 2010 at 10:10 PM, Kevin W. Wall
>     <kevin.w.wall at gmail.com <mailto:kevin.w.wall at gmail.com>> wrote:
>
>         Johan Lim wrote:
>         > Hi All,
>         >
>         > With the Validation Exception that is thrown by the input
>         validator, can we
>         > customise the error message?
>         > I notice that currently it will throw a message telling user
>         what the regex
>         > is for a particular field but I think the message may not be
>         useful for user
>         > that don't know regex.
>
>         First question...which version of ESAPI? Second
>         question...which particular
>         input validator specifically are you referring to? There are some
>         validators that have specific "user friendly" error messages
>         (e.g., those
>         for date validation, credit card validation, etc.), but one
>         validation rule--
>         StringValidationRule--which is has this "user friendly"
>         (cough, cough) exception
>         that it throws:
>
>         throw new ValidationException(
>         this.encoder.encodeForJavaScript(context) +
>                                           ": Invalid input. Please
>         conform to regex " +
>                                           p.pattern() +
>                                           ( maxLength ==
>         Integer.MAX_VALUE ? "" :
>                                             " with a maximum length of
>         " + maxLength ),
>                                       "Invalid input: context=" +
>         context + ", type(" +
>                                           getTypeName() + ")=" +
>         p.pattern() +
>                                           ", input=" + input +
>                                           (NullSafe.equals(orig,input)
>         ? "" :
>                                             ", orig=" + orig), context );
>
>
>         and is probably the one you are talking about.
>         ValidationException has several
>         constructors. The one used here is this one:
>            /**
>             * Creates a new instance of ValidationException.
>             *
>             * @param userMessage       the message to display to users
>             * @param logMessage        the message logged
>             */
>            public ValidationException(String userMessage, String
>         logMessage);
>
>         It probably would be better to simply say
>
>                "Invalid input. Please try again."
>
>         rather than all that geek-speak.  Unfortunately, since
>         StringValidationRule
>         doesn't know if its parsing a dollar amount from an address
>         from the
>         name of a bank, it's hard for it to be much more specific.
>         Furthermore, I
>         suppose the reasoning goes that there is some small set of the
>         general
>         population that thinks everyone should have regular
>         expressions tattooed on
>         their arm. (I didn't put this specific message in, but I can
>         relate. Every once
>         in a while, our geekiness shows through. ;-)
>
>         Since we already have an appropriate message to log, I suggest
>         that for the time
>         being (especially for 1.4.4), we punt and just use something like:
>
>                "Invalid input; please try again."
>         or
>                "Invalid input; please try again. " +
>                  "Contact the help desk if you need further assistance."
>
>         This pondering has caused to to think about another more
>         generic, long-term
>         approach (e.g., 2.1 timeframe) for all this, but I don't have
>         time to write
>         it up tonight. Maybe in a few days.
>
>         Anyhow, I how this addresses Johan's issue somewhat.
>
>         -kevin
>         --
>         Kevin W. Wall
>         "The most likely way for the world to be destroyed, most
>         experts agree,
>         is by accident. That's where we come in; we're computer
>         professionals.
>         We cause accidents."        -- Nathaniel Borenstein,
>         co-creator of MIME
>         _______________________________________________
>         Esapi-dev mailing list
>         Esapi-dev at lists.owasp.org <mailto:Esapi-dev at lists.owasp.org>
>         https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
>
>
>     -- 
>     Chris Schmidt
>
>     OWASP ESAPI Developer
>     http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
>
>     Check out OWASP ESAPI for Java
>
>     http://code.google.com/p/owasp-esapi-java/
>
>     OWASP ESAPI for JavaScript
>     http://code.google.com/p/owasp-esapi-js/
>
>     Yet Another Developers Blog
>     http://yet-another-dev.blogspot.com
>     <http://yet-another-dev.blogspot.com/>
>
>     Bio and Resume
>     http://www.digital-ritual.net/resume.html
>
>
>     _______________________________________________
>     Esapi-dev mailing list
>     Esapi-dev at lists.owasp.org <mailto:Esapi-dev at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>   

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100204/cf498d19/attachment.html 