On Wed, Jun 10, 2009 at 10:26:36AM +0100, Tomas Doran wrote: > I specifically wrote a test for this, however it's a test and not > comprehensive, and I can't see without spending time to take a detailed > look again if your case is proved or disproved by this test.
This is a problem in our code only. Sorry, I should have followed up. A test in our app turned up the session fixation. I then looked at the session code: sub session { my $c = shift; $c->_session || $c->_load_session || do { $c->create_session_id_if_needed; $c->initialize_session_data; }; } and wondered why it would not need a new session id any time it was creating a new session. Is it to avoid expensive session id creation? Thus my question: > My question is can anyone see why not just do this: > > sub session { > my $c = shift; > > $c->_session || $c->_load_session || do { > $c->create_session_id; > $c->initialize_session_data; > }; > } We use a custom memcached plugin for session store[1]. Memcached supports expiring keys and the application does not bother with "Your session expired" messages. Sessions either exist or they don't after they expired. We update the session almost every request, so the expires gets updated every request so the extra expires fetch and store was not important. So, to avoid the extra fetch and store each request of just the expires data we override the session expires methods which is where the session key is deleted if the session has expired or does not exist. That is, we prevented the session id from being deleted. Then create_session_id_if_needed() simply returned the supplied id. It's our own fault for overriding private methods. [1] Yes, it's a store, not a cache. -- Bill Moseley. mose...@hank.org Sent from my iMutt _______________________________________________ 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/