tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Moving from a very old Tomcat to a new Tomcat.
Date Wed, 11 Jun 2008 23:24:53 GMT
Hi Chris.

First I repeat my thanks for taking the time to educate this 
Tomcat-amateur programmer.

Second, I do take your point about the ultimate need, for one who really 
wants to understand the details, of reading the Servlet Specification.
I have tried before, and found many parts to be dry and unintelligible 
to me, probably in part due to the fact that I am not an intensive Java 
nor Tomcat programmer.  I must admit I would never by myself have found 
the between-the-lines implication from the paragraph you chose as 
example, and your complementary explanation is what makes it evident a 
posteriori. You have convinced me anyway of having another try at 
reading the specs.

Regarding your questions about why I am concerned about knowing if the 
session-id that is supplied in the JSESSIONID cookie matches the 
session-id of the real current session :

Imagine that a first browser request starts a session, identified by 
session-id #1, and creates a corresponding browser JSESSIONID cookie 
containing #1.  Within the same session, in the course of several 
interactions, the application accumulates various data in the 
server-side session structure, as session attributes I suppose.
Then the user stops for a while, goes to sip a coffee and comes back.
During that period of time, the session on the server side expired, but 
since the user did not close their browser, the session cookie is still 
valid in the browser (I imagine this is a "browser-session" type of cookie).
Now the user continues his session, and sends one more request to the 
server, same application.  The request arrives at the server with the 
JSESSIONID cookie, the server extracts the request session-id from it 
(still #1).
The servlet now calls sess = request.getSession().
The previous session has expired on the server, so sess is a new 
session, with session-id #2.
And now the application tries to retrieve, from sess, one of the 
attributes it stored in the session earlier.
It will most probably get a null, which means that the atribute does not 
exist, which fact may be significant to the application.

Is that a valid concern, and a reason to always compare the cookie 
session-id with the current session's session-id, or am I missing 
something again ?

André


Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> André,
> 
> André Warnier wrote:
> | Christopher Schultz wrote:
> |>
> |> [request.getSession(true)] has been called, just not by /your/ code
> at this point.
> |
> | Aha ! So there can be hidden, I would even say occult, calls to
> | HttpServletRequest.getSession(), that the unsuspecting developer
> | wouldn't even know about !
> 
> I wouldn't go so far as to say 'occult'.
> 
> | Unless he happens to consult the Holy Source Code, or be a visitor to
> | this list and be thus enlightened.
> | Or is there another source of enlightenment about this, that I don't yet
> | know about ?
> 
> You could observe that you suddenly have a session. (!)
> 
> 
> Hidden in the servlet specification (section 12.5.3.1) there is an
> implied requirement for session creation as part of authentication:
> 
> "
> If the user is authenticated using form login and has created an HTTP
> session, the timeout or invalidation of that session leads to the user
> being logged out in the sense that subsequent requests must cause the
> user to be re-authenticated. The scope of the logout is that same as
> that of the authentication: for example, if the container supports
> single signon, such as J2EE technology compliant web containers, the
> user would need to reauthenticate with any of the web applications
> hosted on the web container.
> "
> 
> So, sessions are not /required/ by the servlet specification to track
> authentication of a particular user, but when any session dies for that
> authenticated user, then user's authentication is lost. The
> read-between-the-lines implication is that successful authentication
> implies the existence of a session (though the opposite is certainly not
> true).
> 
> Technically, it is an implementation detail. Practically, it's the only
> sensible solution.
> 
> |  > If you make a request to a servlet with a bugus session id, then this
> |  > method will return false.
> |  > It could be generally bogus (wrong format,
> |  > etc.) or the session could have expired. The requested session id 
> could
> |  > be different from the "current" session id, if an invalid session
> id was
> |  > requested, and the servlet calls request.getSession(true). In that
> case,
> |  > the requested and actual session ids will be different.
> |  >
> |
> | Ah but..
> | If I make a request with a bogus (or expired) session-id, then Tomcat
> | will never be able to "reconnect" the request with a valid existing
> | session.
> 
> Right. The user-supplied session id will be ignored.
> 
> | But , if I understand this right, if I make a request with an invalid
> | session-id (in the JSESSIONID cookie for instance), Tomcat will not
> | instantly throw out the call with a stack trace.
> 
> Why would it ever do that? An invalid session is is not considered an
> exception at all.
> 
> | It might sneakily let
> | the call proceed, until the servlet tries to do something with the
> | session which it thinks it has but doesn't. /Then/ it will throw the
> | servlet out.
> | Right ?
> 
> No. The worst case is a NullPointerException, which could be thrown by
> running this code with a non-existent session:
> 
> request.getSession(false).getId();
> 
> | In other words, if I write a servlet which depends on the pre-existence
> | of a valid session, should I always check
> | HttpServletRequest.isRequestedSessionIdValid() first, or can I call
> | HttpServletRequest.getSession(false) and check for a null return value ?
> 
> If your servlet requires a valid session, I would recommend using:
> 
> request.getSession()
> 
> ...which guarantees a non-null result.
> 
> | Or can I call HttpServletRequest.getSession(true) and check if the
> | obtained session's id matches the request JSESSIONID a posteriori ?
> 
> Why would you care if the requested session id was the same as the
> actual session id?
> 
> | Are these calls always equivalent, from the point of view of checking if
> | I have a pre-existing valid session matching the session-id of the
> cookie ?
> 
> I suppose so, but I'm not sure anyone cares. Are you concerned about
> evildoers requesting bogus session ids and then getting valid ones
> created for them on the fly?
> 
> | P.S.  No matter what the answers are, thank you much for your time
> | anyway. It has been a very informative exchange for me, filling up many
> | grey areas that I thought I approximately understood but did not really.
> 
> You should really read through the servlet specification. Before I did
> it (never read it cover to cover, I must admit), I thought it would be
> wordy, dry, and unintelligible. To the contrary, it is well-written,
> understandable, and (the best part) SHORT. You could probably get
> through it in a single workday if you read every word (except for the
> APIs, which are not worth reading at all unless they in Javadoc format
> online).
> 
> It definitely fills-in lots of details which you may not have known.
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkhQSp0ACgkQ9CaO5/Lv0PAoIACggfJivsJT62ZwZNXawjrrmBbB
> TmcAn3JF6v90Upwpkf3Fshwo1ZXn7ynr
> =J/dz
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message