-----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]
