[Catalyst] Session trouble

[Bill Moseley]

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
moseley at hank.org