swaggo / swag

Automatically generate RESTful API documentation with Swagger 2.0 for Go.
MIT License
10.7k stars 1.2k forks source link

Global @security support #407

Open alyoshark opened 5 years ago

alyoshark commented 5 years ago

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

// @title My Awesome API
// @version 1.0
// @description This Is My Awesome API That Requires Global Security Check
// @host my.awesome.site
// @BasePath /api
// @Security ApiKeyAuth
// @securityDefinitions.apikey ApiKeyAuth
// @in header
// @name My-Auth-Key

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 ❤️

ubogdan commented 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.

kuoshijia commented 5 years ago

The global @Security tag is supported by specs 2.0. It certainly helps for swift developing. Hope you guys could add this feature later.

kuoshijia commented 4 years ago

Any progress on this? Simply parse the @Security comment in global scope will do

batara666 commented 4 years ago

how

markus-wa commented 3 years ago

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

liuzou1991 commented 2 years ago

Any progress? Now I have to manually edit the docs.go file after each swag init to add global security.

ubogdan commented 2 years ago

@liuzou1991 This is an Open Source project, and any contribution is welcome.

bekabaz commented 1 year ago

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.

bekabaz commented 1 year ago

@ubogdan Is there any documentation on the flow within the code?