Custom ApiKeyAuth is not being honoured

[michaelwiles]

So I set the securitySchemes as specified in the docs:

SPECTACULAR_SETTINGS = {
    "APPEND_COMPONENTS": {
        "securitySchemes": {"ApiKeyAuth": {"type": "apiKey", "in": "header", "name": "Authorization"}}
    },
    "SECURITY": [{"ApiKeyAuth": [],}],
}

That correctly brings up the option in the authorize:

Then I include my token in that field:

Token XXXXXXXXXXXXXXXXX

But then when I attempt to execute on an end point the Authorization header is not included...

Am I doing something wrong? The header is included if I use the default tokenAuth (http, Bearer) But it prefixes what I enter with Bearer which my auth mechanism doesn't support.

[tfranzel]

hi @michaelwiles. ok so there are multiple things at work here. in principle, you did everything right. The problem here is that your operation likely has a security section which overrides the global security section (where your "ApiKeyAuth": [] is put)

this feature was always meant as a measure of last resort because of those non-obvious reasons. we need to clarify that in the documentation. i kind of regret adding it at all.

the better approach would be a simple extension. If your auth method has a authentication_classes you can do that really easily. Take the default ones as reference: https://github.com/tfranzel/drf-spectacular/blob/master/drf_spectacular/authentication.py#L29 just adapt target_class name and return and it should work. (info on how to load them: https://drf-spectacular.readthedocs.io/en/latest/customization.html#step-4-extensions)

sidenote: i found a bug for DRF's TokenAuthentication, where bearerFormat is set to Token (as opposed to Bearer), but that is apparently just a non-functional hint. so if you are using that, we will quickly fix that. btw are you using a custom auth or some library. maybe we should add support for it.

[tfranzel]

@michaelwiles, sry that this fell off the wagon. ab979c1 addresses this issue, by appending SECURITY everywhere (if provided). this is the preferred way for djangorestframework-api-key. virtually all other cases should be handled with OpenApiAuthenticationExtension