Alexandre Jousset wrote:
Hello list,
I've problems to set session expiry time per user.
My goal is to have a default expiry time of until you quit the
browser unless the user logs in and select a checkbox to have the
site remember her (i.e. set expiry time to 1 year).
I use
Hello Matt,
Matt Lawrence a écrit :
To set the longer expiry time, I try:
I think that will make the cookie expire on the 1st January 1971. Try
+31536000.
Looking at the sessions table, the value is correct, with or without
the '+'. The problem seems to come from the line :
Alexandre Jousset wrote:
Hello Matt,
Matt Lawrence a écrit :
To set the longer expiry time, I try:
I think that will make the cookie expire on the 1st January 1971. Try
+31536000.
Looking at the sessions table, the value is correct, with or
without the '+'. The problem seems
On Fri, Mar 14, 2008 at 12:33:19PM +0100, Alexandre Jousset wrote:
Hello list,
I've problems to set session expiry time per user.
My goal is to have a default expiry time of until you quit the
browser unless the user logs in and select a checkbox to have the site
Am 14.03.2008 um 13:53 schrieb Bill Moseley:
Catalyst::Plugin::Session::DynamicExpiry
isn't working for me using cookies. The patch was never applied so I
go with this:
sub auto : Private {
my ( $self, $c ) = @_;
if ( $c-user_exists ) {
Hello Bill,
Bill Moseley a écrit :
My goal is to have a default expiry time of until you quit the
browser unless the user logs in and select a checkbox to have the site
remember her (i.e. set expiry time to 1 year).
There's a plugin that is designed for that:
On 2 Mar 2008, at 03:50, Jonathan Rockway wrote:
In the second case, it's just a bug in the Session::Store::Cache store
that can be fixed with the addition of a backend_expires configuration
key, probably set to never by default.
Not quite true. It would look like it fixes it for most cases.
On Sun, Mar 02, 2008 at 01:31:42PM +, Ash Berlin wrote:
On 2 Mar 2008, at 03:50, Jonathan Rockway wrote:
In the second case, it's just a bug in the Session::Store::Cache store
that can be fixed with the addition of a backend_expires configuration
key, probably set to never by default.
* On Sun, Mar 02 2008, Ash Berlin wrote:
On 2 Mar 2008, at 03:50, Jonathan Rockway wrote:
In the second case, it's just a bug in the Session::Store::Cache store
that can be fixed with the addition of a backend_expires configuration
key, probably set to never by default.
Not quite true. It
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
Bill Moseley wrote on 3/1/08 9:55 AM:
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
* On Sat, Mar 01 2008, Bill Moseley wrote:
Is it expected that the application update the session every request
to prevent expiry while a user is actively using the application?
Is the problem that $c-session-{__expires} doesn't get updated, or is
the problem that the Cache backend is losing
On Sat, Mar 01, 2008 at 09:50:10PM -0600, Jonathan Rockway wrote:
* On Sat, Mar 01 2008, Bill Moseley wrote:
Is it expected that the application update the session every request
to prevent expiry while a user is actively using the application?
Is the problem that $c-session-{__expires}
13 matches
Mail list logo
