Webware for Python

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

I've added this capability.  Session now has a function, setTimeout,
which takes the timeout in minutes for this session.  There's a
corresponding get function, that returns the timeout in seconds.

> I'm planning on adding the ability for Servlet's to set the timeout on a
> Servlet directly.  I'll add that tonight.
> 
> Jay

At 07:51 PM 8/11/00 -0400, 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.

You do that by overridding the method handleInvalidSession(). That was the 
point of creating a method that does nothing but handles this.

WebKit has no way of knowing where your login page is or whether or not you 
even have one. It also doesn't know if it's appropriate to just make up a 
new session.


>So, I suggest not sending an error page by default.

Sending an error page is a more conservative default than immediately 
creating a new session. Ultimately, any web developer will have to consider 
how this issue relates to their site and make a call on the semantics.


>I'm planning on adding the ability for Servlet's to set the timeout on a
>Servlet directly.  I'll add that tonight.

I assume you mean Session, not Servlet...


-Chuck

At 09:32 PM 8/11/00 -0400, Jay Love wrote:
>I've added this capability.  Session now has a function, setTimeout,
>which takes the timeout in minutes for this session.  There's a
>corresponding get function, that returns the timeout in seconds.

There was already a maxIdleInterval() and setMaxIdleInterval(). Did you 
just rename these or remove them or what?

-Chuck

Chuck Esterbrook wrote:
> 
> At 09:32 PM 8/11/00 -0400, Jay Love wrote:
> >I've added this capability.  Session now has a function, setTimeout,
> >which takes the timeout in minutes for this session.  There's a
> >corresponding get function, that returns the timeout in seconds.
> 
> There was already a maxIdleInterval() and setMaxIdleInterval(). Did you
> just rename these or remove them or what?
> 
> -Chuck
> 

I didn't notice them and didn't know what you intended for them.  I just
added additional functions and a variable.  I don't care what the names
are, so if you have a preference for maxIdleInterval, feel free to
switch the code to use that.

Jay

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@...