Skip to content
Snippets Groups Projects

Set default `OauthAccessToken#expires_in`

Merged Jessie Young requested to merge jy-default-expires-in into master

What does this MR do and why?

  • Part 1 of 3 for ensuring all existing OauthAccessTokens have an expiration
  • Part 2 will be to re-run a batched background migration that sets expires_in for all existing tokens. Similar to !86379 (merged)
  • The reason we need to set this default is that the Doorkeeper refresh token flow does uses expires_in value of the refresh token when creating a new token.
  • This presents a risk for the batch background migration: the migration works through the batch using a batch_max_value, which is the id of the newest oauth_access_token at the time when the migration starts.
  • While the migration is running, it is possible that oauth_access_tokens with expires_in: nil are refreshed, which would result in new tokens with expires_in: nil that have ids that are greater than batch_max_value. As a result, these new tokens would be left out of the migration and would remain in the database with expires_in: nil
  • This change ensures that any new tokens being created via the refresh flow have an expires_in value

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

  1. Create an OauthAccessToken with expires_inL nil:
    access_token = FactoryBot.create(:oauth_access_token, expires_in: nil)
  2. Refresh the access token
    app = OauthAccessToken.last.application
    parameters = "client_id=#{app.uid}&client_secret=#{app.secret}&refresh_token=#{OauthAccessToken.last.refresh_token}&grant_type=refresh_token&redirect_uri=#{app.redirect_uri}"
    RestClient.post 'http://localhost:3000/oauth/token', parameters
  3. Confirm that the newly-created token has an expires_in value of 7200 (2 hours in seconds)
    OauthAccessToken.last

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Drew Blessing

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Jessie Young requested review from @ifarkas

    requested review from @ifarkas

  • A deleted user added backend typebug labels

    added backend typebug labels

  • 1 Warning
    :warning: e8735021: The commit subject may not be longer than 72 characters. For more information, take a look at our Commit message guidelines.

    Reviewer roulette

    Changes that require review have been detected!

    Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:

    Category Reviewer Maintainer
    backend Roy Zwambag current availability (@rzwambag) (UTC+1, 9 hours ahead of @jessieay) Doug Stull current availability (@dstull) (UTC-5, 3 hours ahead of @jessieay)

    To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.

    To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.

    Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.

    If needed, you can retry the :repeat: danger-review job that generated this comment.

    Generated by :no_entry_sign: Danger

    • Author Maintainer
      Resolved by Drew Blessing

      :wave: @ifarkas - I'd been mulling your comments about needing to account for refresh token flows when we do the batch migration to backfill expires_in and this seemed like a simpler solution that what was proposed here.

      I could have done this in the same MR as the batch migration but it seemed cleaner to break it up into a few MRs.

      This will go first, then the batched background migration, and finally a database migration to enforce not null expires_in via postgres.

  • Jessie Young changed milestone to %15.7

    changed milestone to %15.7

  • Jessie Young changed the description

    changed the description

  • Jessie Young
  • mentioned in issue #363355 (closed)

  • Allure report

    allure-report-publisher generated test report!

    e2e-review-qa: :exclamation: test report for 1e6c8293

    expand test summary
    +-------------------------------------------------------------+
    |                       suites summary                        |
    +--------+--------+--------+---------+-------+-------+--------+
    |        | passed | failed | skipped | flaky | total | result |
    +--------+--------+--------+---------+-------+-------+--------+
    | Manage | 34     | 0      | 3       | 1     | 37    | ❗     |
    +--------+--------+--------+---------+-------+-------+--------+
    | Total  | 34     | 0      | 3       | 1     | 37    | ❗     |
    +--------+--------+--------+---------+-------+-------+--------+
  • Jessie Young added 2 commits

    added 2 commits

    • e8735021 - Fix rate limiting specs so that tokens aren't expired when they make requests
    • 1e6c8293 - Use variable to clarify why expiration matters

    Compare with previous version

  • Jessie Young
  • Imre Farkas approved this merge request

    approved this merge request

  • Imre Farkas removed review request for @ifarkas

    removed review request for @ifarkas

  • :wave: @ifarkas, thanks for approving this merge request.

    This is the first time the merge request is approved. To ensure full test coverage, a new pipeline will be started shortly.

    For more info, please refer to the following links:

  • 🤖 GitLab Bot 🤖 changed milestone to %15.8

    changed milestone to %15.8

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading