Open alyoshark opened 5 years ago
The context doesn't apply all the time: I recently wrote a API that have 2 different security mechanisms for admin and user side. On the other hand writing code annotation is less then 1% of the project coding time.
If we go on this path , we can also setup a default @Accept and @Produce , @Failure XXX and when a new developer will take a into documentation and code will start wondering where they came from .
I personalty don't see it's as a feature.
The global @Security tag is supported by specs 2.0. It certainly helps for swift developing. Hope you guys could add this feature later.
Any progress on this? Simply parse the @Security comment in global scope will do
how
the documentation suggests this is possible, but somehow no matter what I try, I can't get security definitions into my swagger.yaml
:thinking:
my problem was calling swag init --parseDependency
instead of swag init -g routes.go --parseDependency
when my main API definition isn't in main.go
- interestingly most fields were still being picked up but not licensing and security. Ignore that last bit, was looking in the wrong place.
Might be good to give a warning if certain fields aren't set
Any progress? Now I have to manually edit the docs.go file after each swag init to add global security.
@liuzou1991 This is an Open Source project, and any contribution is welcome.
There is actually a problem in Postman by excluding this functionality. Without a global security directive, Postman sets the API to "No Auth" at the root level. While not a Swagger problem, it becomes a problem when other providers rely on the full Swagger spec to be implemented. If I have time I can look through and see what fix would be possible.
@ubogdan Is there any documentation on the flow within the code?
Is your feature request related to a problem? Please describe. It's cumbersome to specify
@Security
on every controller if the entire API requires the same authentication mechanism.Describe the solution you'd like Something like below on the global context
Describe alternatives you've considered Can't think of a fair alternative to this
Additional context It's quite common for internal API application to use a global authentication mechanism. Would be great if it can be added.
If you think this request is applicable and needs help, I can work out a PR later. Thank you for providing such a great tool ❤️