Unleash / unleash / 30832084439

87%

master: 91%

Build Type

push

github

Committed by web-flow

Commit Message

refactor: parse authorization tokens on the boundary

## Why

Authorization headers currently make each caller infer token meaning
from string prefixes and token internals. That couples routing,
validation, and storage details to middleware and admin routes, and
makes future token changes expensive to reason about.

This refactor parses an authorization value once at the boundary and
passes an explicit credential value inward. Callers branch on its
declared kind and version rather than inspecting the raw string.

## Credential model

A parsed credential has two independent dimensions:

- `kind` identifies its authorization family: user access, API token, or
legacy admin API token.
- `version` identifies its validation and storage protocol: V1 or V2.

The parser deliberately does not resolve permissions, projects,
environments, or the owner of a user-access credential. Those are
authoritative storage-backed facts and are resolved only during
authentication. A `user:` credential can belong to either a person or a
service account, so that distinction cannot be made from its syntax
alone.

## V2 values

A full V2 API-token credential contains both the submitted secret and
its selector. Authentication uses the selector to locate the stored
verifier, then uses the secret to verify the credential.

Admin token-management operations usually receive only the selector.
This is represented as a V2 identifier: it can locate a token for
management, but it cannot authenticate a request because it has no
secret. Admin operations may also accept a full V2 credential, which is
reduced to its selector.

## Why this shape

The model keeps credential family separate from credential version. This
lets V2 support later extend to user-access credentials, including PATs
and service-account tokens, without confusing them with the existing V2
API-token family. It also keeps the current feature-API policy explicit:
user-access and admin API credentials are not accepted where ba... (continued)

Coverage Stats

1981 of 2191 branches covered (90.42%)

59 of 64 new or added lines in 9 files covered. (92.19%)

1 existing line in 1 file now uncovered.

15772 of 18068 relevant lines covered (87.29%)

798.61 hits per line