On 23/09/12 11:10, Mark Thomas wrote:
Thanks for looking at my questions, Mark. I hoped you would find time,
because you fixed the original bug quite recently and would still
remember the rather convoluted logic for FORM authentication.
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
... or no ID at all ...
then that is a problem.
I draw the following conclusions:
1. A client that can accept a Set-Cookie for JSESSIONID will be able to
maintain a persistent session (is that incorrectly overloading a
reserved word?), no matter whether the session ID is changed once, many
times, or not at all.
2. A client that cannot accept cookies will only be able to maintain a
persistent session IF the server sends the correct (current) jsessionid
as a path parameter appended to ALL urls within its response. That is
achievable with servlets, jsps, jstl (all of which which can ask for an
encoded url to be inserted into the dynamic web page). It cannot work
with static html.
3. Therefore, any webapp that MIGHT need to authenticate a client that
does not accept cookies MUST generate EVERY protected resource url
dynamically (to include the session ID).
4. Any webapp that cannot satify case 3 MUST turn off
changeSessionIdOnAuthentication for its Context and degrade the session
fixation protection for ALL of its clients.
Do you agree, or have I misunderstood something in my analysis?
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,
Yes, a lot, thanks! I have enough clarity of thought to get on with the
new test case now.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
