[Catalyst] Announcement - New session plugins

[John Lifsey - Contractor -]

What I tend to do is set two session variables one for creation one for 
last hit and timeouts for each of them. Then upon every request kill the 
sessions that are out of time. Of course this is with my own sloppy 
non-catalyst code that has access to a DB for storage, so its probably moot.

Andreas Marienborg wrote:
>
> On 8. nov. 2005, at 10.16, Yuval Kogman wrote:
>
>> On Mon, Nov 07, 2005 at 20:25:12 -0800, Bill Moseley wrote:
>>> On Tue, Nov 01, 2005 at 10:48:37PM +0200, Yuval Kogman wrote:
>>>>     use Catalyst qw/Session Session::Store::FastMmap 
>>>> Session::State::Cookie/
>>>
>>> There's a few options I'm looking for here.  At least I think I'm
>>> looking for.
>>>
>>> - I'd like the option in Session::State::Cookie to *not* set
>>> expires on the cookie.  I'd like the action of closing the client to
>>> drop the session.  Or is there a better way to handle the requirement
>>> for sessions to vanish when the client is closed?
>>
>> Technically this is problematic: The browser will never notify the
>> server when the session data expires, causing a storage leak
>> (references to the session ID will be lost on browser close, but the
>> store can't know that).
>>
>> Can anybody with more web-smarts than me figure out what is the best
>> policy for this?
>>
>
> All I know is that 90% of all sessions elsewhere are expire on close 
> of browser, so it must be dealt with. We cannot have a sessionsystem 
> not supporting this.
>
> Technically, you could have an "onclose" or "onunload" handler do some 
> ajax stuff, but it's not generally a good solution, as it wont happen 
> on quit etc.
>
> Yes, there will be a leak, but what sort of data are people storing in 
> sessions, if that quickly becomes a massive problem? It must be the 
> responsibility of the developer to deal with it regardless, as they 
> are the ones knowing the options. But the option to _NOT_ set an 
> expires on the session cookie is a must have in my eyes.
>
> Great work non-theless, it seems most people are happy with the new 
> approach, but I havnt had time for handson testing myself yet
>
> andreas
>
>
>
> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4082 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20051108/4cbe4659/smime-0001.bin