Re: [Catalyst] Session expiry per user
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 the following plugins for session management :
Session Session::State::Cookie Session::Store::DBI
I've looked at the docs and I've only found a way to set expiry
time in MyApp.pm, and even with this I don't know how to set it for
until you quit the brower. If I put 0 the session expires immediately.
To set the longer expiry time, I try:
$c-config-{session}{expires} = 31536000 if
$c-req-param('remember_me');
I think that will make the cookie expire on the 1st January 1971. Try
+31536000.
I have a feeling that an undef expiry will result in a session cookie,
based on nothing more than guesswork and superstition.
Matt
___
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/
Re: [Catalyst] Session expiry per user
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 :
$c-config-{session}{expires} = 31536000 if
$c-req-param('remember_me');
that works only once. When I request another page on the site, the
param 'remember_me' is not set so the sessions falls back to 1 hour (tha
value I've put by default).
I have a feeling that an undef expiry will result in a session cookie,
based on nothing more than guesswork and superstition.
Halas, 'undef' is like '0', the session expires immediately :-(
Regards,
--
-- \^/--
---/ O \-----
-- | |/ \| Alexandre (Midnite) Jousset | --
---|___|-----
___
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/
Re: [Catalyst] Session expiry per user
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 to come from the line :
$c-config-{session}{expires} = 31536000 if
$c-req-param('remember_me');
that works only once. When I request another page on the site, the
param 'remember_me' is not set so the sessions falls back to 1 hour
(tha value I've put by default).
Ah, I missed the fact that you were accessing the cookies via a session
plugin, I thought you were setting them directly.
Would it be horribly perverse to store the expiry interval time (or the
remember_me bool) in the session?
$c-config-{session}{expires} = 31536000 if $c-session-{remember_me};
I have a feeling that an undef expiry will result in a session
cookie, based on nothing more than guesswork and superstition.
Catatlyst::Plugin::Session::State::Cookie says:
cookie_expires
Number of seconds from now you want to elapse before cookie will
expire. Set to 0 to create a session cookie, ie one which
will die
when the user’s browser is shut down.
Matt
___
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/
Re: [Catalyst] Session expiry per user
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
remember her (i.e. set expiry time to 1 year).
There's a plugin that is designed for that:
http://search.cpan.org/~nuffin/Catalyst-Plugin-Session-DynamicExpiry-0.02/lib/Catalyst/Plugin/Session/DynamicExpiry.pm
I'm not using it, but I looked at it in detail one day and had some
problems. I think I posted a patch. Yes, December 5th with the
subject Patch for Catalyst::Plugin::Session::DynamicExpiry
$c-config-{session}{expires} = 31536000 if $c-req-param('remember_me');
That's per process.
--
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/
Re: [Catalyst] Session expiry per user
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 ) {
$c-config-{session}-{expires} =
$c-session-{per_user_expiry}
|| $c-config-{session}-{expires};
$c-session_expires(1);
return 1;
}
}
set $c-session-{per_user_expiry} if you want a different expiry.
$c-session_expires(1) does all the stuff like setting cookies etc.
___
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/
Re: [Catalyst] Session expiry per user
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:
http://search.cpan.org/~nuffin/Catalyst-Plugin-Session-DynamicExpiry-0.02/lib/Catalyst/Plugin/Session/DynamicExpiry.pm
I'm not using it, but I looked at it in detail one day and had some
problems. I think I posted a patch. Yes, December 5th with the
subject Patch for Catalyst::Plugin::Session::DynamicExpiry
You posted a patch against a version 0.03. On CPAN the version is 0.02.
I googled to find the SVN but with no luck. Can you tell me where it is
please?
I've also found a Catalyst::Plugin::Session::DynamicExpiry::Cookie (not
on CPAN) that does the job.
I've spent a lot of time on it because Firefox *keeps session cookies*
when you close all tabs and ask it to restore session on
reopen.. Maybe it's FF that does this, maybe it's an extension,
I don't know. The fact is that I've had to close the FF tab before the
FF window in order to dismiss the cookie...
I still have problems with the cookie TTL and the session TTL. With the
module cited above, it does not seem to take into account my setting:
$c-session_time_to_live(31536000) if $c-req-param('rme');
and instead use the default session TTL (2 hours, I see that in my
`sessions` table).
Maybe I'm mixing wrongly session TTL and cookie TTL but I thought
$c-session_time_to_live(x) refered to session, not cookie. However it
seems to refer to cookie.
Anyway, with setting session TTL to 1 year, it now works as I want
(maybe not as it should?).
Thanks a lot to you all!
PS : After some thinking I believe I start to understant it all ;-) but
it's very confusing...
--
-- \^/--
---/ O \-----
-- | |/ \| Alexandre (Midnite) Jousset | --
---|___|-----
___
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/
Re: [Catalyst] Session Expiry
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. A cache is just a cache. Don't rely on them (particularly memcahced) to keep data around until you told it you would like it to expire at - there is no guarantee of this happening, especially under heavy load. Ash ___ 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/
Re: [Catalyst] Session Expiry
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. Not quite true. It would look like it fixes it for most cases. A cache is just a cache. Don't rely on them (particularly memcahced) to keep data around until you told it you would like it to expire at - there is no guarantee of this happening, especially under heavy load. Yes, very true. A cache is a cache. And the database server could blow up, too. What we are talking about is a situation where the session data is (seemingly) suppose to persist for X seconds between requests, but it's instead persisting X seconds between updates to the session (which may not be every request). It appears from the design of the Session plugin that it's suppose to persist X seconds between requests (the expires entry). So, it looks like a design problem. The fact that you might be using a store that deletes entries for other reasons than expire time is another issue. -- 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/
Re: [Catalyst] Session Expiry
* 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 would look like it fixes it for most cases. A cache is just a cache. Don't rely on them (particularly memcahced) to keep data around until you told it you would like it to expire at - there is no guarantee of this happening, especially under heavy load. Yeah. I think we've covered this about 1000 times on the list, so I didn't say anything. I still think using a lossy storage mechanism for data you don't want to lose is silly. I hate it when $SITE_I_VISIT loses my login session; use.perl does this all the time... reddit does it occasionally. It's annoying, and at some time you're going to have to shut off your memcached machine. Then all your users have to re-log-in. Regards, Jonathan Rockway ___ 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/
Re: [Catalyst] Session Expiry
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 $c-config-{session}{expires}
time. Still, that doesn't *solve* the issue.
but it does solve the issue, if the issue is having 2 different expires settings
to keep in sync.
seems like the Cache store should reset the expires time on the session data
each time, rather than having a separate 'expires' entry in the cache. AFAIK it
is the only session store class to do that.
I don't know if that is a fault with how the Cache store itself is implemented,
or with the implementation of the superclass.
--
Peter Karman . http://peknet.com/ . [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/
Re: [Catalyst] Session Expiry
* 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 things due to its expiry
not being updated?
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. It's annoying to have two
expiration times, but that can be easily worked around. (Set cache
expiration every time you update __expires, or just set it to 2038 and
hope Catalyst expires it for you.)
Regards,
Jonathan Rockway
___
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/
Re: [Catalyst] Session Expiry
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} doesn't get updated, or is
the problem that the Cache backend is losing things due to its expiry
not being updated?
Well, I think it's both, althogh I'm not sure __expires is used any
more.
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. It's annoying to have two
expiration times, but that can be easily worked around. (Set cache
expiration every time you update __expires, or just set it to 2038 and
hope Catalyst expires it for you.)
Session::Store::Cache is a pretty thin layer so I'm not sure it's that
plugin's problem. It overrides store_session_data and the session
plugin uses that to store both the expires and session (and flash)
entities. So they all get the same expire time.
Maybe if the Session::Store::Cache plugin overrode
_save_session_expires() and _save_session() so they could have
separate expires times that might work. But, that's overriding
private methods and I'm not sure giving the session store a huge
expiry isn't more of a hack than a solution.
So, really, the problem is simply that the session plugin updates the
expires store every request and not the session store. And if the
store has it's own expiry (like memcached) then if the session is
not updated it will expire before the updated-every-request expires
one will. But, maybe the assumption was that the store would not have
its own expiry mechanism and it would all be handled by the Session
plugin.
What's the point of having a separate expires store that is updated
every request? So that we save updating the session every request
because it's more data to write to the store?
As it turns out, it's actually more expensive since now I have to
force a session save in addition to the expires save every request.
So the use of a __expires entry in the session would be more
efficient. (Not that it's a huge problem in the larger scope of the
request.)
If it's likely that an application might not update the session data
often (triggering a session store), and it's likely that the store
manages an expires time, then maybe the Session plugin should not use
Object::Signature to determine when to store the session, and rather
just update it 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/
