Skip to content
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

Conversation

mbarackman-coursera
Copy link
Contributor

  • 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.

@mbarackman-coursera mbarackman-coursera force-pushed the MPB-add-relation-auth-override branch 2 times, most recently from ed8fc7d to 2b61e7a Compare May 2, 2018 21:23
@@ -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")
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

@cliu587 cliu587 left a 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
Copy link
Contributor

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
Copy link
Contributor

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.
@mbarackman-coursera mbarackman-coursera merged commit 636c83f into coursera:master May 3, 2018
amory-coursera pushed a commit that referenced this pull request May 3, 2018
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants