Meteor-feature-requests: Support for removing stale sessions after X minutes of inactivity (not only X days)

[SimonSimCity]

Currently, the package accounts-base has a configuration loginExpirationInDays which is used to evaluate if a session is stale or still active. Quite some people already asked for a setting, where this can be configured on a minutes-basis.

I just tried to set it to a decimal number - just for trying if it works. I got it working down to a value of 0.05, which is equivalent to 1.2 hours.

My request:

Evaluate why it isn't possible to use a value like 0.010416 which equates to 15 minutes. See if this setting shouldn't be renamed to loginExpirationInSeconds or something similar to show, that it's also possible to enter a lower value here.

[SimonSimCity]

For those who can't wait ... https://github.com/lindleycb/meteor-stale-session/ has a similar concept, where you also forcibly can remove sessions that are stale.

[SimonSimCity]

After some testing I found out that the setting loginExpirationInDays wasn't fully doing what I wanted. It seems that this isn't about stale sessions, but it's a set of days after which you will have to log in again - no matter if you've been active in the meanwhile.

Is this now a bug or is it an undocumented feature ..?

The documentation I found actually isn't really clear: https://docs.meteor.com/api/accounts-multi.html#AccountsCommon-config

It only states:

The number of days from when a user logs in until their token expires and they are logged out. Defaults to 90. Set to null to disable login expiration.

What I did:

I tried a bit around and tested here and there. It seems that the user is logged out one hour before the time is up. Maybe the constant MIN_TOKEN_LIFETIME_CAP_SECS plays a role in there, but if it is, it's done the wrong way, because it substracts one hour from the loginExpirationInDays value. Setting loginExpirationInDays to 0.05, which should be one hour and twelve minutes, therefore caused that I was kicked out after twelve minutes. This explains why a value lower than 0.041666667 - like 0.0104167 for 15 minutes - didn't work...

But if I set it to 0.05, it kicks me out after twelve minutes - no matter what I do in the meanwhile. Is this the purpose of this feature? It seems like a user MUST log in again, latest after this time has run out. If this is by intention, the documentation should be clearer here.

So, please:

1. Update the documentation of loginExpirationInDays to explain clearly that this is a max-session-time (the longest time a session can last)
2. Fix the bug that the session actually is killed one hour before loginExpirationInDays is reached
3. Evaluate if a feature like https://github.com/lindleycb/meteor-stale-session/ (which is what I actually wanted) is worth putting into the core.

[mattiLeBlanc]

I would like to see this implemented too, yes please

[SimonSimCity]

@hwillson just because you seem to be in this topic: Could you please check if what I write here is correct?

I've done some research today and found out the following:

Server: After Meteor is started, the server checks every 10 minutes if there are tokens on the server, where the services.resume.loginTokens.when is older than loginExpirationInDays, which is 90 days by default and 100 * 365 days if null. This logic starts here by calling Accounts._expireTokens().

Client: The client now has two mechanisms:

1. triggered by DDP.onReconnect() and
2. another one when initializing the Account on the client

which both check on Accounts. _tokenExpiresSoon () and call Account. _unstoreLoginToken() and thereby destroy the users session on the client side if the key Meteor.loginTokenExpires in the local storage (which is services.resume.loginTokens.when, provided the server on login) is older than either a tenth of loginExpirationInDays or 1 hour, whatever is greater.

---

This concept leaves us actually with a good deal of work for ourselves, and here are two scenarios I want to dive into:

1. A user should log in once and his session should have a maximum lifetime. After this time the user MUST log in again. Solution: Congrats, the feature fits for you as is.

2. A user should log in once and his session should expire if he is inactive for a definite time.

Now ... a question back on you: Since we're developing single-page-apps on the browser ... what would you see as an activity? Mouse move, a click or tab or rather when a method is sent to the server? Then ... what if your user is offline for longer than this period?

Plus there's no mechanism to kick the user out if his session expired while he was offline (excepted for this Accounts. _tokenExpiresSoon () which kicks the user out before it actually expired or the synchronization to the server after his session got kicked there - but those won't trigger if he remains offline).

---

I suggest that the documentation for Meteor needs an update reflecting this report. There are many bug reports out there who only result of a wrong understanding of loginExpirationInDays, as mine here.

It should also be noted there that we have quite a couple of packages covering quite some additions out in the Meteor Atmosphere:

Server-side timeout:

This concept is to reset services.resume.loginTokens.when to new Date() + loginExpirationInDays after each activity.

• https://atmospherejs.com/zuuk/stale-session
• https://atmospherejs.com/hotpea/stale-session-with-callback - a fork of zuuk's package, adding callbacks
• https://atmospherejs.com/jeverduzco/meteor-session-manager - which is an exact copy of the package zuuk wrote (I diff'ed it)
• https://atmospherejs.com/mrt/session-timeout which is hosted on GitHub at https://github.com/recursivefaults/meteor-session-timeout but it _seems abandoned_

Purely client-side timeout:

The downside with the server-side approach is that your session will also be removed if you were offline for more than loginExpirationInDays ... At least when you then come back online and the server synchronizes your profile.

• https://atmospherejs.com/simonsimcity/client-session-timeout - which kicks the user after the user "disabled" the browser for longer than the defined timeout. This could be done by putting your system into

[lynchem]

This really has to be in the docs. Something like :
loginExpirationInDays: If you use fractions beware that the session will expire one hour before so the min value to use is 1/24. So: (loginExpirationInHours + 1 / 24)

[evolross]

Here it is March 2020 and I just ran into all this. Had random logouts on my production app during critical customer use-cases. Total misunderstanding of loginExpirationInDays due to incomplete documentation. _Totally_ assumed it accounted for user activity. I'll update the doc and send a PR.

[JoshMcCullough]

If I'm reading this correctly, we can set loginExpirationInDays to a fraction. So if we wanted a login token to expire and force re-login after 12 hours, we could set it to .5 -- yes yes?

[SimonSimCity]

@JoshMcCullough According to my findings you'd have to set it one hour higher:

Setting loginExpirationInDays to 0.05, which should be one hour and twelve minutes, therefore caused that I was kicked out after twelve minutes.
https://github.com/meteor/meteor-feature-requests/issues/119#issuecomment-309414922

[StorytellerCZ]

@SimonSimCity Does https://github.com/meteor/meteor/pull/11366 satisfy your needs?

[SimonSimCity]

@StorytellerCZ At first glance it seems to fit the purpose. I won't have much time for evaluation though since I've moved away from meteor in my daily work. Some of my private projects are on Meteor still, so I'm not completely away. I'll close it for now - feel free to reopen if it doesn't quite fit for anyone in need.