[Catalyst] Announcement - New session plugins

[Bill Moseley]

On Tue, Nov 08, 2005 at 11:16:00AM +0200, Yuval Kogman wrote:
> > - I'd like the option in Session::State::Cookie to *not* set
> > expires on the cookie.  I'd like the action of closing the client to
> > drop the session.  Or is there a better way to handle the requirement
> > for sessions to vanish when the client is closed?
> 
> Technically this is problematic: The browser will never notify the
> server when the session data expires, causing a storage leak
> (references to the session ID will be lost on browser close, but the
> store can't know that).

That's the case regardless of setting expires or not on a cookie.  The
client may never return.  The Store system either must manage purging
old session data, or there needs to be a separate cron job that clears
server-stored sessions.

> > - Cookies enabled detection.  I suppose I could do that in my app
> > class auto method, but might be nice for the plugin to do the
> > detection.
> 
> Hmm... This part is kind of tricky since it cannot be done in one
> request - the client must be told to save a cookie, and this cookie
> must be asked for later.

Right.  And it varies by application when you need to know.  Some
applications need a session for every request, so the first request
without a valid session from the client would need to set the cookie,
redirect to a special cookie-checking url which would either report
cookies are required if not found, or do a second redirect back to the
original request if the cookie is found.  I don't really see a way
around the double redirect.

Other applications might only need state saved when asking to log in
or when adding state info, say adding to a cart.

In the past when I've done this:  If no session in a cookie or URL
then add a URL session and redirect to a special url.  If cookie comes
back then remove URL session and redirect back to original request.
Otherwise redirect back leaving the URL session.

I really find it frustrating to go to a site when I have cookies
turned off and instead of being told so the site just doesn't work.
(Like telling me my password is incorrect just because cookies are not
enabled!)


> I think the best option is to allow a checkbox on login that says
> "use URI rewriting instead of cookies" with all the caveat info
> mentioned to the user. Then, on login this flag will be added to
> $c->{session}.

But you often need the session before the login page.  I'd probably
have a "Cookies required" page with an option to continue using URL
sessions.  Assuming we can trust the site user to make an informed
decision...

Disabled cookies are a lot less common then five years ago.  But, some
public access computers still disable them for privacy reasons.

Perhaps for security reasons would it be wise to set a different expires time
for URL sessions than for cookie sessions?

Thanks!


Oh, BTW -- there's a few things I commonly do, but I'm not sure if they are
plug-in features or application features.  Mostly application, I
suppose, as they are more than just "session" data:

- When a user logs in I set a long term cookie to identify that user.
Then that can be used to pre-set their username (or in some cases, log
back in) when they return.  (That's the "remember me" checkbox on the
login form.)

- I may expire sessions in two hours, but if there's 5 or 10 minutes
of inactivity then I require a re-login to access more secure parts
of the site (like an admin area).  So the session needs to track the
time between requests and set a flag when exceeds a setting.

Related to that, I might require a re-login when accessing parts of
the site and it's been too long since they last entered their
password.


-- 
Bill Moseley
moseley at hank.org