New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce Related Resource Auth Override #248
Introduce Related Resource Auth Override #248
Conversation
ed8fc7d
to
2b61e7a
Compare
@@ -268,4 +296,10 @@ class NaptimeResolver extends DeferredResolver[SangriaGraphQlContext] with Stric | |||
} | |||
|
|||
|
|||
private[this] def getInternalRequestContext(context: SangriaGraphQlContext): SangriaGraphQlContext = { | |||
val originalRequestHeader = context.requestHeader | |||
val newHeaders = context.requestHeader.headers.remove("X-Coursera-User").add("X-Coursera-Source" -> "internal") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to move this to assembler's RemoteFetcher? that way implementation detail of how coursera handles auth isn't leaked onto the Naptime project and I believe that is the place where we have the final headers and instantiate the client so it feels like a more natural place to do this conditional logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I think that's doable and that all sounds reasonable. let me see
2b61e7a
to
4c2861b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I think you'll need to merge in the style changes from my scalafmt changes to land, unfortunately.
@@ -20,4 +20,12 @@ record ReverseRelationAnnotation { | |||
*/ | |||
relationType: enum RelationType { FINDER, MULTI_GET, GET, SINGLE_ELEMENT_FINDER } | |||
|
|||
/** | |||
* This is an optional field which will override the auth headers from the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's fix up this comment to not refer to headers. indicating that a different auth strategy from the default behavior I think is fine.
// Handle MultiGet and Non-Multigets differently, since multigets can be batched | ||
val forwardRelations = | ||
fetchForwardRelations(forwardRequests, resourceName, ctx) | ||
// partition forward requests by auth type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: the comment should reflect that we need to make 1 call of fetchForwardRelations
for each auth override type.
- This change allows API developers to create related resources that are fetched with “internal” auths. - This is done by adding an authOverride value to the reverse relation definition on the primary resource. - The purpose of this is to give developers the option to do authentication in only one place, the entry/parent resource, and use internal auth for all the related/child resources. This allows the child resources to be a bit more re-usable in that they can be attached to multiple parent resources that may all have different auth schemes.
3ccf982
to
d142d80
Compare
* Introduce Related Resource Auth Override - This change allows API developers to create related resources that are fetched with “internal” auths. - This is done by adding an authOverride value to the reverse relation definition on the primary resource. - The purpose of this is to give developers the option to do authentication in only one place, the entry/parent resource, and use internal auth for all the related/child resources. This allows the child resources to be a bit more re-usable in that they can be attached to multiple parent resources that may all have different auth schemes.
This change allows API developers to create related resources that are fetched with “internal” auths.
This is done by adding an authOverride value to the reverse relation definition on the primary resource. This will show up in the naptime resource schema and will be interpreted by assembler in order to request with the proper auth request headers.
The purpose of this is to give developers the option to do authentication in only one place, the entry/parent resource, and use internal auth for all the related/child resources. This allows the child resources to be a bit more re-usable in that they can be attached to multiple parent resources that may all have different auth schemes.