Blog Post: Non-Expiring Access Tokens
Triage (REQUIRED)
Please note that there is a different process for when you want to announce something via the blog. Please see announcement requests in the handbook and open an announcement request issue instead of a blog post issue.
Proposal
Recently, we had a large change where we made it so that access tokens (personal, group, project) must have an expiration date. If a customer had a token with a nil
expiration date, we hard-coded one for the 17.0 timeframe.
This change has a lot of potential to be disruptive in %17.0 unless it is well communicated. It is also somewhat controversial , since customers with long lived tokens will now be forced to rotate them.
The intention of the blog post is to:
- Give the "why" behind why we chose do to this
- Some tools for customers to make this transition easier for them
- Raise awareness that the date was applied
Checklist
-
Does this align with a time-sensitive release, campaign or announcement? Please add link to pertinent info such as eBook landing page -
If wide-spread customer impacting or sensitive, mention @nwoods
to give her a heads up ASAP, apply the sensitive label, and check the PR handbook in case you need to open an announcement request instead of a blog post issue -
If the post is about one of GitLab's Technology Partners, including integration partners, mention @mjoscelyn
, apply the Partner Marketing label, and see the blog handbook for more on third-party posts -
If the post is about one of GitLab's customers, mention @nicolecsmith
, apply the Customer Reference Program label, and see the blog handbook for more on third-party posts -
Indicate if this post requires additional approval from internal or external parties before publishing (please tag needed sign off DRIs as necessary) -
Please upload any images to the MR before tagging the editorial team.
Questions?
-
Please tag @Sgittlen with any questions/concerns/confusion.