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 [EMAIL PROTECTED] _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/