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.
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.
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? 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.]
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?
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.
Thanks,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
