> > browser will no longer transmit session cookies for old sessions). >> > > But this is "normal" case - attacker can use/transmit "session cookies for > old sessions" (which is where the whole discussion started) >
I was simply pointing out that sessions do not technically expire on the server side. The browser expires sessions by ceasing to return the session cookie. If an attacker steals the cookie and keeps sending it, then the server does nothing to expire the session. However, Auth logins can expire, but that is a different matter. > In any case, there is no process that can monitor sessions/logins for >> expiration automatically (i.e., no place for a "hook"). The only "events" >> that the framework can respond to are requests, but an inactive client is >> not making any requests, so there would be nothing to trigger an expiration >> check. >> > > I understand. I am not looking for "process". > > I want to know *which place in web2py code* "determines" that for a > normal request - session has expired and user should be redirected to > "login" page - before the requested page is served ? (It attaches > appropriate _next to the login form - so that after successful > authentication - user is taken to the page s/he requested) > This is login expiration, and it is checked in Auth.__init__: https://github.com/web2py/web2py/blob/master/gluon/tools.py#L1279 Note, there is no "hook" that will allow you to determine when login has expired. One trick that might work, though, would be to check for the existence of session.auth (which implies the user is logged in) right before initializing Auth, and then check again right after -- if session.auth exists before but not after, this implies that the login had expired (and auth was therefore removed from the session). You could then use that as a cue to delete the old session file (you must record the session ID prior to initializing Auth, as the session will be renewed by Auth.__init__ if the login has expired). Of course, this only enables you to delete the session file upon an HTTP request of a logged in user whose login has expired. If the logged in user simply stops making requests, there will be no subsequent expiration checks to trigger the file deletion (you'll need sessions2trash to catch those files). > Will adding following (from sessions2trash.py docstring) be better if > called *immediately after successful login* ? > This IMO ensures that session files are deleted after login attempt - > especially when login was "forced" by the web2py framework due to expired > session > > # Delete session in a module (move to the modules folder) > from sessions2trash import single_loop > def delete_sessions(): > single_loop() > > I'm not sure you want to run that in your app code, as it will loop through all the session files. You could consider triggering a task via the scheduler, but could be inefficient to do all that checking if you've got lots of logins. Probably better to delete individually identified session files when dealing with requests from individual users. Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
