swag icon indicating copy to clipboard operation
swag copied to clipboard

Global @security support

Open alyoshark opened this issue 5 years ago • 7 comments

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

alyoshark avatar Jun 10 '19 12:06 alyoshark

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.

ubogdan avatar Jul 07 '19 11:07 ubogdan

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 avatar Aug 20 '19 09:08 kuoshijia

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

kuoshijia avatar Dec 26 '19 07:12 kuoshijia

how

batara666 avatar Sep 09 '20 18:09 batara666

~~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

markus-wa avatar Jun 01 '21 10:06 markus-wa

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

liuzou1991 avatar Aug 03 '22 07:08 liuzou1991

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

ubogdan avatar Aug 03 '22 11:08 ubogdan

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 avatar May 31 '23 17:05 bekabaz

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

bekabaz avatar May 31 '23 20:05 bekabaz