Switch to the default CookieJar session store #162
Merged
Conversation
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
bagedevimo
force-pushed
the
drop-active-record-sessions-store
branch
from
580f6e3 to
b0e44ca
Compare
Contributor
Author
|
Merge #161 first |
bagedevimo
force-pushed
the
drop-active-record-sessions-store
branch
2 times, most recently
from
386ac96 to
60d8d77
Compare
Deploying this will log everyone out, so we may want to consider an intermediate migration step.
bagedevimo
force-pushed
the
drop-active-record-sessions-store
branch
from
60d8d77 to
ae97aae
Compare
Contributor
Author
|
Tested by logging in ticking remember me, stopping the rails server, exiting my browser. change to this branch, start rails, start browser and verify still logged in. The cookie works fine for the non-session remember me, but if you don't click remember me your session will be lost regardless of the browser, etc. |
tom93
added a commit
that referenced
this pull request
Dec 20, 2023
secret_key_base was added in Rails 4 and replaces secret_token. It is used by CookieStore to encrypt cookies (we are not currently using CookieStore, but we will switch to it in #162). The Rails 4 convention for setting secret_key_base is to use config/secrets.yml and the environment variable SECRET_KEY_BASE (see [1]). We don't use this approach, because secrets.yml will be deprecated in favour of credentials.yml.enc in Rails 5.2 [2] and because setting the environment variable is awkward. Instead, we generate a random secret the first time the app runs and store it in config/secret_key_base.#{env}.txt. We also support the environment variable SECRET_KEY_BASE to match the Rails convention; we don't currently use this environment variable, but it may be useful (e.g. in situations such as build steps where we don't want to generate the file, or in environments such as Docker where environment variables are often more convenient than files). We don't store the secret in the database (which is how the existing secret_token is implemented) because it may be useful to start the app without a database connection. Also, it's probably more secure to keep the secret out of the database (and its backups). This commit also adds a rule to .gitignore to make sure the secrets aren't accidentally committed. [1]: https://guides.rubyonrails.org/v4.1.8/upgrading_ruby_on_rails.html#config-secrets-yml [2]: https://www.github.com/rails/rails/pull/30067
tom93
added a commit
that referenced
this pull request
Dec 20, 2023
secret_key_base was added in Rails 4 and replaces secret_token. It is used by CookieStore to encrypt cookies (we are not currently using CookieStore, but we will switch to it in #162). The Rails 4 convention for setting secret_key_base is to use config/secrets.yml and the environment variable SECRET_KEY_BASE (see [1]). We don't use this approach, because secrets.yml will be deprecated in favour of credentials.yml.enc in Rails 5.2 [2] and because setting the environment variable is awkward. Instead, we generate a random secret the first time the app runs and store it in config/secret_key_base.#{env}.txt. We also support the environment variable SECRET_KEY_BASE to match the Rails convention; we don't currently use this environment variable, but it may be useful (e.g. in situations such as build steps where we don't want to generate the file, or in environments such as Docker where environment variables are often more convenient than files). We don't store the secret in the database (which is how the existing secret_token is implemented) because it may be useful to start the app without a database connection. Also, it's probably more secure to keep the secret out of the database (and its backups). This commit also adds a rule to .gitignore to make sure the secrets aren't accidentally committed. [1]: https://guides.rubyonrails.org/v4.1.8/upgrading_ruby_on_rails.html#config-secrets-yml [2]: https://www.github.com/rails/rails/pull/30067
Contributor
|
Merge #195 first, to skip the legacy signed-but-not-encrypted cookie store mode. |
Holmes98
approved these changes
Dec 21, 2023
tom93
approved these changes
Dec 21, 2023
Holmes98
pushed a commit
to Holmes98/nztrain
that referenced
this pull request
Dec 21, 2023
secret_key_base was added in Rails 4 and replaces secret_token. It is used by CookieStore to encrypt cookies (we are not currently using CookieStore, but we will switch to it in NZOI#162). The Rails 4 convention for setting secret_key_base is to use config/secrets.yml and the environment variable SECRET_KEY_BASE (see [1]). We don't use this approach, because secrets.yml will be deprecated in favour of credentials.yml.enc in Rails 5.2 [2] and because setting the environment variable is awkward. Instead, we generate a random secret the first time the app runs and store it in config/secret_key_base.#{env}.txt. We also support the environment variable SECRET_KEY_BASE to match the Rails convention; we don't currently use this environment variable, but it may be useful (e.g. in situations such as build steps where we don't want to generate the file, or in environments such as Docker where environment variables are often more convenient than files). We don't store the secret in the database (which is how the existing secret_token is implemented) because it may be useful to start the app without a database connection. Also, it's probably more secure to keep the secret out of the database (and its backups). This commit also adds a rule to .gitignore to make sure the secrets aren't accidentally committed. [1]: https://guides.rubyonrails.org/v4.1.8/upgrading_ruby_on_rails.html#config-secrets-yml [2]: https://www.github.com/rails/rails/pull/30067
tom93
added a commit
that referenced
this pull request
Dec 21, 2023
We forgot to update Gemfile.lock in #162.
tom93
added a commit
that referenced
this pull request
Dec 22, 2023
We forgot to update Gemfile.lock in #162.
Contributor
|
This has been deployed just now, so all users that didn't tick "remember me" will be signed out. |
Contributor
|
It appears that users might get signed out even if they ticked "remember me". We are not quite sure why. |
Contributor
|
It turns out that the sign-out issue is because by default Devise sets the "remember me" cookie to expire after 2 weeks, which is very short. In future we should probably increase this duration, and/or set |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Deploying this will log everyone out, so we may want to consider an intermediate migration step.