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.
@auth
directive and
graph traversal queries.
To implement graph traversal rule on GraphQL API operations :
- Ensure your have configured the GraphQL schema to Handle JWT tokens
using
# Dgraph.Authorization
This step is important to be able to use the JWT claims - Annotate the Types in the GraphQL schema with the
@auth
directive and specify conditions to be met forquery
,add
,update
ordelete
operations.
Contact
type can only use a queryContact
query :
claims
found in
the JWT token. In this case, the query is executed with the value of the USER
claim.
When a user sends a request on /graphql
endpoint for a get<Type>
or
query<Type>
operation, Dgraph executes the query specified in the @auth
directive of the Type
to build a list of “authorized” UIDs. Dgraph returns
only the data matching both the requested data and the “authorized” list. That
means that the client can apply any filter condition, the result is the
intersection of the data matching the filter and the “authorized” data.
The same logic applies for update<Type>
and delete<Type>
: only the data
matching the @auth query are affected.
@cascade
directive, making the
directive more like a pattern matching condition.
For example, in the cases of To do
, the access depends not on a value in the
to do, but on checking which owner it’s linked to. This means our auth rule must
make a step further into the graph to check who the owner is :
username
must be equal to the JWT claim USER
.
All blocks must return some data for the query to succeed. You may want to use
the field __typename
in the most inner block to ensure a data match at this
level.
Rules combination
Rules can be combined with the logical connectivesand
, or
and not
. A
permission can be a mixture of graph traversals and role based rules.
@auth
on interfaces
The rules provided inside the @auth
directive on an interface are applied as
an AND
rule to those on the implementing types.
A type inherits the @auth
rules of all the implemented interfaces. The final
authorization rule is an AND
of the type’s @auth
rule and of all the
implemented interfaces.
Claims
Rules may use claims from the namespace specified by theDgraph.Authorization
or claims present at the root level of the JWT
payload.
Error handling
When deploying the schema, Dgraph tests if you are using valid queries in your @auth directive. For example, usingqueryFilm
for a rule on a type Actor
results in an error: