-
-
Notifications
You must be signed in to change notification settings - Fork 954
Open
Labels
enhancementNew feature or requestNew feature or request
Description
As part of #1254 I'm looking at documenting the way that securitySchemes
works, and it turns out it's a little more lackluster than I remember.
Right now, if you define an endpoint i.e.:
/apiKey:
get:
operationId: apiKey
description: Perform an authenticated request, using an API Key in the `X-API-Key` header
security:
- apiKey: []
responses:
# ... snip
This generates only the following code:
@@ -20,7 +20,6 @@ import (
)
const (
+ ApiKeyScopes = "apiKey.Scopes"
BasicAuthScopes = "basicAuth.Scopes"
)
@@ -55,8 +54,6 @@ type MiddlewareFunc func(http.Handler) http.Handler
func (siw *ServerInterfaceWrapper) ApiKey(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
+ ctx = context.WithValue(ctx, ApiKeyScopes, []string{})
+
handler := http.Handler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
siw.Handler.ApiKey(w, r)
}))
This still requires a lot of work to hand-roll server-side authentication.
We should instead generate
We can generated ??, and then rely on an implemented method sfor
multi reoutes
k
Although it can be possible to use the middleware to authenticate, I believe it's an area we can improve on.
We'll need to consider:
- the existence of the middleware(s) to not re-authenticate
- the existence of multiple means to authenticate - is it first one wins?
This should be opt-in.
Example schema:
Some code can be found in 09adbb0
See also:
mono424, jmaister, TcMits and markpsiano
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request