Draft: Update OAuth Access Tokens to have a default expiration
What does this MR do and why?
- This migration is adapted from this previous MR, which was used to add an expiration to all existing OAuth access tokens: !86379 (merged)
- It was later discovered that there were still new
OauthAccessTokens
being created without an expiration because callingOauthAccessToken.new
directly does not set a defaultexpires_in
. - Doorkeeper controllers will set the ttl to
Doorkeeper.confg.access_tokens_expires_in
by callingDoorkeeper::OAuth::CientCredentials::Issuer.new.create
- Calling
OauthAccessToken.new
is problematic because it will not set a default expiration. The good news is that, as far as I can tell, we only do that inee/app/services/gitlab_subscriptions/create_service.rb
. - There are currently ~14k oauth access tokens on prod that do not have an expiration and are not revoked
- Almost all of those 14k tokens are from one OAuth application: "GitLab Subscription Portal" (customers.gitlab.com) which is addressed via !105734 (merged).
- Via this MR, we will ensure that all existing
OAuthAccessToken
s have an expiration value.
Migration
% rake db:migrate:main VERSION=20221202002124
main: == 20221202002124 ScheduleExpireOAuthTokensCleanup: migrating =================
main: == 20221202002124 ScheduleExpireOAuthTokensCleanup: migrated (0.0444s) ========
% rake db:rollback:main VERSION=20221202002124
main: == 20221202002124 ScheduleExpireOAuthTokensCleanup: reverting =================
main: == 20221202002124 ScheduleExpireOAuthTokensCleanup: reverted (0.0089s) ========
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
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.
Edited by Jessie Young