View Issue Details

IDProjectCategoryView StatusLast Update
0035286mantisbtapi restpublic2026-01-17 12:14
Reporterdregad Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status confirmedResolutionopen 
Summary0035286: REST API: follow Standards for Authorization header
Description

Our implementation of API tokens in Authorization header is not compliant with the standard defined by RFC-9110, which requires that an authentication scheme is specified before the actual credentials, while we expect just Authorization: {{token}}.

We need to

  1. support Authorization: bearer {{token}} as a valid authorization mechanism and make it the default and suggested format
  2. deprecate usage of Authorization: {{token}}

See MDN reference on Authorization header and Authentication schemes for more practical information on the standard.

Additional Information

Follows discussion in PR https://github.com/mantisbt/mantisbt/pull/2071

@vboctor

I suggest the inspecting authorization header types - e.g. bearer, basic, NTLM, etc. As part of that we should support bearer in front of API tokens as the suggested format, while still support the case when bearer is not provided (treat it as default).

@dregad

I would even go one step further: deprecate use of Authorization header without bearer and remove it in the future, as it's not compliant with the standard.

@vboctor

I agree that we should deprecate the calls without the bearer prefix, but other than documenting this, I'm not sure how we want to surface such deprecation. We can log it, but that penalizes the server (by spamming the logs) for clients using deprecated behavior, etc. Blocking it just seems to harsh and will break the ecosystem a bit, for low value. Adding a deprecation response header is an option as well.

TagsNo tags attached.

Activities

raspopov

raspopov

2025-02-02 09:18

reporter   ~0069812

And need to remember to follow the recommendations from RFC 6750.

barts2108

barts2108

2026-01-15 09:13

reporter   ~0070714

Using office scripting fetch() (to make REST API calls) is doing a CORS (cross origin resource share) preflight OPTIONS request. That request does not contain the Authorization header, as the server should respond what kind of authorization is allowed. Upon such preflight OPTIONS request, Mantis API will respond with a 401 Api token required. Due to the 401 response, the fetch() call will not continue to make the GET request.

When the Authorization is changed to match the standard, IMHO the OPTIONS request should be changed to allow the OPTIONS request without api token.