Update authorization and pagination docs #1814
Conversation
|
@mandiwise is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel. A member of the Team first needs to authorize it. |
src/pages/learn/authorization.mdx
Outdated
| ## Using type system directives | ||
|
|
||
| In the example above, we saw how authorization logic can be delegated to the business logic layer through a function that is called in a field resolver. | ||
|
|
||
| Another approach when implementing authorization checks for a GraphQL API is to use [type system directives](/learn/schema/#directives), where a directive such as `@auth` is defined in the schema with arguments that can indicate what roles or permissions a user must have to access the data provided by the and fields where the directive is applied. For example: | ||
|
|
||
| ```graphql | ||
| directive @auth(rule: Rule) on FIELD_DEFINITION | ||
|
|
||
| enum Rule { | ||
| IS_AUTHOR | ||
| } | ||
|
|
||
| type Post { | ||
| authorId: ID! | ||
| body: String @auth(rule: IS_AUTHOR) | ||
| } | ||
| ``` | ||
|
|
||
| It would be up to the GraphQL implementation to determine how an `@auth` directive affects execution when a client makes a request that includes the `body` field for `Post` type. However, the authorization logic should remain delegated to the business logic layer. |
There was a problem hiding this comment.
I'm struggling to see how this leaves the logic in the business logic layer - isn't it the GraphQL layer here that's dictating that the rule to use is IS_AUTHOR rather than the business logic?
There was a problem hiding this comment.
I agree, this one is a bit ambiguous. I thought it was worth mentioning the type system directive approach because I've seen it used so often (whether or not it's a great idea to mix up auth rules in a schema). But I struggled to come up with a good example here that was adjacent to the prior example and also adheres to what would be considered the best practice. If you'd rather not invite readers to consider this option, I can just remove the section. Alternatively, I could remove the example and just provide a couple sentences explaining that people may see the type system directive approach in the wild. Let me know.
Co-authored-by: Benjie <[email protected]>
Co-authored-by: Benjie <[email protected]> Co-authored-by: Jonathan Berger <[email protected]>
Co-authored-by: Benjie <[email protected]>
Co-authored-by: Benjie <[email protected]>
Co-authored-by: Benjie <[email protected]>
Co-authored-by: Benjie <[email protected]>
Co-authored-by: Benjie <[email protected]>
Co-authored-by: Benjie <[email protected]>
Co-authored-by: Benjie <[email protected]>
src/pages/learn/authorization.mdx
Outdated
|
|
||
| ## Using type system directives | ||
|
|
||
| In the example above, we saw how authorization logic can be delegated to the business logic layer through a function that is called in a field resolver. |
There was a problem hiding this comment.
Following on from https://github.com/graphql/graphql.github.io/pull/1814/files#r1852923240
Instead of trying to fit the auth directive approach into the "business logic layer" narrative, let's explicitly call it out as an alternative - something that people do but is not the recommended way:
| In the example above, we saw how authorization logic can be delegated to the business logic layer through a function that is called in a field resolver. | |
| In the example above, we saw how authorization logic can be delegated to the business logic layer through a function that is called in a field resolver. In general it is recommended to perform all authorization logic in the business logic layer, however if you decide to implement authorization in the GraphQL layer instead then one approach is to use [type system dire... |
(merge with next paragraph)
The remainder of the text in this section would also need light editorial to reflect this.
What do you think?
There was a problem hiding this comment.
Sounds good, addressed in 587906a.
|
We're back to 136 files changed @mandiwise; I think something went wrong with your merge/rebase |
Description
This PR contains updated authorization and pagination content for the Learn docs. Key changes include:
postRepositorycode example has been expanded for clarity@benjie @jorydotcom