Skip to content

Commit ba67dd4

Browse files
[amplify-data] feat: add gen1 manyToMany auth discussion (#8172)
* feat: add gen1 manyToMany auth discussion * Fix directive format Co-authored-by: Rene Brandel <[email protected]> --------- Co-authored-by: Rene Brandel <[email protected]>
1 parent 2061840 commit ba67dd4

File tree

2 files changed

+58
-0
lines changed
  • src/pages/gen1/[platform]/build-a-backend/graphqlapi

2 files changed

+58
-0
lines changed

src/pages/gen1/[platform]/build-a-backend/graphqlapi/customize-authorization-rules/index.mdx

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -860,6 +860,58 @@ Refer to the [sample code](/gen1/[platform]/build-a-backend/graphqlapi/connect-f
860860

861861
</InlineFilter>
862862

863+
### Authorizing `@manyToMany` relationships
864+
865+
Under the hood, the [`@manyToMany` directive](/gen1/[platform]/build-a-backend/graphqlapi/data-modeling/#many-to-many-relationship) will create a "join table" named after the `relationName` to facilitate the many-to-many relationship. The authorization rules that Amplify applies to the "join table" it creates are a union of the authorization rules of the individual models in the many-to-many relationship.
866+
867+
For example, consider a schema in which the owner of a `Post` (protected by an `owner` rule) can apply `Tag`s that are created by a system admin (protected by a `groups` rule). Behind the scenes, Amplify creates a `PostTags` table with both `owner` and `groups` auth:
868+
869+
```graphql
870+
type Post
871+
@model
872+
@auth(
873+
rules: [
874+
{ allow: owner }
875+
]
876+
) {
877+
id: ID!
878+
title: String!
879+
content: String
880+
tags: [Tag] @manyToMany(relationName: "PostTags")
881+
}
882+
883+
type Tag
884+
@model
885+
@auth(
886+
rules: [
887+
{ allow: groups, groups: ["admins"] }
888+
]
889+
) {
890+
id: ID!
891+
label: String!
892+
posts: [Post] @manyToMany(relationName: "PostTags")
893+
}
894+
895+
### CREATED BEHIND THE SCENES
896+
type PostTags
897+
@model
898+
@auth(
899+
rules: [
900+
{ allow: owner }
901+
{ allow: groups, groups: ["admins"] }
902+
]
903+
) {
904+
id: ID!
905+
postId: ID!
906+
tagId: ID!
907+
post: Post!
908+
tag: Tag!
909+
owner: String
910+
}
911+
```
912+
913+
For more control over the join table's authorization rules, you can create the join table explicitly, linking it to each model with a `@hasMany`/`@belongsTo` relationship, and set appropriate auth rules for your application.
914+
863915
### How it works
864916

865917
Definition of the `@auth` directive:

src/pages/gen1/[platform]/build-a-backend/graphqlapi/data-modeling/index.mdx

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -793,6 +793,12 @@ const posts = listPostsResult.data.listPosts;
793793
const postTags = posts[0].tags; // access tags from post
794794
```
795795

796+
<Callout>
797+
798+
**Important**: The authorization rules that Amplify applies to the "join table" it creates are a union of the authorization rules of the individual models in the many-to-many relationship. See [this discussion](/gen1/[platform]/build-a-backend/graphqlapi/customize-authorization-rules/#authorizing-manytomany-relationships) for more context.
799+
800+
</Callout>
801+
796802
## Assign default values for fields
797803

798804
You can use the `@default` directive to specify a default value for optional [scalar type fields](https://docs.aws.amazon.com/appsync/latest/devguide/scalars.html) such as `Int`, `String`, and more.

0 commit comments

Comments
 (0)