An extension for the users to decide how long they want to stay online

TB54

I don't know if there was a change, but since a few days, i realize I de-connect quickly from the flarum forum if I'm not active, and have to re-login very regularly, which is annoying. That gave me the idea that I would have liked to have, in my settings, an option to ask me how long I want to stay online inactive (or at least maybe just one option to activate: keep me online as long as I didn't log out).

I don't know if it would be possible, or easy to do, but I think it would be practical to let the users decide that for themselves.

clarkwinkelmann

Flarum already has 2 different session "duration" options: regular and "remember me"

Regular is hard-coded to a specific duration and in the future it should be configurable via config.php or an extension.

"remember me" will keep the session active forever until you manually log out.

The session API technically allows to create more kinds of sessions with their own duration, but I don't think that's particularly useful when you already have the 2 built-in types of sessions.

TB54

clarkwinkelmann Flarum already has 2 different session "duration" options: regular and "remember me"

Is it in the settings? I don't find it.

clarkwinkelmann

TB54 in the login modal you should see a checkbox called "Remember me". When you login with that checkbox checked, the session type is set in the database and an additional cookie is set in the browser. Otherwise it's the regular session that will expire after 1 hour of inactivity.

When using a social login, it's generally always a "remember me" session (the visitor cannot choose) unless the extension author customized it.

luceos

So the requirement would be:

create an mit extension on either github.com or gitlab.com public repository
that adds another field to the log in page called session duration
❓️ with a dropdown with some values (default, 1 hour, 12 hours, 7 days)
based on the choice the user session is saved/active up to that duration

Needs investigation:

Does core allow overriding the session duration per log in attempt?

rob006

luceos Does core allow overriding the session duration per log in attempt?

Right now lifetime of session token is not only global, but pretty much hardcoded.

clarkwinkelmann

If the list of choices is known and does not accept arbitrary value, I would say the intended solution is to create one type of access token for each duration, and "hard-code" the duration in each one, just like the original. It should even be possible to dynamically create those token types without the need to have a separate class for each one in the source code.

The lifetime being hard-coded for a given token type is by design, because the value is used as part of the SQL queries for garbage collection, so there would be no way to have customizable duration per token with that kind of API. The old system prior to the big access token refactor of the last betas stored the expiration date in the token itself, but it came with its lot of problems too.

There are technically hacks that could be used to change the lifetime of an existing token type, but I would not recommend this solution if it can be avoided. Most notably, registering a new token class with the same type as the existing one will override its lifetime in both the middleware retrieval and garbage collection.

For a large number of arbitrary token lifetimes, the best solution isn't that much more complicated. Just have a single new token type, give it infinite lifetime, and handle its revocation separately without using the access token API. Ideally use a scheduled job, and just delete each token the minute it expires.

Still I'm not too sure why someone would need such a complicated system. If a user wants to stay connected, they can use the "remember me" feature.

The access token lifetime has no security benefit, because it's just the time since last activity. So implementing this feature as described couldn't be used to create limited time sessions that cannot be extended.

rob006

clarkwinkelmann If a user wants to stay connected, they can use the "remember me" feature.

Sometimes users does not want to be remembered, but also does not want o be logged out after 1 hour of inactivity. Right now you can choose between 5 years and 1 hour, and both values sounds quite extreme for me. I find it really odd that session access token does not respect session.lifetime config value and Flarum requires some ugly hacks to extend session lifetime.

luceos

clarkwinkelmann If the list of choices is known and does not accept arbitrary value, I would say the intended solution is to create one type of access token for each duration, and "hard-code" the duration in each one, just like the original. It should even be possible to dynamically create those token types without the need to have a separate class for each one in the source code.

The lifetime being hard-coded for a given token type is by design, because the value is used as part of the SQL queries for garbage collection, so there would be no way to have customizable duration per token with that kind of API. The old system prior to the big access token refactor of the last betas stored the expiration date in the token itself, but it came with its lot of problems too.

But what if we store token lifetime in the table? Garbage collection can still use that field to clear up the table, in addition it would reduce the need to create token types per lifetime length. I think that a token per session duration would create huge overhead, especially if these durations are to be configurable or extensible..

luceos

Seeing this proposal has no upvotes yet, I think we can delay action until there's more interest.

Thanks for both your feedback!

(I might have bumped this proposal by accident as I was going through proposals based on upvotes, but the sorting was off for a second)

clarkwinkelmann

luceos I don't remember how much of the reasoning was described in my original PR of those changes, but from what I remember, this was the idea:

Previously there was no concept of regular tokens, remember me tokens or manually created tokens. This made it challenging for extensions to edit existing tokens without any hint as to their usage, and this prevented building the session management UI (which should finally ship in our next release). I also remember issues with the SQL queries required to filter results while the lifetime and last activity were stored as different columns, rather than storing the expiration date.

My PR refactored the system to add token types, while keeping it as simple as possible. There was no requirement for the expiration date to be stored in the database for this new system to work, so this was dropped. An extension could still re-introduce that system if it needs it.

The type-based access tokens also has an important role related to the future session management UI: if you customize tokens, you will probably need to update the management UI accordingly to show that those tokens are different. Having a separate type for your special session means you don't need to worry about changing how the native tokens are displayed.

I still believe hard-coded values for regular and remember is the most maintainable way to go for core, however I'm not sure the current values have to remain unchanged. In fact there was an archived open issue about adjusting the remember me lifetime flarum/issue-archive136 likewise we could discuss an optimal value for the regular token as well.

All of this is only part of the story though, there's also the Symfony session and cookie lifetimes. The regular token lifetime should only be long enough for the token to survive the Symfony session. A longer lifetime wouldn't help since the Symfony session would expire and break the link between the browser and that token anyway.

Any token that should survive the current browsing session would need to be a form of remember cookie.

Again, I think the easiest implementation for this would pretty much operate outside of the token API. Just have the extension add a new column to the tokens table, and clear remember tokens before their native expiration based on that new column. Or to re-use the same value for all sessions including existing sessions, store it on the users table and join the tables during a scheduled command.

I'm not seeing any issue implementing this with the current API.

The only thing we should fix is the point mentioned above by rob006 about session.lifetime, we should make sure there is no way for the regular token to expire before the Symfony session, which can currently happen. The static properties aren't an issue here either, we should just add a static method on SessionAccessToken that allow setting the lifetime value, and set it to session.lifetime in a service provider.

What I think is a more useful feature than customizable session lifetimes, is a session keep alive system. Which we already have available https://discuss.flarum.org/d/30542-davwheat-session-keep-alive-good-riddance-something-went-wrong

rob006

clarkwinkelmann The static properties aren't an issue here either, we should just add a static method on SessionAccessToken that allow setting the lifetime value, and set it to session.lifetime in a service provider.

Wouldn't it make more sense to use static getter which will return session.lifetime? It should be less prone to timing errors than setter (no risk that $lifetime is set before session.lifetime is adjusted). And it will be easy to introduce extensibility for other tokens by retruning something like resolve('config')['session.remember.lifetime'] ?? self::$lifetime.