tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Moving from a very old Tomcat to a new Tomcat.
Date Wed, 11 Jun 2008 21:58:54 GMT
-----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


Mime
View raw message