Auth rules for oneToMany table

[clintfoster]

Is this feature request related to a new or existing Amplify category?

api

Is this related to another service?

GraphQL

Describe the feature you'd like to request

Suppose we have Flight and User models with a manyToMany relation called FlightPassengers, like so:

type Flight
  @model
  @auth(
    rules: [
      { allow: groups, groups: ["Admin"] }
      { allow: private, operations: [read] }
    ]
  ) {
  passengers: [User] @manyToMany(relationName: "FlightPassengers")
}

type User
  @model
  @auth(
    rules: [
      { allow: owner }
      { allow: groups, groups: ["Admin"] }
    ]
  ) {
  flights: [Flight] @manyToMany(relationName: "FlightPassengers")
}

The owner of a Flight can add passengers. But passengers should not be able to add themselves. Since the FlightPassengers join table is created implicitly, there seems to be no way to specify its auth rules. In fact, it's not clear what the rules are since there is no mention of it in the documentation.

I suppose something like an OR of the Flight and User rules might make sense as the default (and maybe that's how it works). But this is too broad for cases where the rules need to be narrower.

I tried field-specific auth rules, but it didn't work for restricting access to the join table itself (not surprising).

Related:

• DataStore query on many-to-many join table, using @manyToMany, not working, source tables are using owner auth. GraphQL create join table object, not working, due to missing owner field in Input model. amplify-codegen#473
• Correctly authorizing new many-to-many relationships with user pools amplify-cli#9387

Describe the solution you'd like

A naive approach might be to explicitly supply a join table model that contains the auth rules (but nothing else):

type FlightPassengers
  @model
  @auth(
    rules: [
      { allow: groups, groups: ["Admin"] }
      { allow: private, operations: [read] }
    ]
  ) {
}

However, this isn't quite right because it's relying on an Admin group to unify the two separate sets of rules. It prevents a passenger (User.owner) from updating the passenger list. But any Flight owner can modify the passenger list for all other flights. What we want is simply for the flight owner to be authorized to modify the Flight's passengers in the same way as individual Flight fields. But we do not want a passenger (User.owner) to modify the flight's passengers (any more than they should be able to modify the Flight fields).

This could be accomplished with a flag to extend the auth rules from only one of the two sides of the join table, e.g.:

type Flight @model {
  passengers: [User] @manyToMany(
    relationName: "FlightPassengers"
    useAuth: true
)}

Thus, if we can modify a flight, we can also modify its passenger list.

The useAuth flag essentially makes the auth rules for the join table the same as if it were a simple list within the model.

Describe alternatives you've considered

Additional context

I read through some similar posts in which people resorted to manually defining the join table. Since it seems common for a join table to have rules about who can modify it, this should be supported out of the box for "implicit" join tables, which are a great feature for reducing boilerplate code.

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request

Would this feature include a breaking change?

• ⚠️ This feature might incur a breaking change

[clintfoster]

I updated my description to reference this comment from @benjeater, who looked at the generated vtl to determine the current rules for the join table. That issue specifically mentions DataStore. But I think the discussion about auth rules for join tables also applies to GraphQL and AppSync.