Here is the agreed feature description for session timeouts, captured from freenode/#aeolus:
There is an admin setting for session time in a config file, and...
<jayg> then we check after that time to ask if they are there
(This could mean "pop up a javascript warning)
<jayg> if no response after 30 seconds, log them out <jayg> feature described
<hewbrocca> And <hewbrocca> what resets the timer? <hewbrocca> Do we have a way to differentiate backbone refreshes from real user requests? [11:25] <matty_dubs> Non-Backbone activity == "activity"? Is that fair? <jayg> a page refresh resets, I would think - or, clicking 'yes, I am still here'
Seems to me we would do this in two stages:
1. Implement the timeout itself, ignoring backbone requests and reading the desired time before session expiration from a system configuration setting
2. Implement a "warning, you're about to timeout" dialog. This could be entirely client-side, or it could be a backbone request to the server for time-before-expiration
Is this sufficient?
--Hugh
On 07/27/2012 10:43 AM, Hugh Brock wrote:
Here is the agreed feature description for session timeouts, captured from freenode/#aeolus:
There is an admin setting for session time in a config file, and...
<jayg> then we check after that time to ask if they are there
(This could mean "pop up a javascript warning)
<jayg> if no response after 30 seconds, log them out <jayg> feature described
<hewbrocca> And <hewbrocca> what resets the timer? <hewbrocca> Do we have a way to differentiate backbone refreshes from real user requests? [11:25] <matty_dubs> Non-Backbone activity == "activity"? Is that fair? <jayg> a page refresh resets, I would think - or, clicking 'yes, I am still here'
Seems to me we would do this in two stages:
- Implement the timeout itself, ignoring backbone requests and
reading the desired time before session expiration from a system configuration setting
- Implement a "warning, you're about to timeout" dialog. This could
be entirely client-side, or it could be a backbone request to the server for time-before-expiration
Is this sufficient?
--Hugh
This seems about right to me. To clarify 1) -- ignoring backbone requests means "backbone requests don't count as activity, and sessions time out even while pages are being auto-refreshed", rather than "ignoring the issue of backbone requests"
Also, we need to make sure whatever we do also properly expires/removes API sessions (currently created once per API request, set to expire in 2 minutes).
I don't believe 2) is in scope for the current task, which should just be 1). When we discussed this on the sprint planning call, 1) is precisely what I was talking about doing here.
There's also probably a 3) -- at some point we need to stop creating a new session on each API request, instead either doing something with a session cache of sorts (i.e. maintain at most one API session per user), or with tokens, or something else to avoid the LDAP lookup per request.
Scott
aeolus-devel@lists.fedorahosted.org