Page MenuHomePhabricator

Provide option to force a login session to end within a certain time
Open, LowPublicFeature


This is similar to bug 26538, but for the user side I presume

It is requested that people be able to set an option that would allow them to configure the duration time of their login session.

Use case:
Multiple Wikipedia users sharing the same computer/browser in a household.

We have seen a number of times now that people/siblings/partners accidentally use each others accounts in this situation. The option would forcefully expire the login session after a certain amount of time, independent of the cookie expiration of the browser.

Version: 1.22.0
Severity: enhancement
See Also:



Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:06 AM
bzimport set Reference to bz53156.
bzimport added a subscriber: Unknown Object (MLST).

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'.
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM