CustomersDot <> GitLab.com Access Token Short Expiry
Summary
Unsure if this is a "bug" per se, and from slack discussions, nothing on cdot code has changed recently. But multiple support engineers have noticed this as seemingly different from how it worked until now.
Recently (within the last week as of 2022-05-23), Support team has noticed customer's cDot accounts no longer being linked to their GitLab.com users. From admin point of view, "GitLab Groups" page shows Customer has not linked their GitLab.com account.
even when the Customer record has a uid
and gitlab
provider. This creates an extra challenge for us on the support side due to reduced visibility on customer's namespaces.
From a customer POV, My Account > Your GitLab.com account shows No account linked.
unless the view is loaded as a customer logging into cDot using their GitLab account.
In the history tab, very recent entries exist nullifying the access token. For example, my account on customers.staging:
2022-05-23 13:35 | khughes+test63@gitlab.com | update [updated_at = 2022-05-23 13:35:35 UTC, access_token = ]
The Provider is (and has been) gitlab
and UID is 1688436
(my staging account)
The question here is: what changed and is it worth investigating?
It seems like nothing on cDot side has changed recently, so perhaps GitLab.com side?
Support impact
There are a few services on cDot side which do rely on user-level access token when available, for example Gitlab::HostedPlans::CreateTrialService. Support tooling relies on that service for "extending" expired subscriptions; it doesn't currently supply an admin token so it fails to work otherwise. Anecdotally speaking, this has worked fine up until very recently where we're now seeing accounts that had persisted access_tokens being invalidated.
Customer impact
For the customer purchasing perspective, it contributes to a bit of a confusing process when managing an existing subscription. Again, using my staging account (which was previously linked), trying to add minutes into an existing sub:
Sends me to the purchase URL (https://customers.staging.gitlab.com/subscriptions/new?plan_id=2c92a0086a07f4a8016a2c0a1f7b4b4c&subscription_id=A-S00082613&transaction=ci_minutes
) now requiring an extra step to re-link: https://customers.staging.gitlab.com/auth/gitlab?redirect_to=https%3A%2F%2Fcustomers.staging.gitlab.com%2Fsubscriptions%2Fnew%3Fplan_id%3D2c92a0086a07f4a8016a2c0a1f7b4b4c%26subscription_id%3DA-S00082613%26transaction%3Dci_minutes
which resulted in a 404
Refreshed the page landed me back at the purchase workflow
Workarounds
- Have the customer re-link their account, possibly every few hours?
- Note for console users needing to workaround it: pass
is_admin=true
to BaseTrialService