Sessions cookie key to be configurable in development environment
What does this MR do and why?
User Sessions cookie_key
to be configurable in development environment
In order to address this issue: gitlab-development-kit#1894 (closed) which is part of the ongoing work on the Cells project, we need to make the User Session cookie_key
configurable on the local development
environments
More Context Please !
GDK already supports setting up two cells for local development, to help engineers simulate how two cells would look like in the future on GitLab.com, to facilitate development and testing cells features on cells.
This is how Cells almost look like when you follow the instructions to setup two cells using GDK.
(this is an editable png via draw.io tool)
What is the problem that this MR is solving then?
When we setup two cells, the user has to login on both cells localhost:3000
and localhost:3001
. But in reality on GitLab.com, users have to be signed in only once even if they switch between cells. And for the purpose of the 16.4 Demo we have to present this behaviour as well. In order to have the user signed in automatically on all the cells upon login, there are three problems that have be solved.
Right now any GDK uses the cookie_key
: _gitlab_session_<UNIQUE_HASH_BASED_ON_THE_ROOT_DIRECTORY_OF_GDK>
. But we need to make this key parameterized.
The solution
This MR is addressing only one of them, which is the ability to configure and change the User Sessions cookie_key
between all the GDK cells. But it will be used to change the cookie_key
only for the 2nd cell, so that we won't introduce a breaking change to the current GDK environments.
This MR introduces new config file config/session_store.yml
, which has two options:
-
cookie_key
: Which controls the first part_gitlab_session
-
unique_cookie_key_postfix
: Which controls the 2nd part of the key. Current default behavior istrue
. But if it's set tofalse
, the last part will be skipped, and we won't add a unique postfix to thecookie_key
If this config file is missing, the current default behavior of generating the cookie_key
is preserved.
Follow up MR on GDK
This is the follow up GDK MR that will be used to configure the 2nd GDK cell to:
- Will make 2nd Cell share the same sessions
cookie_key
as the first GDK cell. - Share the same
secret_key_base
between the two cells, so that User Sessions are encrypted with the same key. - Make 2nd Cell connect to the Sessions Redis
How to set up and validate locally
- Pull the branch
adding-config-for-session-store-cookie-name
.
Testing with the config file is missing (default scenario when this MR is merged)
When the config file is missing, we preserve the current default behavior for user session cookie_key
s.
gdk restart rails-web
- Browser to
localhost:3000
. Login is optional - In Google Chrome, right click -> inspect -> application tab -> cookies. The cookie key for sessions should be like
_gitlab_session_<UNIQUE_HASH_BASED_ON_YOUR_GDK>
Testing with the config file is present and with unique cookie_key postfix
- Introduce this file
config/session_store.yml
development:
unique_cookie_key_postfix: true
cookie_key: "my_awesome_session_key"
gdk restart rails-web
- Browser to
localhost:3000
. Login is optional - In Google Chrome, right click -> inspect -> application tab -> cookies. Clear the cookies. Then refresh the browser.
- Check the cookies again after the refresh. You should get a new cookie key that looks like
my_awesome_session_key_<SOME_UNIQUE_KEY>
Testing with the config file is present and without unique cookie_key postfix
- Change
unique_cookie_key_postfix
tofalse
. -
gdk restart rails-web
. - In Google Chrome, right click -> inspect -> application tab -> cookies. Clear the cookies. Then refresh the browser.
- You should get a new cookie key that looks like
my_awesome_session_key
only
Clean up
Feel free to remove the config/session_store.yml
so that it doesn't show up in your git
changed files for your other work. It will be introduced later when the follow up GDK MR is merged.
References
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.