Closed k3a closed 4 years ago
@k3a thanks for picking up my slack. Also, great catch on the session key issue. I was not too concerned about encrypting the session after a behavior change where we no longer needed to store the users id-token; and opted to only store the group claims.
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)