This repository was archived by the owner on Jun 24, 2025. It is now read-only.
feat: allow setting custom session cookie expiration#1156
Merged
eliandoran merged 8 commits intodevelopfrom Feb 13, 2025
Merged
feat: allow setting custom session cookie expiration#1156eliandoran merged 8 commits intodevelopfrom
eliandoran merged 8 commits intodevelopfrom
Conversation
eliandoran
suggested changes
Feb 11, 2025
56b407c to
6a97d6f
Compare
Contributor
Author
|
|
allows users to control how long their session will be live, before it expires and they are forced to login again
defaults to 1 day ("24 * 60 * 60 * 1000") as previously set in sessionParser
…ion cookies maxAge this avoids having "unused" dead session on the filesystem
…lt value to 21 days 21 days was used in the login route previously, when "remember me" was set
cookie will use the default value set in sessionParser middleware, which is controlled by config.Session.cookieMaxAge if rememberMe is not set -> the value is unset and the cookie becomes a non-persistent cookie, which the browser delete after the current session (e.g. when you close the browser)
previously it was either a number like string (in case env or config.ini was used) or a number (the fallback value) we now parseInt the value -> if any value is NaN (e.g. because it was incorrectly set) it will try with the next, before it uses the fallback value the strange looking `parseInt(String(process.env.TRILIUM_SESSION_COOKIEMAXAGE))` is required to make TypeScript happy, other variants of trying to get the value into a string were not good enough for typescript :-) The `String(process.env.TRILIUM_SESSION_COOKIEMAXAGE)` will now either return a number like value or 'undefined' (as string), which parseInt parses into NaN, which is falsy.
6a97d6f to
b692c00
Compare
Contributor
Author
|
changes done as discussed, we now use Seconds to enter the value and we now only set the default value once, instead of in two places: I've went with setting the default value in sessionParser, made more sense to me to have it "close" to the configuration, instead of being set in the login route |
eliandoran
approved these changes
Feb 13, 2025
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
Hi,
this PR is a feature on top of #1155 – which is why you see some extra commits here.
It will allow users to set their own session expiration, e.g. currently it defaults to 1 day – but I can see users who might want to limit it to a shorter period of time (myself included ;-)).
it also set the TTL of the FileStore for the session to the same value as the maxAge from the cookie.
Before that it was set to 30 days, which (if I am not completely mistaken) would've left a couple of dead "unused" session in the FileStore.
(this still needs some testing "in the field", which is why it is set to draft)