fix(auth): prevent legacy keyring ambiguity causing 401 errors

Kai Armstrongrequested to merge
fix-keyring-legacy-token-ambiguity into main

Fixes #8168 (closed)

Problem

Users with PATs stored in the legacy keyring format experience 401 Unauthorized errors after upgrading to v1.84.0+.

Debug output shows Job-Token: header being sent instead of Private-Token: header, causing authentication failures.

Root Cause

The legacy keyring format glab:hostname was ambiguous - it was used for both token and job_token. When authenticating:

  1. API client retrieves both token and job_token from config
  2. Backward compatibility fallback finds the user's PAT when checking for job_token (same ambiguous key)
  3. Auth source selection checked job_token before token
  4. Incorrectly uses JobTokenAuthSource, sending Job-Token: header instead of Private-Token: header
  5. Result: 401 Unauthorized

Solution (Defense in Depth)

1. Config Layer

Restrict backward compatibility fallback to only check legacy keyring format for token and oauth2_refresh_token, not job_token. Job tokens were rarely stored in keyring historically (typically CI/CD environment variables).

2. API Client Layer

Prioritize PAT (token) over job_token in auth source selection. PATs are more common and this provides a safety net if both are somehow retrieved.

Testing

  • All existing keyring tests pass
  • Project builds successfully
  • Users with legacy keyring PATs will now authenticate correctly

Changes

  • internal/config/config.go: Restrict legacy fallback to specific keys
  • internal/api/client.go: Check token before job_token in auth source selection

Merge request reports