Following my comments below I thought I'd follow up a bit with some brief
testing of my own.
This is what I think it going on. Someone with more knowledge/experience,
please correct me if anything I say here is wrong. I'm assuming that the
browser is cooperating with sessions OK, i.e. not configured to block them.
When TC receives a request, it checks to see whether the browser has
included a jsessionid in the request. You can do this yourself as follows:
String sessId = request.getRequestedSessionId();
If there is a jsessionid in the request (i.e. null != sessId), and it
matches a valid TC session object (i.e. one that has not timed out or had
invalidate() called on it), that session object is associated with the
request, and the same jsessionid will be written back to the browser with
the response that TC sends back, so that the session is persisted.
If the requested jsessionid does not match a valid session, a new session is
immediately created by TC and assigned to the request, with a new
jsessionid, which TC writes back to the browser with its response. This new
session creation seems to take place before the doPost() method is entered.
However you can still tell whether an old jsessionid was requested even
after the new jsessionid has been assigned, as follows:
String id = request.getRequestedSessionId();
if (null==id)
{
// there was no jsessionid in the request
}
else if (request.isRequestedSessionIdValid())
{
// there was a valid jsessionid in the request
}
else
{
// there was an invalid jsessionid in the request
}
In either case, a session object is always returned by request.getSession()
and request.getSession(false). (Actually this was a surprise to me, because
it seems that it is not possible to suppress creation of a new session where
none exists by using getSession(false)....?)
Thus, the effect of all this taken together is that browser sends a
jsessionid to TC with every request except when the browser is opened afresh
and makes its first request to the webapp. It even seems to send timed out
jsessionids to the server when the browser has been left open for longer
than the session timeout (presumably TC handles expiry issues server-side),
or when the browser is left open while TC is restarted. Once TC has sent a
jsessionid to the browser, the browser will keep returning it in every
request to TC until the browser is closed, or TC changes the jsessionid for
some reason.
Now, the question of authentication. I don't think that there is way to
tell that a user has authenticated using any of the code that Joseph or I
have mentioned, because this code deals only with sessions (which exist
whether you authenticate or not). The code above merely tells you
information about a browser's recent visit to the site. I'm not familiar
with TC's own authentication, but in my own case, successful authentication
is indicated by adding an object to the session to indicate that a given
authenticated user is using it. Thus I use a test like:
if (null==(myclasses.User)request.getSession().getAttribute(CURRENT_USER))
{
throw new MyAuthException("User not authenticated");
}
else
{
// complete their request
}
Calling the invalidate() method on a session seems to cause the session
object to be destroyed immediately. If this is done during processing of a
request, I think that TC still sends the old jsessionid to the browser in
the response. So the next time that the browser makes a request, it will
present the old jsession, which will be invalid, so TC will replace the
jsessionid at that point.
Hope this is useful to someone else and isn't too far off the mark...?
> -----Original Message-----
> From: Steve Kirk [mailto:[EMAIL PROTECTED]
> Sent: Wednesday 08 December 2004 16:25
> To: 'Tomcat Users List'
> Subject: RE: How to detect expired session vs. no session? (Solved)
>
>
> I'm a bit puzzled. There is something not quite right here
> (or maybe I'm
> not quite understanding correctly). Aren't sessions created
> as soon as a
> JSP within a ServletContext is accessed, irrespective of
> whether the user
> authenticates or not? Thus invalid sessions vs anonymous
> sessions is not an
> either/or choice - a session can be both valid and
> authenticated, or both
> valid and anonymous. Is "invalid" the same as "expired"?
>
> Also there seems to be a slight contradiction in what you say
> below, because
> if request.getSession returns null for an invalidated
> session, how can you
> then call isRequestedSessionIdValid() on an invalidated
> session without
> getting a NullPointerException? I realise that the method is
> not called on
> the session object directly, but surely it must access the
> session object at
> least indirectly?
>
> > -----Original Message-----
> > From: LAM Kwun Wa Joseph [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday 08 December 2004 11:23
> > To: [EMAIL PROTECTED]
> > Subject: RE: How to detect expired session vs. no session? (Solved)
> >
> >
> > Confirmed that request.getSession(false)==null for both
> > expired session
> > requests and anonymous requests, if I have <%@ page
> > session="false" %> in
> > my pages.
> >
> > I just figured out the follow which work exactly what I wanted:
> >
> > boolean hasSessionID =
> > (request.isRequestedSessionIdFromURL() ||
> > request.isRequestedSessionIdFromCookie());
> >
> > if (hasSessionID && !request.isRequestedSessionIdValid()) {
> > // expired/invalidated session
> > }
> > else {
> > // no session at all
> > }
> >
> >
> > > I haven't tested this, but I *think* that a request containing an
> > > expired session will still return a non-null session object, but a
> > > different instance to the one that would have been returned
> > pre-timeout.
> > > But I don't know that for a fact. why not just test it
> > out yourself,
> > > it's not that hard, just shorten the timeout interval first
> > so that you
> > > don't have to wait 30 mins to do your test ;)
> > >
> > >> -----Original Message-----
> > >> From: LAM Kwun Wa Joseph [mailto:[EMAIL PROTECTED]
> > >> Sent: Wednesday 08 December 2004 09:35
> > >> To: [EMAIL PROTECTED]
> > >> Subject: RE: How to detect expired session vs. no session?
> > >>
> > >>
> > >> But does it have the same effect for a request with an
> > >> expired session vs
> > >> a request with no session at all? I think it will return
> > null in both
> > >> cases.
> > >>
> > >> > if you call request.getSession(false) this will return
> > null if the
> > >> request is not associated with a request already. the
> > "false" param
> > >> turns off the default behaviour of creating a new
> session when none
> > >> exists.
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: LAM Kwun Wa Joseph [mailto:[EMAIL PROTECTED]
> > >> >> Sent: Wednesday 08 December 2004 08:23
> > >> >> To: [EMAIL PROTECTED]
> > >> >> Subject: How to detect expired session vs. no session?
> > >> >>
> > >> >>
> > >> >> Hi,
> > >> >>
> > >> >> How can I tell between a request using an expired session
> > >> vs a request
> > >> >> with no session at all? I need to show different messages to
> > >> >> users being
> > >> >> kicked due to inactivity and to anonymous users. Thanks!
> > >> >>
> > >> >> Regards,
> > >> >> Joseph Lam
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >>
> >
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail:
> > >> [EMAIL PROTECTED] For
> > >> >> additional commands, e-mail:
> [EMAIL PROTECTED]
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> >
> > >> --------------------------------------------------------------
> > >> ------- To
> > >> > unsubscribe, e-mail:
> > [EMAIL PROTECTED] For
> > >> additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >>
> > >>
> >
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail:
> > [EMAIL PROTECTED] For
> > >> additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >
> > >
> > >
> > >
> > --------------------------------------------------------------
> > ------- To
> > > unsubscribe, e-mail:
> [EMAIL PROTECTED] For
> > > additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
