Feature #44430
Updated by Marius BĂLTEANU 1 day ago
Extracted from #43881 only the part that implements the fine grained personal access tokens: Bogdan Egikov wrote in #note-11: > I have implemented pillar 1 (personal access tokens) together with pillars 2 (scoped permissions) -and 4 (structured audit logging) as a single patch against current trunk. trunk-. Attached: @personal-access-tokens-43881.patch@-. @personal-access-tokens-43881.patch@. > > **Personal access tokens** > > * New @personal_access_tokens@ table (one migration) and model: multiple named tokens per user, each with a mandatory expiration date. Only the SHA256 digest of the value is stored (same strategy as the existing Doorkeeper @hash_token_secrets@ configuration); the @rmpat_@-prefixed value is displayed exactly once, at creation. > * Self-service UI under My account (list / create / revoke), protected by sudo mode; throttled last-used tracking; a new @personal_access_token_max_lifetime@ setting (Administration -> Settings -> Integrations tab, @format: int@, 0 = no limit, security-notified). The new-token form clamps its default expiration to this policy. > * Fully backward compatible: @find_current_user@ tries the token digest first and falls back to the unchanged legacy API key, across all three transports (header, @key@ parameter, HTTP Basic username). Existing keys and integrations are not affected - same coexistence approach as the OAuth provider introduction in 6.1.0. > * A tested @PersonalAccessToken.import_legacy_api_tokens!@ is included but deliberately not invoked: legacy plaintext keys can be converted to hashed tokens server-side without invalidating them (lookup is by digest), so a future release can retire plaintext keys with a data migration in the style of SaltUserPasswords (20110223180953). > > **Scoped permissions** > > * Optional @scopes@ column (space-separated permission names, blank = full access). Enforcement reuses the existing OAuth machinery: scopes are assigned to @User#oauth_scope@, so the @Role#allowed_to?@ intersection and the @admin@ pseudo-scope apply unchanged, and public permissions are force-included like OAuth applications. > * Note: this inherits the open defect #44271 (issue attribute editing goes through @Issue#user_tracker_permission?@, bypassing the scope intersection). The patch pins that behavior with a clearly-labelled test that will start failing once #44271 is fixed, so both mechanisms pick up the fix together. Holger Just wrote in #note-12: > > Most of the functionality of your new personal access tokens seems to mirror what we already have with the oauth applications (e.g. restricted scopes or token live times) as implemented in #24808. As such, I'm not sure if it's actual a good idea to duplicate most of this again. Instead, I would prefer an approach where we adapt / extend the existing oauth applications so that we could issue long-lived access tokens from there.