Migrate Existing Session Data to Redis and Begin Reading It

[Hamms]

Follow-up to #57972. We have been successfully writing session data to Redis, so now it's time to start using it.

This PR switches us from a cookie-based session store to a Redis-based one provided by the redis-actionpack gem. It also includes some temporary logic which will gracefully migrate any sessions that are still trying to store data in the cookie into redis.

Links

• https://github.com/redis-store/redis-actionpack

Testing story

Tested locally and and on an adhoc that user registration, authentication, and deauthentication all work as expected. Also verified that I can start a session on the staging branch, then switch to this branch and restart the server to pick up the changes, and then continue my session in the browser with no disruption.

Deployment strategy

We should plan to deploy this during a low traffic time when we are able to quickly respond with a revert in case things go wrong.

Follow-up work

After all (or most) sessions have been successfully migrated into Redis, we can remove the migration logic and use a vanilla un-customized Redis-based session store.

PR Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked

[cat5inthecradle]

Between these two lines of code, the session only exists in memory, is there anything bad that happens if we clear the cookie and then fail to write the session? Or is it fine if we throw a 500 with the cookie cleared?

[Hamms]

Oh, good catch! I'm not entirely sure how the 500 error response interacts with manually-set headers like this, but my expectation is that we would indeed lose the cookie data in that case. I'll swap these lines, and add an error handler just in case.

[cat5inthecradle]

Is mirror_cookies_in_redis_store still in use? Does that file need to go away here?

[Hamms]

It isn't; I had it in my head that I was going to clean that up later when I eventually remove the MigrateCookiesStore logic, but I guess there's no reason not to do so now

[sureshc]

Do we need to update our Rack Request extension? It seems to try to decrypt the session cookie to extract the user_id, I'm guessing so that Pegasus knows who the user is.

code-dot-org/lib/cdo/rack/request.rb

Lines 90 to 111 in 1ad9b87

	def user_id_from_session_cookie
	session_cookie_key = "_learn_session"
	session_cookie_key += "_#{rack_env}" unless rack_env?(:production)
	message = CGI.unescape(cookies[session_cookie_key].to_s)
	key_generator = ActiveSupport::KeyGenerator.new(
	CDO.dashboard_secret_key_base,
	iterations: 1000
	)
	encryptor = ActiveSupport::MessageEncryptor.new(
	key_generator.generate_key('encrypted cookie')[0, ActiveSupport::MessageEncryptor.key_len],
	key_generator.generate_key('signed encrypted cookie')
	)
	return nil unless cookie = encryptor.decrypt_and_verify(message)
	return nil unless warden = cookie['warden.user.user.key']
	warden.first.first
	rescue
	return nil
	end

[sureshc]

This is a foundational change to our web applications. Are there ways we can reduce risk? Can we roll out this change to a subset of users/sessions and increase that percentage over time to all users? Do we have easy ways to rollback without a deploy? I'm assuming/hoping that any unanticipated negative impacts of this change would actually be smaller than the several hundred requests a day that are failing due to Cookie overflow 😅

[Hamms]

Do we need to update our Rack Request extension? It seems to try to decrypt the session cookie to extract the user_id, I'm guessing so that Pegasus knows who the user is.

Oh damn, yes we do. I did not know this existed; I'm hoping that Drone tests will catch this now that they're configured correctly.

Can we roll out this change to a subset of users/sessions and increase that percentage over time to all users?

Not easily; we'd have to implement a session store that supports both cookie-based and redis-based sessions simultaneously, which would involve significantly more custom logic than what we've done so far.

Do we have easy ways to rollback without a deploy?

No, not at all. I'm planning to put some work into implementing another custom session store that will allow us to rollback this change at all, but by default attempting to switch back from a Redis-based session storage strategy that just puts a string in the cookie to a Cookie-based session storage strategy that expects the cookie to contain a Hash would be extremely disruptive.