[Esapi-user] ESAPI.authenticator().login() semantics
kevin.chen at scynexis.com
Fri Dec 3 17:23:26 EST 2010
I'm a new ESAPI user, and I have been using the SwingSet 1.0
(http://code.google.com/p/swingset-demo/) application to learn the API
features and usage.
The lab on preventing cross-site request forgery has a JSP page
(CSRFLab.jsp) where the user logs in using
ESAPI.authenticator.login(request, response) and must be modified by the
user to decorate a link on the page using
ESAPI.httpUtilities().addCSRFToken(href). This is straightforward
The href in question links to a second JSP page where the task is to add
code to validate the CSRF token that was appended. The lab template
code uses ESAPI.authenticator().getCurrentUser() to obtain a User
object, and the intended solution is for the lab implementor to use
user.getCSRFToken() to obtain the current user's token and compare it
against the token value added to the page link (i.e.
However, when I implement this solution (or even run the lab solution
provided by SwingSet), the user object retrieved by the second page is
not the User object stored in the HTTP session, but the Anonymous user.
This is presumably because the reference implementation of
ESAPI.authentication.getCurrentUser() only sets the thread local value
currentUser on a successful call to login() (in AbstractAuthenticator).
Since these are JSPs (and I am running in a Tomcat container), it is
very likely that different page requests are serviced by different
threads in the container, and therefore the current user will not be
populated when the second request is processed.
I am attempting to determine whether this is a behavior specific to the
reference implementation or the intended usage pattern for
ESAPI.authenticator().login() -- that is, the no-argument version of
login() should perform all of the logic to populate the current user
object. The problem I am encountering is that if the answer is the
latter, there is a validation call in login() to
ESAPI.httpUtilities().assertSecureRequest() which treats non-POST
requests as invalid. So if I want to use login() to populate the
current user, I have to wrap all of my requests in HTML form
submissions, which hardly seems like a reasonable requirement for the
Is my interpretation of the API correct, or am I running into issues (or
design bugs) specific to the reference implementation? If login() is
not the correct API to use, which one should I be using?
Any advice/assistance is appreciated,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user