Skip to content

Personal Access Token (PAT) expiry is notifying [a] for impersonation tokens [b] at Premium

Summary

GitLab Premium Customer reported (internal links) that after upgrading from 12.2 to 12.9, users started receiving warning emails that their personal access tokens were expiring soon.

Implemented to close issue #3649 (closed) via MRs !17344 (merged) and !19296 (merged) PAT expiry is an GitLab Ultimate feature, so this was challenging as the UI does not surface any information about this feature on GitLab Premium

Further investigation identified that the tokens being alerted for were impersonation tokens.

# Find a user that has received the email
user = User.find_by_username('username')

# Get PATs that have had notifications sent
user.personal_access_tokens.where(expire_notification_delivered: true)

Impersonation tokens are created by administrators, not users, and so it's not useful for users to be notified about their expiry - not even on GitLab Ultimate

Additionally, the customer's users did not know impersonation tokens existed.

Steps to reproduce

Create short lived impersonation tokens for users?

Example Project

What is the current bug behavior?

What is the expected correct behavior?

~~At present (not withstanding #211494) the PAT expiry feature should not work at all GitLab Premium.~~

Users should not be notified that their PATs are expiring when in fact their impersonation tokens are expiring. Users can't do anything about impersonation tokens, and in any event, the emails say their PATs are expiring, which is confusing.

Proposal

Ignore impersonation tokens for notification purposes.

Out of scope

Notification emails for impersonation tokens will be disabled by the proposal, and restoring them is out of scope. Restoring them will be executed under Issue #216269.

Possible fixes

Fix number 1 is to just ignore impersonation tokens.

They can be set to expire when created, via the API, to comply with company policies. This doesn't seem to be limited to Ultimate. It doesn't make sense to email users about these at all, and administrators don't care - they created them to expire.

Raw SQL from back end MR !19296 (merged) currently:

SELECT "users".* FROM "users" 
  WHERE 
  (EXISTS 
    (SELECT 1 FROM "personal_access_tokens"
     WHERE 
        (personal_access_tokens.user_id = users.id) AND 
        (revoked = false AND 
         expire_notification_delivered = false AND 
         expires_at >= CURRENT_DATE AND 
         expires_at <= '2019-11-21 20:54:15.241017'))) LIMIT 1000

I think it should be further restricting the results from the personal_access_tokens table.

SELECT "users".* FROM "users" 
  WHERE 
  (EXISTS 
    (SELECT 1 FROM "personal_access_tokens"
     WHERE 
        (personal_access_tokens.user_id = users.id) AND 
        (revoked = false AND 
         expire_notification_delivered = false AND 
         impersonation = false AND 
         expires_at >= CURRENT_DATE AND 
         expires_at <= '2019-11-21 20:54:15.241017'))) LIMIT 1000
Edited by Ben Prescott_