The global security requirement seems to be ignored or securityDefinitions is not read

[ironsmile]

It seems that no matter what you have in securityDefinitions and security Swagger UI ignores them and simply appends "api_key" into the query.

I am using master (3aaf121310) with an API which has global security requirements and few possible ways for authentication (described in securityDefinitions). Example:

    "securityDefinitions": {
        "api_key_token": {
            "type": "apiKey",
            "description": "Query parameter appended to the URL",
            "name": "token",
            "in": "query"
        },
        "api_header_token": {
            "type": "apiKey",
            "description": "Custom HTTP header which contains the api token",
            "name": "X-Auth-Token",
            "in": "header"
        }
    },
    "security": [
        {
            "api_key_token": []
        },
        {
            "api_header_token": []
        }
    ],

What happens

When I use the Swagger UI it makes requests which do not use any of the security definitions. It does:

curl -X GET --header 'Accept: application/json' 'http://api.example.com/status?api_key=8591safd12jsuwee123'

This is the output in the "Curl" section. Using the dev tools and logs from the API I was able to verify that this is equivalent to what it actually does.

As can be seen, neither securityDefinition is used. Nowhere in the definitions there is a mention of "api_key" query parameter. Regardless, it is added in the query with the token I've pasted.

What should happen

The UI should make a request which is equivalent to

curl -X GET --header 'Accept: application/json' 'http://api.example.com/status?token=8591safd12jsuwee123'

or

curl -X GET --header 'Accept: application/json' --header "X-Auth-Token: 8591safd12jsuwee123" 'http://api.example.com/status'

The first one has a query parameter "token" (from the "api_key_token" security definition) and the second one has the header "X-Auth-Token" (from the "api_header_token" definition).

How to easily reproduce

I value your time so I've cooked up a full example specification which can be used for verifying the problem. It can be seen at pastebin. It is pity that CORS rules makes it so that it cannot be "explored" in the Swagger UI with this direct url.

[webron]

swagger-ui doesn't automatically parse the securityDefinitions and requires some manual hooking. Check out https://github.com/swagger-api/swagger-ui#header-parameters. The reason why you get api_key appended is because that's the default we use for the pet store sample (check the source of the index.html).

[ironsmile]

I see. I haven't realized that.

Would you be open to a pull request which adds parsing of securityDefinitions and security? Any advice for me if I decide to do it? It does seem like a lot of work in order to capture all possible ways of authentication.

[webron]

I think a PR would be great, but it may get complicated. I'm sure you've seen the api_key box at the top right corner of the UI. That's actually there for a specific use case for the pet store. It can easily be adapted to any other type of simple apiKey typed authentication. However, that covers one case. The securityDefinitons and security allow for several authentication methods, with AND/OR between them. That would require that that top input would need to be rendered dynamically. In fact, somewhere we have a feature ticket for this (just can't find it right now). The biggest challenge is the UI/UX design for it which would need to be dynamically rendered and not burden the user. It's not a small task. If you're willing to take the task on yourself, we can certainly discuss implementation further.

[ironsmile]

I've found #1454, #1108 and #764 which are all on the subject as far as I can tell. You are right that the UI is the biggest hurdle. Unfortunately, I am ill equipped for that.

What if we take a middle road? Make sure all "simple" authentication methods work out of the box. That is, all which can fit in the current interface: token in query or header, basic authentication. This would be relatively easy to do. It is an incremental improvement and will probably save you the time for answering tickets such as this one.

[webron]

@ironsmile looks like we may have some updates on this soon, so please stay tuned.

[prusswan]

I agree it is somewhat misleading that swagger-ui does not respect the security definitions (which are part of the documentation). Ideally there should also be a way to indicate the apiKey parameter (maybe greyed out) along with the other query parameters for the endpoints that require it. Right now there is no way to identify which endpoints are protected and which are not.

[fehguy]

Yes, as @webron mentioned, we are actively working on making the auth rendering dynamic based on the spec, which is how it should work.

[fehguy]

Fixed by #2014