Security Requirement Object with multiple schemes in AND

[mazzock]

Hi,
Playing with Swagger Editor (http://editor.swagger.io/), i'm trying to define multiple security schemes (in AND) for same operation following swagger 2.0 specs (javascript format).
Here reference: https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityRequirementObject.

This is my declaration

  securityDefinitions: {
    "APIKey": {
      type: "apiKey",
      name: "X-ApiKey",
      in: "header",
    },
    "AccessToken": {
      type: "oauth2",
      flow: "password",
      tokenUrl: "https://api.xxxxxx.com/v1/tokens",
      scopes: {
        "default": "Default scope" 
      }
    }
  }

And later

security: [
  {"AccessToken": ["default"], "APIKey" : []}
],

...

No errors, no warnings. AccessToken and APIKey too are both well defined in securityDefinitions sections but in the preview I have security table misaligned and, even worse, in the "try operation" view, it does not make me choose both security schemes I have defined, I'm forced to choose one (see attached screenshot)

.
There is something wrong in my statement?
Its 'a known bug?

Thanks

mazzock

[mohsen1]

Do you want to use two securities at the same time in "try operation"?

[webron]

@mohsen1 - according to the spec, that is indeed a possibility, and they way @mazzock described his security, it requires both security requirements.

[mazzock]

The api key identifies the client (web app, native app, 3rdy party api trusted clients) for the purpose of tracking, rate limits etc, access token identifies and authorizes the user. There is no doubt that there are ways to encode api key information with token only, but I'd like to model the api in a uniform manner.
Too much security? :)
Anyway, I just tried to do what I've read in specs ...

Take this opportunity to ask another question. Response headers are not represented at ui level. How to document the classic 201 Created with Location header?
I have to open a specific issue?

Thanks

[prabhatjha]

This is new to me as well. ;-) I did not think of a use case where calling
an API requires multiple authentication. Doesn't it throw a wrench in
usability? @ron do you have pointer to discussion thread on this topic?

In terms of supporting it in swagger-editor with respect to other features
that are yet to be implemented, this one is a lower priority IMO. Happy to
receive a pull request though.

On Sun, Feb 1, 2015 at 11:08 AM, Marco Mazzocchetti <
notifications@github.com> wrote:

The api key identifies the client (web app, native app, 3rdy party api
trusted clients) for the purpose of tracking, rate limits etc, access token
identifies and authorizes the user. There is no doubt that there are ways
to encode api key information with token only, but I'd like to model the
api in a uniform manner.
Too much security? :)
Anyway, I just tried to do what I've read in specs ...

Take this opportunity to ask another question. Response headers are not
represented at ui level. How to document the classic 201 Accepted with
Location header?
I have to open a specific issue?

Thanks

—
Reply to this email directly or view it on GitHub
#318 (comment)
.

Cheers,

Prabhat

Help spread www.eejot.org

[mohsen1]

For Response Headers I have #268. For multiple security in try operation we can have a checkbox for each security instead of a dropdown that allows only one security to be selected at a time.

[webron]

@prabhatjha - I don't have a discussion thread on the matter, it's just one of the changes we put into the spec after many requests for it over the years.

@mazzock's design is not really far-fetched, and is actually relatively common. It's not really multiple authentications, but rather a single authentication with several layers. Nothing wrong there, and it's not really our place to say whether it is a proper or improper design, we're just here to help document it.

[tuukkamustonen]

We would be needing this as well.

In our case, couple of extra headers need to be sent, the same headers on every endpoint. They are not actually api keys or other authentication, but do relate slightly to security and identity of the user.

So practically, we would need "global headers" and not really "security headers". But afaik global headers are not even supported in the spec?

[mohsen1]

@tuukkamustonen You can define parameters globally using global parameters object. Then you can assign that parameter to each path. Every operation in that path will be using that parameter.

See this example:

---
swagger: '2.0'
info:
  version: 1.0.0
  title: Pets Store
parameters:
  x-something:
    name: X-Something
    in: header
    description: Global header `X-Something`
    type: string
paths:
  /pets:
    parameters:
      - $ref: '#/parameters/x-something'
    get:
      responses:
        200:
          description: Returns all the pets

[tuukkamustonen]

@mohsen1 Thanks, but I don't consider that "global parameters" :) I am actually using what you suggest here. The problem is (aside from the fact that you have to have those $refs here and there, which is not too bad), that these fields are endpoint-specific and not global like security fields. In other words, user has to always redefine these fields when doing test requests, even when they would remain the same throughout the endpoints.