Am 08.01.16 um 17:02 schrieb Christopher Schultz:
Tomcat will change the session identifier when the user authenticates.
If you are creating a session before login, you'll see that the session
id changes when authentication is successful. This is to protect against
session-fixation attacks.
I re-login the user, if tomcat returns "null" on
HttpRequest.getUserPrincipal(). I noticed that the sessionId changes.
But if I am required to re-login the user on parallel requests, it
depends on magic what sessionId is given after all responses are
delivered to the browser.
You can see in the logs, that requested sessions are suddenly invalid.
I would not require an other call to the login method if servlet
container returns a user once it is authenticated in a session.
Can you explain why the changing session id breaks your application? Are
you storing session ids somewhere and just not updating the session id
list when the session id changes? It should be possibly to listen for
that event and update your session id list. Or maybe there's a better
way to accomplish your goal rather than keeping your own session id
list. (I'm guessing you have a session id list because it would best
explain the behavior you are describing here.)
I do not save the http session id anywhere. The browser saves it in a
cookie. The cookie is changing rapidly because the UserPrincipaö is not
returned from the request.
Here is something I would prefer:
1. Every request that belongs to a given session returns a non null
object when calling getUserPrincipal() after the login() method returns
successfully.
2. As you have no control over the net and do not know in which order
the browser receives its packets, you can not invalidate a sessionId in
a snap. Tomcat has to gracefully invalidate it somehow.
An example:
1. Client logs in
2. Server responds with SID=SID1
3. Client request 2 resources in parallel
4. Server receives first request and handles it, returning SID=SID2
5. Server receives second request (with SID=SID2), which belongs to
invalid session. Code is creating a new session than. Server response
with SID=SID3
6. Client will use SID3 in future requests which belongs to the new
session and not the original session where the user is logged in.
IMHO it would be also secure to lock the sessionId to the IP address
instead of changing the id but less error-prone. You can even combine it
and allow old sessionIds only from the original IP address.
If the servlet container would just use the session information for HTML
pages parallel request are rare. But when serving cachable thumbnails it
often like checking headers and return 304.
kind regards,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
