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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
