On 23/09/2012 10:46, Brian Burch wrote:
> With reference to:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53584
>
> I reproduced the problem using the sample war on a back-level svn
> version of the trunk, then confirmed the problem was fixed on a later
> level.
>
> I have been developing a new unit test case in
> org.apache.catalina.authenticator.TestFormAuthenticator to reproduce the
> behaviour demonstrated by the war. However, my new test failed because
> the client was challenged to relogin after successful authentication,
> even though it provided the correct jsessionid parameter value on
> subsequent GETs to the protected resource.
>
> I discovered the default behaviour for AuthenticatorBase is to ask the
> Session Manager to generate a new sessionid after authentication. This
> behaviour seems to be intended to prevent session fixation attacks.
Correct.
> However, in the case where the client is not using cookies (my test
> disables them for its Context), there does not appear to be a way for
> the server to communicate the new jsessionid value to the client. The
> client has no idea that this has happened, so it appends the original
> session id to the next GET request. The Authenticator cannot find the
> original session id (it is deleted when the new one is generated), so it
> issues a new login challenge to the supposedly-unauthenticated client.
> In other words, the authentication is applied to just one request,
> rather than all subsequent requests.
The new session ID will be encoded in the URLs sent back to the client
(assuming that the application uses the API to encode them).
> I modified my test to traverse the Valve pipeline and set the
> FormAuthenticator changeSessionIdOnAuthentication flag to false. The
> test now works as intended.
>
> Have I misunderstood the situation?
I'm not sure.
> If not, then two issues concern me:
>
> 1. It seems as if a session that does not use cookies and is prepared to
> use url rewriting will only work when the
> changeSessionIdOnAuthentication logic is disabled, or is there some way
> to get the new session id sent to the http client? [The demonstration
> war uses jsps which use response.encodeURL("j_security_check"), and
> response.sendRedirect(response.encodeRedirectURL("index.jsp")), which
> append the current jsessionid to the url.]
Post authentication, they should return the new session ID back to the
client. If they are returning the old ID then that is a problem.
> 2. I can see AuthenticatorBase.changeSessionIdOnAuthentication is an
> instance variable. I am concerned about the scope of the Valve instance
> - I normally code my Valves at the Host level in server.xml, but not, of
> course, the Authenticators, which are defined by the login-config
> section of each webapp's web.xml. Does each Context have its own
> instance of the authenticator valve?
Yes. A quick check with JConsole will confirm this.
> I would like to be sure of my understanding before proposing the test
> case as an enhancement, so any comments or advice would be helpful.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
