Investigate unauthenticated OmniAuth session TTL
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Background
Unauthenticated sessions with the default 1 week TTL can bloat Redis memory usage. During a recent outage these took up the majority of Redis usage due to a large number of unauthenticated requests. This was despite us limiting session duration to 1 hour in !6586 (merged) / gitlab-foss!21144 (merged).
In !19064 (merged) we ensured a reduced TTL was set after a failed login.
Problem
OmniAuth sign ins take a different path so we'll want to check that they also don't leave behind unauthenticated sessions with a long TTL. In particular: the OmniauthCallbacksController used doesn't inherit from ApplicationController instead calling Devise::OmniauthCallbacksController direct from Rack, bypassing the original fix if it turns out to have been needed here.
The new approach of limiting the TTL from the Devise FailureApp may catch some OmniAuth sign ins, depending on how it interacts with the OmniAuth failure app and the GroupSaml::FailureHandler. If it doesn't we may need to limit the TTL from those in addition to OmniauthCallbacksController.
Expected outcomes
- Any sessions created during OmniAuth sign ins must have the reduced TTL set
- Any sessions created during a failed OmniAuth sign in must have the reduced TTL set
- Both above must be true for a variety of sign in methods, including Group SAML
- Any session data set for SSO Enforcement must be kept or those users be unable to use GitLab
- At a minimum we'll want test coverage to ensure unauthenticated sessions with a long TTL are not left behind