On 10 Dec 2008, at 22:25, Bill Moseley wrote:
When Catalyst::Session fetches an existing session it records its
"signature" which it then compare with the session data at the end
of the request to decide if the session should be written.
So, if you look at the session every request, for ex
On Tue, Dec 16, 2008 at 06:20:43PM +, Tomas Doran wrote:
> Do you fancy writing a test for the issue so we can actually prove it is
> gone?
Well, it would could be something like this:
use lib "t/lib";
use Test::WWW::Mechanize::Catalyst "SessionTestApp";
$SessionTestApp::store_session_data
On 17 Dec 2008, at 05:11, Bill Moseley wrote:
On Tue, Dec 16, 2008 at 06:20:43PM +, Tomas Doran wrote:
Do you fancy writing a test for the issue so we can actually prove
it is
gone?
Well, it would could be something like this:
Again looks perfectly reasonable to me :)
Apologies if
On Wed, Dec 17, 2008 at 08:34:36AM +, Tomas Doran wrote:
>
> On 17 Dec 2008, at 05:11, Bill Moseley wrote:
>
>> On Tue, Dec 16, 2008 at 06:20:43PM +, Tomas Doran wrote:
>>> Do you fancy writing a test for the issue so we can actually prove
>>> it is
>>> gone?
>>
>> Well, it would could be
On 17 Dec 2008, at 13:11, Bill Moseley wrote:
On Wed, Dec 17, 2008 at 08:34:36AM +, Tomas Doran wrote:
Apologies if I wasn't being clear perviously - could you convert your
suggested changes and test into a diff against the distribution which
someone could just apply with patch, rather th
On Mon, Dec 29, 2008 at 06:10:34PM +, Tomas Doran wrote:
>
> Session handling could do with refactoring as-per the authentication
> plugins, so that the store and state were not plugins themselves, this
> would make things a lot 'nicer'.
>
> However, in the shorter term, providing people wit