I want to have the session object just disappear silently when the session times
out, as it does now. I assume this is still an option? Here's why:
What I've done is write a class derived from Page called SecurePage that all of
my pages requiring login are derived from. In WriteHTML, SecurePage checks that
a valid username and password were provided as form variables OR that no username
and password were provided and the correct session variables are present to
indicate that the user is already logged in. If either of these conditions
apply, it sets session variables indicating the user is logged on and calls
Page.WriteHTML. Otherwise, instead of calling Page.WriteHTML, it displays a
login page with username and password fields, and hidden form fields containing
all request variables, if any. This way, you can bookmark any secured page in
the site, even one with parameters, and if you go back to that page in a new
session or after your session has timed out, it asks you to log in, then once
you've logged in, it gives you the page you wanted.
Jay Love wrote:
> I would like to propose a brief discussion of this session timeout
> behavior. My opinion is that no error page should be sent when a
> session times out, just assign a new session ID. I don't know that I've
> ever gotten a session timeout error page, except on my company's
> intranet, and it really annoys me there, as I would prefer to simply be
> redirected to the login page.
>
> So, I suggest not sending an error page by default.
>
> I'm planning on adding the ability for Servlet's to set the timeout on a
> Servlet directly. I'll add that tonight.
>
> Jay
>
> Chuck Esterbrook wrote:
> >
> > FYI I updated Application so that when your session is expired, it displays
> > a page saying so. Previously, you would simply lose your session data and
> > depending on the nature of the page, experience some strange problems.
> >
> > Sessions expire either because they time out from inactivity, or because
> > the app server was restarted (and you therefore lose the sessions that were
> > stored in memory).
> >
> > This is checked in. The method in Application.py is handleInvalidSession().
> >
> > Another enhancement that I'm brewing is file backed sessions. By storing
> > sessions on disk, rather than in memory you get:
> >
> > * the ability to restart the app server without hosing users
> > * the ability to use sessions with the OneShot adapter
> > * a founding piece of fault tolerance
> >
> > The only know disadvantage is a performance hit.
> >
> > The sessions are stored one per file in WebKit/Sessions/ with the id as the
> > filename. The contents are pickled, but you can set the encoder/decoder
> > functions (as I call them) if you prefer marshalling or your own
> > proprietary scheme.
> >
> > The new classes are:
> > SessionStore
> > SessionMemoryStore
> > SessionFileStore
> >
> > The first is abstract and is all the Application knows about. Session
> > stores pretty much look like dictionaries when you use them.
> >
> > As you can imagine, it would be fairly easy to create SessionSQLStore and
> > others.
> >
> > You can set the session store through a setting in the config file.
> >
> > I have the code 95% finished, but there are some glitches. I estimate that
> > I'll check this in sometime tomorrow.
> >
> > -Chuck
> >
> > _______________________________________________
> > Webware-discuss mailing list
> > Webware-discuss@...
> > http://lists.sourceforge.net/mailman/listinfo/webware-discuss
>
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/mailman/listinfo/webware-discuss
--
- Geoff Talvola
Parlance Corporation
gtalvola@...
|