[Catalyst] Session Expiry

Bill Moseley moseley at hank.org
Sat Mar 1 15:55:43 GMT 2008


Is it expected that the application update the session every request
to prevent expiry while a user is actively using the application?

My assumption is I want to set $c->config->{session}{expires} to some
value which will log users out after some period of inactivity, yet
won't log them out if they are actively using the application.


Here's what I'm seeing, in painful detail:


I'm using Session::Store::Cache to store my sessions in the cache,
which is memcached in my case.  We have decided this is an appropriate
store for sessions in this application.

The Session plugin stores two entities.  One is the actual session
data and that is saved whenever the session is updated by the
application.

The other is an "expires" entry and that is saved *every* request.
The idea is the "expires" entry is written every request to
extend the session.

The problem, of course, is that the session data, at least in the case
of using the Cache backend, also has an expires time.  So, even though
the Session plugin extends the "expires" entry every request, if the
actual session data is not written to in the application it is not
updated and thus may expire.

In other words, as an example, if $c->config->{session}{expires} = 20
then the session will expire in twenty seconds even if a request is
made every 5 seconds as long as the actual session data is not updated
during that 20 seconds.

Setting the expires time to something more reasonable like an hour
doesn't solve the problem because if the user manages to use the
application in a way that doesn't require updating the session they
will still get logged out after the expires time.


My question is this:

Is it expected that the session is rewritten every request?  I frankly
don't see any way around that as long as the session store has its own
expiry (e.g. with memcaced).

Is this a problem with the Session plugin design?  That is, should it
not have a separate "expires" entry written and instead simply fetch
the session, update an __expires entry in the session data, and then
write it back to the store every request (with a new expires if the
store provides that feature).

Or, is this an issue with using a session store that supports expires
times?  Using a different store (like the database) would mitigate the
problem because I could use a much longer expires time for the cron job
that purges old session data than the $c->config->{session}{expires}
time.  Still, that doesn't *solve* the issue.


The work-around is simple; I'm just updating the session in auto()
for every request.




-- 
Bill Moseley
moseley at hank.org




More information about the Catalyst mailing list