Swagger-ui: Support the global security object

[jacobweber]

According to the swagger 2.0 spec, a default "security" object is supported in the root object, which can be overridden at the operation level.

It doesn't look like swagger-ui supports this. When I added the object below to the root object, and removed it from my operation objects, swagger-ui didn't show the On/Off buttons anymore.

    "security": [
        {
            "oauth2": [
                "full"
            ]
        }
    ],

It works if I add it to individual operation objects.

[sansjunk]

+1
I just came here to report this! I guess the workaround now is to just duplicate the security requirement in each API definition.

[davisford]

This used to work for me also in editor.swagger.io, but has since stopped working. Any idea why?

[cnovak]

I am seeing the same issue in the Swagger UI online demo when loading a Swagger 2.0 file with a global security object.

I am not seeing @davisford 's issue in the Swagger Editor online demo. it displays the authentication at the top of the preview and is sending the key in the header with this example:

swagger: '2.0'
info:
  version: 1.0.0
  title: Echo
  description: >
    #### Echos back every URL, method, parameter and header

    Feel free to make a path or an operation and use **Try Operation** to test
    it. The echo server will

    render back everything.
schemes:
  - http
host: mazimi-prod.apigee.net
basePath: /echo
security:
  - myApiKey: []
paths:
  /:
    get:
      responses:
        '200':
          description: Echo GET
    post:
      responses:
        '200':
          description: Echo POST
      parameters:
        - name: name
          in: formData
          description: name
          type: string
        - name: year
          in: formData
          description: year
          type: string
  '/test-path/{id}':
    parameters:
      - name: id
        in: path
        description: ID
        type: string
        required: true
    get:
      responses:
        '200':
          description: Echo test-path
securityDefinitions:
  myApiKey:
    type: apiKey
    in: header
    name: api_key

I did notice some caching issues however - if you click "Try this operation", then change the securityDefinition for myApiKey to in:query, other send requests for that method will still have the key in the header.

[davisford]

@cnovak it's a known bug - don't recall the issue# right now. but if you change the security info, you have to close all expanded forms and re-open to make them take effect. ez workaround, but it can be frustrating if you don't know about it.

[jacobweber]

The authorization handling in 2.2.2 is similar, but behaves slightly differently. It now shows a global "Authorize" button on top, but this still doesn't obey the global "security" object; it just shows all securityDefinitions separately. So if one of your "security" objects requires the AND of two security definitions, they'll be shown incorrectly as two separate authorizations.

On the other hand, if you put "security" objects on individual operations, and you click the red exclamation point, the dialog works correctly, showing both of the ANDed requirements as a single authorization.

Example:

    "security": [
        {
            "oauth2": [
                "full"
            ]
        },
        {
            "appId": [],
            "appKey": []
        }
    ]

[ianfixes]

It took quite a lot of time for me to realize that this was a problem in swagger an not in my spec. Possibly root issue reported here: https://github.com/swagger-api/swagger-codegen/issues/3947

[webron]

This shouldn't be an issue with the latest UI.