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:

1. cookie_key: Which controls the first part _gitlab_session
2. unique_cookie_key_postfix: Which controls the 2nd part of the key. Current default behavior is true. But if it's set to false, the last part will be skipped, and we won't add a unique postfix to the cookie_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:

1. Will make 2nd Cell share the same sessions cookie_key as the first GDK cell.
2. Share the same secret_key_base between the two cells, so that User Sessions are encrypted with the same key.
3. Make 2nd Cell connect to the Sessions Redis

How to set up and validate locally

1. 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_keys.

1. gdk restart rails-web
2. Browser to localhost:3000. Login is optional
3. 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

1. Introduce this file config/session_store.yml

development:
  unique_cookie_key_postfix: true
  cookie_key: "my_awesome_session_key"

1. gdk restart rails-web
2. Browser to localhost:3000. Login is optional
3. In Google Chrome, right click -> inspect -> application tab -> cookies. Clear the cookies. Then refresh the browser.
4. 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

1. Change unique_cookie_key_postfix to false.
2. gdk restart rails-web.
3. In Google Chrome, right click -> inspect -> application tab -> cookies. Clear the cookies. Then refresh the browser.
4. 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

• Current documentation on how to setup Multiple Cells on GDK

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.