Thanks for the info. I really don't need an auto-logout feature, but I wanted to understand my options if Wt insisted on timing out.
On Apr 6, 2010, at 4:22 AM, Koen Deforche wrote: > Hey Joseph, > > 2010/4/3 Joseph VanAndel <[email protected]>: >> If I leave my Wt application running long enough, and don't click something >> on the browser window for 10+ minutes, eventually I see a message on the >> console like: >> >> [2010-Apr-02 16:45:18.470350] 15548 [/ kmUNnsgToijqQ3mL] [notice] "Timeout: >> expiring" >> RadarControl::~RadarControl called > > That is not how it is supposed to behave though: Wt choses not to let > a session expire as long as the browser window is open. Thus: you > should only see a session expiring when the user has browsed away from > the application. The underlying mechanism uses keep-alive messages > (which are sent twice per "timeout-period", and which prevent the > session from expiring). > >> 1) How can I configure how long the timeout is? > > In wt_config.xml, see > http://www.webtoolkit.eu/wt/doc/reference/html/overview.html#config_session > >> 2) Other than seeing that the destructor of my Application class (which >> inherits from Wt::WApplication) is being called, how do I prepare to save >> any application state? > > There is currently no other way than through the destructor of your > application or widgets. I can see it could be useful to propagate a > virtual method call (e.g. timeout()) through the application to allow > the application to more explicitly react to a timeout, since a widget > destructor is also called when you delete the widget (obviously). > >> 3) Does Wt provide any hooks to let me warn the user that their session is >> about to expire? This is common in banking applications - after a period of >> idleness, my bank's website posts a dialog warning me that my session is >> about to be terminated. If I ignore it, I get logged off. If I click "OK" >> before the auto-logout, I stay logged in. > > Given my first comment, this would require an active auto-logout > feature to be implemented. You could do this using a WTimer, which you > reset each time you get a real event, but that is indeed cumbersome, > since you need to be sure to reset the timer in each slot connected to > an event signal. > > I think there are two other options that make sense for the banking scenario: > - allow to customize the keep-alive message stream by requiring the > user to confirm a keep-alive message. This would be essentially a > JavaScript-solution. > - extend WApplication::notify() so that you can query the event if it > is a user event. Otherwise (it is e.g. a keep-alive message), you can > react by displaying a WDialog... This would essentially be a > server-side solution. > > Both approaches are not that much work really, so we could consider > having both of them. > > Does that answer your question and would that be the kind of solution > you are looking for? > > Regards, > koen > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > witty-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
