-
Notifications
You must be signed in to change notification settings - Fork 91
Support for "securityDefinitions" #54
Comments
IMO, your current solution seems like the most reasonable way to accomplish this. Defining the base In that case, some clarification/examples in the docs might help. If this is insufficient for your needs, can you elaborate more on how you would like to see this working? |
The current solution is perfectly fine for me. But what I had in my mind, was to extract these |
Thanks @SandhyaGiri this definitely makes sense. I think I'm just trying to reason about conflict resolution in the event that there are two different security definitions with the same name. For example:
and then another view:
In this case, which definition would we expect to see in The thing I like about your solution is that there is one and only one way to define the security definitions. It looks like |
Currently even though "securityDefinitions" section is provided in the documentation for the API, it is not reproduced in the final JSON produced.
Sample Documentation on a API method (with securityDefinitions section)
Expected JSON response
Following definition should be present at the root level of the JSON generated.
Actual JSON response
Carries only the security requirement for the corresponding path, and the 'securityDefinitions' section is missing.
Current solution is to add it manually to the generated JSON object, like below:
The text was updated successfully, but these errors were encountered: