Summary

Fixes a false accept security gap in GraphQL add mutations: when a nested insert links to an existing parent via @hasInverse, Dgraph mutates the parent's inverse predicate but previously only ran @auth add checks on newly allocated UIDs. Protected parents were never validated, allowing unauthorized users to modify admin-only nodes indirectly.

Example bypass (now blocked):

mutation {
  addFooItem(input: [{ parent: { id: "foo1" } }]) { numUids }
}

…when ProtectedFoo requires admin for both add and update.

• Track affected existing nodes during mutation rewrite when asIDReference() adds an inverse link to an existing UID (mutation_rewriter.go)
• After authorizeNewNodes(), run authorizeAffectedNodes() using update rules on those nodes (mutation.go)
• Scope affected-node auth to add mutations only to avoid breaking update mutation flows

Related discussion: https://discuss.dgraph.io/t/bug-auth-rules-of-parent-not-respected-when-child-with-hasinverse-is-added/12955

Test plan

• Unit rewrite tests: go test ./graphql/resolve -run 'TestAddChildRecordsAffectedProtectedParent|TestNestedAddRecordsDeepNewNodes' -count=1
• Auth query rewriting: go test ./graphql/resolve -run TestAuthQueryRewriting/Add_Mutation -count=1
• E2E integration: go test -tags=integration -run TestNestedAdd ./graphql/e2e/auth/... (requires Docker cluster with patched binary)

Made with Cursor