tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Len Popp" <len.p...@gmail.com>
Subject Re: Moving from a very old Tomcat to a new Tomcat.
Date Wed, 11 Jun 2008 23:59:06 GMT
In general, yes, your application has to be able to handle dropped
sessions and session attributes. That's a consequence of the way the
web works. A user could bookmark any page and return to it weeks
later.

You can't control the timing or order of web page requests. If a
servlet finds some vital piece of input is missing, it just has to
return a 400 error. I haven't had any difficulty making this work.
-- 
Len


On Wed, Jun 11, 2008 at 19:24, André Warnier <aw@ice-sa.com> wrote:
> 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