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

Chris Schmidt chrisisbeef at gmail.com
Tue Feb 2 00:59:19 EST 2010


*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>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
> 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

Bio and Resume
http://www.digital-ritual.net/resume.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100201/ef4e1cc1/attachment.html 


More information about the Esapi-user mailing list