[JIRA] Commented: (JOST-184) It would be nice if ESAPI.encodeForURL could be made to work

[Brent Putman (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/JOST-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324#comment-14324 ] 

Brent Putman commented on JOST-184:
-----------------------------------

This is @coding, not Rod:
I don't completely agree that this is a no-no for libraries, although is somewhat sub-optimal.  There were good reasons for doing this.  We currently only use 2 or 3 encoder methods from ESAPI, which have no jar dependencies (all internal to ESAPI). Leaving the default config in place would have meant shipping OpenSAML with all of their dependencies (upwards of 20 jar files last time  I looked) which are used for the other 99.9 % of the library. Also, as a security library ourselves, we wanted to make it more explicit what config was required, and at least make a user do some work if they want to consciously change it.  Finally, their default config resolution mech for some properties file-based config also spews loads of stuff to stdout (which IMHO is also a no-no for libraries....).

The good news is that this isn't actually a problem.  Based on the current impl of their ESAPI locator class, they attempt to reflectively instantiate the SecurityConfiguration impl on every call to the locate methods, so you can safely just reset the impl class name back to the default value after you call our DefaultBootstrap, e.g.:

ESAPI.initialize("org.owasp.esapi.reference.DefaultSecurityConfiguration");

And should you not want to rely on the current behavior of their library in this regard (maybe you want to use a newer version), then you can just simply not use our DefaultBootstrap as-is.  It's called "default" for a reason.  It's assumed that customized impls might be desired.  So you can just use a custom bootstrap class that subclasses ours, and calls the existing protected methods there except leaves out the initializeESAPI() method.

That's what you can do today. I did look to see if there is a better option for the future.  I think it would be possible to leverage their support for a system property to set our custom SecurityConfiguration impl.  It would set to our class unless it's already been set to a non-null value before our bootstrap. That's probably cleaner and is already directly and officially supported by ESAPI.  We already do this for some other system-property based config of some other library.  I'll play with that and open an issue/task if it looks do-able.

> It would be nice if ESAPI.encodeForURL could be made to work
> ------------------------------------------------------------
>
>                 Key: JOST-184
>                 URL: https://issues.shibboleth.net/jira/browse/JOST-184
>             Project: OpenSAML 2 - Java
>          Issue Type: Improvement
>          Components: Security
>    Affects Versions: 2.5.3
>            Reporter: Rod Widdowson
>            Assignee: Chad La Joie
>            Priority: Trivial
>
> I have just "borrowed" esapi from OpenSAML to do nearly all the escaping for the DS jsp page.  I appreciate that this very much stretches the bounds of what it was initially intended for and is a bit of 'creature feep'...
> I couldn't use encodeForURL because it throws a nested exception.  The root cause is that ESAPI.securityConfiguration().getCharacterEncoding() (line 400 of org.owasp.esapi.reference.DefaultEncoder) returns null.  This in turn throws an exception in the error handling but we needn't worry about that.
> I took a _very_ brief look at the esapi security configuration and it looked to be hard wired (which feels like what it should be).  So, might it be possible to add "utf-8" as a CharacterEncoding (assuming that it makes sense for the entire stack).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira