Skip to content

Provide first-class (generated) code to support authentication/authorization #1524

@jamietanna

Description

@jamietanna

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:

#843
#177
#221
#911

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions