We’re overhauling Dgraph’s docs to make them clearer and more approachable. If
you notice any issues during this transition or have suggestions, please
let us know.
Add
Rules foradd
authorization state that the rule must hold of nodes created by
the mutation data once committed to the database.
For example, a rule such as the following:
add
rule, in this case saying that you can only add to-do list
items with yourself as the author.
Delete
Delete rules filter the nodes that can be deleted. A user can only ever delete a subset of the nodes that thedelete
rules allow.
For example, the following rule states that a user can delete a to-do list item
if they own it, or they have the ADMIN
role:
- For most users, the following mutation deletes the posts that contain the term “graphql” and are owned by the user who runs the mutation, but doesn’t affect any other user’s to-do list items
- For an admin user, the following mutation deletes any posts that contain the term “graphql”, regardless of which user owns these posts
Update
Updates have both a before and after state that can be important for authorization. For example, consider a rule stating that you can only update your own to-do list items. If evaluated in the database before the mutation (like the delete rules) it would prevent you from updating anyone elses to-do list items, but it does not stop you from updating your own to-do items to have a differentowner
. If evaluated in the database after the mutation occurs, like for add
rules, it would prevent setting the owner
to another user, but would not
prevent editing other’s posts.
Currently, Dgraph evaluates update
rules before the mutation.