Repository navigation
chore(soe): make the Arcane long-lived login an opt-in - #84
Merged
Merged
Conversation
Arcane's default login lasts about a day, which is a prompt every morning on a dev box. Two knobs move it and both are needed -- either alone still logs you out. authSessionTimeout sets the access token's life, and the access-token cookie is the only thing that survives a browser restart. The server clamps it to 15..525600 minutes with no never-expire value, so a year from each login is the ceiling. JWT_REFRESH_EXPIRY stamps the session row's expiry at login and is never extended on refresh, so the image's 168h means every request 401s at day seven whatever the timeout says. Off by default: Arcane holds the Docker socket, so a year-long cookie is a per-machine decision. Both settings stay absent while the flag is off rather than being written at a default, so a value set by hand in the UI survives a re-run. Verified on desktop-derek with real runs. Flag off: neither JWT_REFRESH_EXPIRY nor a written authSessionTimeout. Flag on: JWT_REFRESH_EXPIRY=87600h in the container env and authSessionTimeout=525600 in the settings table. Flag off again: the timeout is left at 525600 rather than reset. Not achievable on v2.10.1: changed=0 on a re-run. That version's settings GET returns none of the keys the role manages, so the diff always fires. It predates this change -- with the flag off, carrying exactly what main carries, the assert still reports changed.
Contributor
|
Released in v2.24.13 -- https://github.com/hyperi-io/hyperi-developer/releases/tag/v2.24.13 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Arcane's default login lasts about a day, which is a login prompt every morning on a dev box. Two knobs move it and both are needed - either one alone still logs you out.
authSessionTimeout(settings table, minutes) sets the access token's life, and the access-token cookie is the only thing that survives a browser restart. The server clamps it to 15..525600 and has no never-expire value, so a year from each login is the practical ceiling.JWT_REFRESH_EXPIRY(env) stamps the session row's expiry at login and is never extended on refresh. Left at the image's 168h, every request 401s at day seven whatever the timeout says.Off by default. Arcane holds the Docker socket, so a year-long cookie is a per-machine decision. Both settings stay absent while the flag is off rather than being written at a default, so a value set by hand in the UI survives a re-run.
Verified on desktop-derek, real runs
JWT_REFRESH_EXPIRYin the container env orarcane.env.JWT_REFRESH_EXPIRY=87600hin the container env, andauthSessionTimeout = 525600read from the SQLite settings table.525600rather than being reset, and the env var is removed.ansible-lintclean on the role,run-tests.shgreen.Two things worth knowing
The brief's premise was v2.8.0; desktop-derek runs v2.10.1. On v2.10.1 the settings GET returns 22 keys and includes none of the ones the role manages, so
changed=0on a re-run is not achievable. That predates this change - with the flag off, carrying exactly what main carries, the assert still reports changed. Filed as #83 rather than widened into here.Not verified: that
changed_whenonStart Arcanefires when onlyarcane.envmoves. It correctly reportedokon the second run, where the file was unchanged, but I did not isolate a run that moved only that file.dragonfly's Arcane was left alone deliberately - hand-rolled stack, no
ADMIN_STATIC_API_KEY,JWT_REFRESH_EXPIRYinline in compose, pinned v2.8.0, 16MB live database. A role run there would rewrite both files and recreate the container.