Redmine

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. Attached: 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.