[Seaside] Session expiration and data cleaning
diego.lont at delware.nl
Tue Feb 25 10:53:17 UTC 2014
Maybe I am stupid, but if you depend on your sessions to expire to release key resources, I think this always means you have a security hazard. One should not rely on what the user does or does not. So I think the question should be: why is it important to know the exact time the session expires? What data do you need to clear, that it cannot wait to be cleared?
On 25 Feb 2014, at 08:53, jtuchel at objektfabrik.de wrote:
> it seems this is a common request, because it pops up from time to time. Seems people are unhappy about the fact that the time sessions may exist after their expiry is undefined. So what Karsten describes is probably a feature request...
> For our application we decided to design our session classes to not hold on to critical resources for longer that they need them, so that their lingering after expiry is not an issue. For peace of mind, it would be nicer if sessions just got killed once they've expired.
> Am 25.02.14 08:45, schrieb Karsten Kusche:
>> i thought that’s not 10 created sessions but 10 queries to the cache. You can also create a background timer and let it access the application’s cache and trigger a reap.
>> Kind Regards
>> Karsten Kusche - Dipl. Inf. - karsten at heeg.de
>> Georg Heeg eK - Köthen
>> Handelsregister: Amtsgericht Dortmund A 12812
>> Am Dienstag, 25. Februar 2014 um 08:40 schrieb Dave:
>>> No hint?
>>> View this message in context: http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746106.html
>>> Sent from the Seaside General mailing list archive at Nabble.com.
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
On 24 Feb 2014, at 11:39, Dave <lasmiste at gmail.com> wrote:
> I need to clear some data on session expiration. After several searches and
> attempts I discovered that sessions expired after #cacheTimeout but they are
> unregistered only after the creation of 10 more sessions, see here:
> you can change it reducing the cacheReapInterval, for example if you want to
> unregister your session after 2 sessions are created, you can write:
> myApplication cache reapingStrategy configuration at:#cacheReapInterval put:
> and you can test it creating a MySession:
> super unregistered.
> Time now inspect.
> then associate it to your application:
> myApplication preferenceAt: #sessionClass put: MySession.
> and looking at the time of inspection, so far so good.
> I need to clean my data when the session expires (with or without a
> timeout), not when the session expires *and* after 2 or more sessions are
> Have you any suggestion?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside