My76Strat wrote:

In the description where it says "expire the login session after a certain amount of time" it should state "expire the login session after a certain amount of time inactive" to align with the stated desire as discussed at wp:vmt. Clearly it is not desired that an active session should forcefully expire in the midst of activity on a timed basis alone. An additional feature was requested as prudent which would allow an account forcefully expired for inactivity to restore the entire session upon logging in; to prevent the loss of data incurred by the forced expiration. Please consider these stipulations as if they were included in the original description; they are included in the original request.

Some brainstorming:

• "Expiring" a session is easy enough with SessionManager, just store the last-active time in the session (either in the data or use the SessionMetadata hook to save it in the metadata) and use the SessionCheckInfo hook to invalidate it if the time isn't recent enough.
• OTOH, determining when a user was last active isn't so easy since we don't want to be having every page read having to write to the session to update an activity timestamp.
  • You'd need to decide on a granularity (G) for the activity timestamps that results in an acceptable rate of writes, and accept that an expiry of T minutes might really expire after G-ε minutes of reading followed by only T-G+ε minutes of real inactivity.
• "Restoring" the session on login is another tricky issue, particularly since the things the server considers as being in the session are not necessarily the things the user would consider.
  • For example, a user might think of a situation like "I'm editing a page, the session expires, I leave the edit form to log in, then come back and the edit-in-progress should still be there." But the data in the edit form isn't maintained in the session (it's in the state of the edit form that the user left), so it's not something the server could easily "restore" after login.
• Expiring the session in this manner would interact oddly with the "remember me" checkbox on the login form: either the early expiration would override the remembering (but only when $wgObjectCacheSessionExpiry isn't also exceeded), or the remembering would override the expiration so the only effect would be an increase in the "Sorry! We could not process your edit due to a loss of session data" (but still being logged in) when editing. So you might just want to skip early expiry entirely if the session is 'remembered'.