[1st & important] Fix domains and encryption key setup of securecookies with claims #29
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.
Mainly fixes #23, fixes #25 by configuring Domains and other options of session store.
Additionally, enabling RBAC previously required
SESSION_KEY
to be set to a non-empty value. Enabling RBAC and not settingSESSION_KEY
were silently ignored, resulting with no group claims cookie produced - effectively a bug.Next,
SESSION_KEY
was documented asA session key used to encrypt browser sessions
which was not true. Gorilla's NewCookieStore says that the argument is a key or pair of keys. If only one key is passed, that is considered as only having the first key from the pair set, with the second key being empty. Keys are set in pairs because the first one of them isauthentication key
and the optional second one isencryption key
. Multiple pairs can be set to allow key rotation. So the original implementation just setting theSESSION_KEY
was actually setting it as theauthentication key
, preventing cookie value to be altered by a malicious actor, not encrypting the cookie as the config documentation string said - another bug.This commit changes the behavior so that
SECRET
is used for authentication andSESSION_KEY
is used for encryption as originally documented.Idea to discuss: It would be possible to completely remove
SESSION_KEY
config field and use a single-keySECRET
argument toNewCookieStore
without encrypting the claims cookie. In the reality there is nothing secret in the groups claim so encryption is not really necessary. But having it encrypted (and using the pull request as-is) could allow more data (private eventually) to be stored in the session store.all tests are ok as before (I intentionally left the %w bug there as #27 fixes this)