On Mon, Jul 16, 2007 at 07:20:36PM +0300, Yuval Kogman wrote: > Hi, > > no update yet, been terribly busy (the client is not being very nice > to us). > > If you need comaint to release yourself let me know. You should have > commit access, right?
I can take another stab at it -- I had spent a few hours throwing warn and cluck messages into the code to try and figure out what was going on. My eyes started to glaze over after a while. I like how you refactored the plugins quite a bit. But, I wish there were comments in the code to give a little context. That would make debugging by people unfamiliar with the code easier. I also find NEXT makes it a bit more complicated when trying to follow stack traces. Would you have a few minutes to at least verify if you can reproduce the problem with the test application I sent? I'd like to rule out any thing that might be due to my environment. What seems to be happening (and this was happening with a previous bit of code from a week or two back) was that I was accessing the session after it had been cleared/reset at the "end" of finalize (or something like that). So, that was creating a new sessionid and thus storing the session data under a different id than the id used in the cookie. This is the code that's getting me now: sub calculate_session_cookie_expires { my $c = shift; return $c->session->{remember_me} ? $c->session_expires : $c->NEXT::calculate_session_cookie_expires; } I think the quick fix would be to stuff the remember_me flag in the stash earlier in the request and look at the stash instead of the session (to avoid creating a new sessionid by calling $c->session). I thought it might be a matter or moving $c->_clear_session_instance_data later in the request cycle, but it seems that's not really the problem. I was seeing multiple sessions created (and cleared) in the case of a request with a cookie with an id for an expired session -- which doesn't seem right. Oh, and to note again: I think the behavior of dieing on invalid session id format is not right. The id should just be ignored in that case and a new cookie sent. If someone ends up with a bad cookie (or the cookie format changes) could result in a lockout. Thanks, -- Bill Moseley [EMAIL PROTECTED] _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/