Swagger documentation lists incorrect authorization header

[achard]

Environment

• Python version: 3.10
• Nautobot version: 1.39

Steps to Reproduce

1. Open the swagger API interface
2. Attempt to use the included curl commands to execute API calls

Expected Behavior

The listed authorzation header value should be Authorization: Token <VALUE>

Observed Behavior

THe header value is instead Authorzation <VALUE>

[smk4664]

@achard and I looked into this a little. This issue occurs when you use Authorize on the tokenAuth with just the token and no Token prefix. Perhaps this should be renamed to Swagger Docs Token Authorization without Token prefix.

[jathanism]

This is not easily fixable because it's not a part of the Swagger 3.0 API schema spec. See:

https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#securitySchemeObject

Specifically:

bearerFormat | string | http("bearer") | A hint to the client to identify how the bearer token is formatted. Bearer tokens are usually generated by an authorization server, so this information is primarily for documentation purposes.

As indicated here the bearer format style clearly indicates that this value is "primarily for documentation purposes".

So even if we were to manually override token authentication to return an "http.bearer" vs. "apiKey" authentication type, it still wouldn't work:

 {
    "type": "http",
    "scheme": "bearer",
    "bearerFormat": "Token",
    "description": "Token-based authentication with required prefix \"Token\""
}

This results in a slightly different UI experience:

However this does not address what gets emitted because of the OpenAPI spec adherence:

The name of the header is derived from the authentication method, however the argument that gets passed to the header is a function of the schema itself and it is not possible to prepend to this argument because it is literally coming through from the HTTP client.

So what we're left with is deferring to "apiKey" authentication type, which is what is currently used, and again, does not support prepending a header value.

We might be able to augment the front-end code to pre-pend this "Token" keyword to the header value, but that seems mighty invasive for something that is working as intended. I personally do not feel the juice is worth the squeeze strictly because "Token {key}" is intended to be the header value.