Stuart Donaldson [mailto:stu@...] wrote:
> That is rather interesting. The SecureCountVisits page does
> not check
> for Application.createSessionForTransaction() as does the CountVisits
> It appears that when a session expires, the strategy is to call
> Application.handleInvalidSession() which basically removes the _SID_
> reference so the browser will stop requesting an invalid session, and
> marks request._sessionExpired. It does not however, delete
> the session
Yes it does -- see Application.isSessionIdProblematic() which explicitly
calls "del self._sessions[sid]" on an expired session.
> The sesion object remains attatched to the transaction for
> the remainder
> of the transaction processing by the servlet. It is up to
> the servlet
> to check the request.isSessionExpired() and take appropriate
> action of
> notifying the user that their session has expired at this point.
I don't think that's quite what's happening. I think this is what happens
on an expired session:
1. The Transaction object is constructed, and transaction._session is
initialized to None.
2. Application.isSessionIdProblematic() detects the expired session and
deletes it from self._sessions.
3. Application.handleInvalidSession() is called, which clears the _SID_
cookie and/or field (if the IgnoreInvalidSession setting is enabled,
otherwise it returns an error message).
4. Sometime later in the request processing, self.session() is called...
5. ...which calls Application.createSessionForTransaction()...
6. ...which calls Request.sessionId() to get the session ID...
7. ...which returns None because the session ID was cleared in step 3 above
8. Therefore Application.createSessionForTransaction() creates a _new_
So as far as I can tell, the call to self.session() is handled as though
there was no session at all, and a new empty session is created.
There's no need to call isSessionExpired() unless you specifically want to
treat an expired session differently from a non-existant session. It
depends on what your application is doing. The SecurePage example handles
both cases the same way, and simply sends the user back to the login page,
but it could certainly be done differently.
Am I missing something here? I don't see any problem.