Bug 60854 - Unintended JSESSIONID value change
Summary: Unintended JSESSIONID value change
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.75
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2017-03-13 17:31 UTC by Jan Engehausen
Modified: 2017-03-27 10:33 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Jan Engehausen 2017-03-13 17:31:24 UTC

we're observing a JSESSIONID value change on a second request in a scenario where the first request both authenticated AND created a session. We expect the JSESSIONID created in the response to the first request to remain constant in subsequent requests.

It appears that the configuration for "cache" and "changeSessionIdOnAuthentication" behave in an unintended way, creating new session IDs where none are needed. Apologies if we misunderstand this, but it looks like a bug, and not a feature.

We've detailed the situation and observations at https://github.com/smurf667/test-tomcat-session which includes a simple, reproducible self-contained test (Maven, Java).

Kind regards,
Jan Engehausen
Comment 1 Remy Maucherat 2017-03-13 17:55:22 UTC
My opinion is that it's a feature. If you don't like it, you should cause the creation of a session before authentication. Will leave it open for further comments before closing, though.
Comment 2 Jan Engehausen 2017-03-13 18:02:42 UTC
Hello Remy,

as far as I understand, session fixation prevention is there to change the session ID when a session becomes authenticated. That's good.

But without a session to begin with, then being authenticated right away, why change the session ID on the next response? There is no need for this - what does this protect against? This is appears unneccessary.

Furthermore, turning principal caching off (cache=false and changeSessionIdOnAuthentication=true) causes ANY response to set a new session ID cookie. Is that really intended?

Comment 3 Remy Maucherat 2017-03-13 18:11:07 UTC
If you don't cache authentication occurs on every request.
Comment 4 Jan Engehausen 2017-03-13 18:15:11 UTC
I see. I need to run this by my colleagues, hope it is okay to keep open until tomorrow.

I would argue that in the case where authentication and session creation occur in the same request it would not be right to change the session ID on the second request (where no authentication occurs).
Comment 5 Jan Engehausen 2017-03-15 17:31:41 UTC
So, we discussed this and still think that in the particular scenario described (authentication and session creation in the same request), a subsequent request should not get a new session ID, as authentication already happened in the previous request. Maybe a "second opinion" can be collected.
Comment 6 Christopher Schultz 2017-03-15 21:36:45 UTC
Your example does not show it; are you using cache="false" in your basic authenticator valve? You'd have to go through some hoops to effect that change.
Comment 7 Jan Engehausen 2017-03-16 05:55:05 UTC
I am using org.apache.catalina.authenticator.BasicAuthenticator directly with default settings (cache="true" and changeSessionIdOnAuthentication="true").

com.example.SessionBehaviorIT.testDemonstrateProtectedServlet() shows the issue.

Running "mvn verify" is enough. You could also start Tomcat via "mvn tomcat7:run" and then execute testDemonstrateProtectedServlet() in some IDE.



I have understood that cache="false" will cause each request to get a new session ID cookie, this case can be safely ignored.
Comment 8 Mark Thomas 2017-03-23 20:27:13 UTC
It is worth keeping in mind the change in session ID is relatively cheap. The session object remains the same, it is just the ID field that is updated.

Using alwaysUseSession="true" on the Authenticator appears, on the face of it, to be a simple solution to this problem.

I haven't tried coding it, but it looks like a fix triggered by session creation would be possible. It would require some refactoring of AuthenticatorBase.register to avoid duplication of code.

Overall, I do wonder if the additional complexity of the session creation triggered fix is truly necessary.
Comment 9 Jan Engehausen 2017-03-24 09:48:36 UTC
Hi Mark,

I can confirm that alwaysUseSession="true" does make all tests of the test project pass. In our real life setup we do have a custom authenticator and can implement the workaround as described.

I leave it up to you guys to decide if you change anything. As I said, I find the current behviour "unexpected" and think that if it did not happen like that there would be less confusion with other parties in the future.

Thanks, and kind regards,
Comment 10 Mark Thomas 2017-03-27 10:33:22 UTC
I think, given the options available, I am going to resolve this as WONTFIX.

If a use case was presented where alwaysUseSession="true" could not be used then that might justify the additional complexity required to handle session creation after authentication but, at the moment, such a use case seems pretty unlikely.