Redmine

Attached is a patch against current trunk implementing the rate limiting part (pillar 3) of this proposal.

What it does:
- Fixed-window (60 s) request counting per authenticated user, or per source IP for unauthenticated requests; covers the API key, HTTP Basic and OAuth2 authentication paths.
- New integer setting rest_api_rate_limit (requests per minute, 0 = disabled; default 0, so existing installations are unaffected), shown on the API settings tab next to rest_api_enabled.
- Over the limit the API responds 429 Too Many Requests with Retry-After and X-RateLimit-Limit headers and an errors body in JSON/XML (reusing common/error_messages.api.rsb); each rejection is logged via Rails.logger.warn
- Counters live in a cache store (Rails.cache by default, injectable — the tests swap in a memory store since the test environment runs :null_store). With a store that cannot count, the limiter fails open.
- Web UI requests are never throttled (the filter is guarded by api_request?)

Known limitations, by design: fixed-window boundary bursts (up to 2x the limit across a window edge); with the default :file_store/:memory_store counters are per host/process — a shared limit across nodes needs memcached/redis;
remote_ip trust depends on the reverse proxy setup.

Tested with Ruby 3.4/SQLite: the new unit + integration tests pass (14 runs), and the whole test/integration/api_test suite stays green (382 runs). RuboCop is clean on the touched files.

Feedback welcome — happy to adjust naming, defaults or scope (per-endpoint limits, X-RateLimit-Remaining, …) based on maintainer guidance.

No good reason. Thanks for the pointer.

The only thing in the way was the setting: to: and within: are captured when the class body runs, while rest_api_rate_limit is meant to be editable in the admin UI without a restart. So I kept the setting and called rate_limiting from a before_action placed after user_setup, so that the bucket can be the current user and fall back to the IP:

def check_api_rate_limit
  limit = Setting.rest_api_rate_limit.to_i
  return unless api_request? && limit > 0

  rate_limiting :to => limit, :within => 1.minute, :scope => 'api', :name => nil,
                :by => lambda {User.current.logged? ? "user/#{User.current.id}" : "ip/#{request.remote_ip}"},
                :with => lambda {render_api_rate_limit_exceeded(limit)},
                :store => Rails.cache
end

This drops my own counter and its unit test, and the rate_limit.action_controller notification is a better hook for the audit logging pillar of this issue than the logger.warn I had. The downside is the dependency on a private method.

If you prefer to stay on the public macro, the limit has to move to configuration.yml and changing it then needs a restart. I can send that version instead.

Updated patch attached

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.

Structured audit logging

• Opt-in api_audit_logging_enabled setting (Integrations tab). Each API-credential authenticated request writes one JSON line to log/api_audit.log (rotated weekly): timestamp, user, credential id (pat:<id> / api_key / oauth:<id>), method, path, IP, response status. Implemented with prepend_around_action so requests denied by a halted filter chain (401/403) are audited as well, a true 500 is recorded when an exception is in flight, and logging failures degrade silently instead of breaking API responses. The path is logged without the query string, and the patch also adds the key parameter to config.filter_parameters so the plaintext key no longer appears in production.log.

Not covered here

• Rate limiting - left to the ongoing discussion in this ticket.
• CORS (new dependency), granular endpoint control, and an Administration panel over all users' tokens - kept out to keep this reviewable; happy to follow up on any of them.

Verification

Checked on a clean trunk checkout at f92786ec6 (Rails 8.1.3.1, Ruby 3.3, SQLite): git apply --check passes, and the full test suite (bin/rails test) gives

• before the patch: 5734 runs, 29842 assertions, 29 failures, 3 errors, 102 skips
• after the patch: 5795 runs, 30010 assertions, 29 failures, 3 errors, 102 skips

The failure lists before and after are identical - all of them are environment-dependent on my machine (27 SCM tests needing local test repositories from rake test:scm:setup, 4 LDAP tests needing a test LDAP server, 1 changeset test) and are unrelated to the patch, which adds 61 passing tests. RuboCop reports no offenses on the changed files.

Feedback welcome - I will gladly iterate on the patch based on review.