[Seaside] WAApplication and WASession subclassing and expiry, again

[Johan Brichau]

Hi Tim,

Unless you want to share state across all your sessions, you should not be subclassing WAApplication.

Default Seaside configuration comes with WALastAccessExpiryPolicy configured at 600 seconds, which removes sessions from the session cache when they have not been accessed for more than 10 minutes.
This is done every time Seaside serves a request.

If you override NPSession>>unregistered you can perform specific actions when the session is unregistered.
Mind that you _must_ make a supercall in that override, or your sessions will not be removed.

WAExpirySession is just an example where the unregistration and registration is counted. It does nothing special.

If your sessions do not expire, it would be helpful to know what your config is.

cheers
Johan

> On 19 May 2019, at 18:01, Tim Johnson <digit at sonic.net> wrote:
> 
> Hi,
> 
> The current recommended practice seems to be to subclass WAApplication[1][5][6] especially if one wants to handle session expiration/expiry[2].  One must then register the WAApplication as the application root, and use other tricks (override another method) to get one's component (or task) into the flow [3], it seems.  
> 
> I am a student of the HPI book[4] (since many years ago) which trains me to keep all of my application logic (model) in my custom WASession subclass.  If I am to also subclass WAApplication, am I to move all of my application logic to that instead[7]?  
> 
> I ask because I am recently dealing with the first Seaside app I have deployed to the wider internet (instead of an intranet), and sessions are not expiring, a'la [4].  They will stick around for days.  My app also seems to lock up after about 24 hours which is getting annoying.  :)     
> 
> When I look at implementors and senders of #unregistered[8], I see that perhaps I should now be subclassing WAExpirySession instead of WASession if I want my sessions to expire (or if I want to hook into the expiration process)...?  I cannot find much documentation on the net regarding WAExpirySession.
> 
> Also, I am on Seaside 3.2.2 — might it help to upgrade?
> 
> Thanks,
> Tim
> 
> 
> [1] https://github.com/SeasideSt/Seaside/issues/1113 <https://github.com/SeasideSt/Seaside/issues/1113>
> 
> [2] http://www.seaside.st/documentation/faq/how-to#254979024 <http://www.seaside.st/documentation/faq/how-to#254979024>
> 
> [3] https://kentreis.wordpress.com/2008/01/22/ <https://kentreis.wordpress.com/2008/01/22/>
> 
> [4] http://forum.world.st/Seaside-sessions-not-being-either-unregistered-or-GCed-td4835659.html#none <http://forum.world.st/Seaside-sessions-not-being-either-unregistered-or-GCed-td4835659.html#none>
> 
> [5] https://stackoverflow.com/questions/43824202/catching-the-session-expiry-in-pharo-seaside-3-2 <https://stackoverflow.com/questions/43824202/catching-the-session-expiry-in-pharo-seaside-3-2>
> 
> [6] https://stackoverflow.com/questions/41173162/how-to-configure-seaside-3-2-session-timeouts-age <https://stackoverflow.com/questions/41173162/how-to-configure-seaside-3-2-session-timeouts-age>
> 
> [7] http://forum.world.st/Subclass-WAApplication-td98970.html <http://forum.world.st/Subclass-WAApplication-td98970.html>
> 
> [8] http://forum.world.st/Sharing-Seaside-URLs-between-users-security-what-is-actual-way-for-session-expiration-page-td4916451.html <http://forum.world.st/Sharing-Seaside-URLs-between-users-security-what-is-actual-way-for-session-expiration-page-td4916451.html>_______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20190525/3d7d4e83/attachment-0001.html>