feat: sra i&a: implement auth resolution workflow in middleware #462
Conversation
lucix-aws
force-pushed
the
feat-sraauth-middleware
branch
from
c49b305 to
208fee8
Compare
lucix-aws
changed the title
lucix-aws
force-pushed
the
feat-sraauth-middleware
branch
from
208fee8 to
15a7ba2
Compare
lucix-aws
force-pushed
the
feat-sraauth
branch
from
1cac3db to
5e0d11c
Compare
lucix-aws
force-pushed
the
feat-sraauth-middleware
branch
from
15a7ba2 to
fcb1d8f
Compare
| @@ -998,6 +999,18 @@ public ChainWritable() { | |||
| writables = new ArrayList<>(); | |||
| } | |||
|
|
|||
| public static ChainWritable of(GoWriter.Writable... writables) { | |||
| @@ -294,6 +316,71 @@ private void generateApplicationProtocolTypes() { | |||
| }).write(""); | |||
| } | |||
|
|
|||
| private void writeProtocolResolvers() { | |||
There was a problem hiding this comment.
nit: writeProtocolResolvers and generateProtocolResolvers sound like the same thing. it looks like the former is more writing/generating the invocations and the latter is doing the definitions, so maybe work those intentions into the name of the functions
| @@ -2,7 +2,6 @@ package http | |||
|
|
|||
| import ( | |||
| "context" | |||
| "net/http" | |||
There was a problem hiding this comment.
nice, i wonder if it was just an oversight that we werent using the smithy request object already
There was a problem hiding this comment.
Well this is the new signer type from a previous PR, but yes I felt that it should use the smithy transport type instead of the underlying one.
|
|
||
| public static GoWriter.Writable generateAddMiddleware() { | ||
| return goTemplate(""" | ||
| err = stack.Finalize.Add(&$L{ |
There was a problem hiding this comment.
I'm not 100% sure about this, but I don't think this middleware is needed.
In generateSelectScheme() of the auth scheme middleware, identity resolvers are already invoked to see if it's valid or not for choosing an auth scheme, so I think you can just attach that resolved identity to the resolvedAuthScheme.
There was a problem hiding this comment.
We check that the resolver exists there at that time, but we don't actually get the identity until this middleware (hence getIdentityMiddleware).
We could definitely save the resolver on the first call as you've said though it's really only a string lookup.
main changes:
resolveAuthSchemeresolveIdentitysignRequestMiddlewareFinalizeInput, we can add it but I'm leaving it as something to explore externally. For the most part I think what's important is that identity resolution is part of finalize such that retries handle it.AuthSchemeDefinitionto expose codegen to plug inIdentityResolverOptionsexpressions andAuthSchemeexpressions.misc:
operationNameinterface on input structs. Operation name is now bound directly on middleware add.vars of anonymous empty structs.HttpBearerAuthintegration (moved to SDK), the generated code is not compatible with I&A as it bakes the signer into the client config.