Can anyone confirm I’m on the right track here re having an approach to manage session timeout etc:
Assumption: Using active_record session storage.
Don’t set a session(cookie) "
expires_in" time as we will manage this manually.
QUESTION: This is a particular assumption I was after feedback on. I’m assuming that as I’m managing expiry manually in my application that trying to incorporate use of the cookie session expiry time as well would complicate things??
For each request (application.rb before_filter(s)):
Assumption - Rails keeps the sessions table "
" field populated after each request so that it is up to date
check to see whether the session has expired (manually check the sessions table “updated_at” field and compare with the applications timeout peiod) - if yes then expire session then "
reset_session". This seems to remove the session record from the sessions table.(?)
If the user was LOGGED_IN to the application then redirect them back to the LOGIN PAGE.
Clean up any sessions table records that are older than say 2 x LengthOfSessionTime (use of SQL direct targetted at the session table)
Query sessions table to see how many users are logged in, for display in the footer. Capture (a) logged in users and (b) Anonymous users totals.
At login:
Update a custom sessions table column (user_id) with the user_id. Do this via the approach “session.model.user_id =
user.id”
I assume when the:
a) user accesses the site and the session is expired this in itself will not remove the session record from the sessions table. One could manually expire the session in this case I guess as I think this deletes the row but I assume one would need to be careful re when this is done. You would still want the user to have a http session so to speak, however you may want them to have to logon again for any protected items.
b) session expires & the user is not interacting with the site - sessions would remain in the table would need another mechanism applied
Tks Al for confirming I’m on the right track - thanks too for the code snippet - the database_cleanup method seems to iterate through the sessions however…wouldn’t this be an overhead, i.e. a single SQL command would be quicker no? Was there a reason to want to iterate through them like this?
The session expiry probably wont remove the session record from the db
but the best approach here is to set up a cron job to clear out old
session records (say those more than a day old).
re Session Expiry - is there any reason to maintain an active session for an anonymous user (i.e. one that hasn’t logged on)?
Here are my thoughts re what needs handling for an incoming HTTP request, focused on session handling (
i.e. assuming the authorization checks & login process are already in place)
HTTP Request Incoming (table shows current state => action to take)
session expired/loggedOn/protectedPage => LogOffUser + logon page with “your session has expired” message
session expired/loggedOn/nonProtectedPage => LogOffUser + goto page
session expired/Anonymous/protectedPage => logOnPage
session expired/Anonymous/nonProtectedPage => logon page
session ok /loggedOn/protectedPage => normalAuthorisationCheck
session ok /loggedOn/nonProtectedPage => goto page
session ok /Anonymous/protectedPage => goto logonPage
session ok /Anonymous/nonProtectedPage => goto page
Findings:
[1] From a session perspective only need to really pick up on the case where the user is logged in & the session has expired, in which case forcing user logoff is then the key next step.
[2] Occasionally clean up old session records in database (i.e. sessions table), however this does not tie directly in with the above process. i.e. can be thought of as a separate thread of activity.
