-
-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Description
Is your feature request related to a problem? Please describe.
Currently none of the security features are supported by the go-server generator.
This makes it difficult
Describe the solution you'd like
At a minimum, a good first step would be having at least one of the features implemented.
I proposed ApiKey or BearerToken as they seem the most general and easiest to handle and/or pass through specially compared to OAuth or OpenIDConenct.
I'm not sure on how best to handle the parsing of the session information (i.e. token/user etc), the way I did a proof-of-concept was by using the context.,
In this case I passed it straight through:
ctx := context.WithValue(r.Context(), "user", r.Header.Get("APIKey"))
// Where APIKey comes from the securitySchemes.token.name where securitySchemes.token.type == "apiKey".But ideally on a per-service basis you would want to be able to write code that maps the API key to a user ID/email or some kind of other session ID so each respective route could query that (and then it potentially wouldn't need to worry about what kind of method for security was used down stream).
Server Author
As the server author, you exposed with the ability to write a function that provides your own code to handle how to handle the API Key, Bearer token, etc and convert it to appropriate object for use by the API endpoints, such that you can query active identity (user/session) and optionally was the request authenticated.
Bonus
Check the security requirements of operations and generate corresponding checks and error conditions.
This likely would be better raised as a separate issue if its not done to satisfied this request, however without any handling at all for security schemas its not doable.
Describe alternatives you've considered
There doesn't seem to be a nice way already to do this.
The other idea, I had would be to utilise the mux routing to handle the authentication.
This would be better than requiring each generated control function needing to handle authentication.
This one is something I might take a look at doing as that could mean the auth would only require one change in the generated main() function.
The alternative router supported by the generator chi, seems to support this as well through its middleware handler.
Additional context
I fairly new to Go so I am really not sure what the best way to do this, but I figure best to at include some ideas.