Set MaxAge for cookie based on WebSession expiry#58091
Merged
Conversation
a60644f to
9f52dd0
Compare
kimlisa
reviewed
Aug 21, 2025
Contributor
kimlisa
left a comment
There was a problem hiding this comment.
im also ok with waiting on this and implementing it with a "remember me" button. i would bring in the UX team for that one tho
+1 implementing it as an opt in feature, if someone else disagrees, i won't object
rudream
approved these changes
Aug 22, 2025
Collaborator
|
I say ship it as is. Less config options are better IMO. |
kimlisa
approved these changes
Aug 22, 2025
Contributor
Author
|
Gonna let this one sit in master for a few weeks before backporting. |
9f52dd0 to
5cb8608
Compare
mmcallister
pushed a commit
that referenced
this pull request
Sep 22, 2025
avatus
added a commit
that referenced
this pull request
Nov 6, 2025
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 10, 2025
* Set MaxAge for cookie based on WebSession expiry (#58091) * Set MaxAge in web cookie if time until expiry is > 0 (#58293) This updates the logic to only setting max-age if the provided expiry is in the future rather than any non-zero value. * Respect WebIdleTimeout in bearerTokenTTL (#59645) The webUI will log a user out due to invalid token if they haven't pinged the server within the idle time, which defaulted to the bearer token default (10 minutes). Instead, we will only default to 10 minutes if the web_idle_timeout is not configured in the cluster config
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
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.
Currently our web session cookies are literally session cookies, which means "generally" they are removed the browser is closed. (i say generally because browsers all choose to do their own whacky things with these cookies)
To alleviate this and get a more consistent behavior, we can set the max-age of our session cookies so that they persist after a browser is closed. We will set the max-age in seconds based on the time left until the underlying WebSession expires (this matches the sessionTTL, default is 12 hours for example). this wont completely fix "frequent reauth" but its a first step.
Because the backend already assumed these tokens didn't have an expiration or max-age, we aren't giving up on any security from our end here (we didnt check expiration of the cookie itself). The cookies are still validates against the WebSession expiration, this just allows the users web session to exist after closing the browser. (happy to do an update to make this behavior opt-in as well, but I don't think its necessary). Nothing would be different here if the user just left their browser open for 12 hours, so expiration behavior will not change.
there will be an
epr for this as well when setting web session cookies from some sso stuff (2 lines).im also ok with waiting on this and implementing it with a "remember me" button. i would bring in the UX team for that one tho