So Let’s break down my understanding and see if I am off base here anywhere: (sorry @tss) for hijackng your OP
@auth - can only be applied on types in the schema. And only accepts four properties, query, add, update, and delete. The rules defined on these four properties are applied to it’s parents generated queries and mutations in the resolving function to limit the data returned to rule matching data only.
delete[Type] - is a generated mutation as long as the type has either a field with the ID type or a field with the @id directive. This mutation will delete nodes based upon a required filter parameter. This mutation will respect the auth.delete rule(s), e.g. @auth(delete: { ... }).
@custom - can be applied on either a predicate in a type, or on a custom query or mutation. A custom query or mutation, requires this directive. e.g.
# a generated type field
type MyType @auth(delete: { ... }) {
id: ID
customField: returnedType @custom(...)
}
# custom query
type Query {
myCustomQuery: returnedType @custom(...)
}
# or custom mutation
type Mutation {
myCustomMutation: returnedType @custom(...)
}
None of the examples above accept the auth directive at the same place that accepts the custom directive. The auth directive is only valid on the generated type. When processing a delete of the example MyType with the generated deleteMyType mutation, the custom directive on the customField would only get called if that field was selected. And this call would happen pre-delete. I am also pretty sure that the custom directive is not able to distinguish if it is called from a getMyType, queryMyType, addMyType, updateMyType, or deleteMyType operation. All it knows is to run its function when requested without any data about the parent other than the parennt’s predicates to be able to pass them as props. (For instance the id can be passed and used inside of the custom directive.
This is my understanding based off from the docs and also confirmed in:
So as was stated, in that related topic, you can pass custom headers and even pass the entire header used for the auth directive. I see no way to do a DQL custom operation that respects the auth directive aside from a single case:
One work around, With a custom directive on the predicate it cannot be called on a node that the user does not have some form of access to (query, add, update, delete). So you could, very dangerously I will say, have a custom directive that runs a graphql delete operation passing through the JWT header. BUT!! this delete mutation could then be run on any query, add, update, delete operation. Let’s demo this:
Read the surrounding context and warnings above before trying this code:
type Child @auth(
query: { rule: "{$canQueryChild: { eq: "\true\" } }" }
add: { rule: "{$canAddChild: { eq: "\true\" } }" }
update: { rule: "{$canUpdateChild: { eq: "\true\" } }" }
delete: { rule: "{$canDeleteChild: { eq: "\true\" } }" }
) {
id: ID
name: String!
parents: [Parent]
}
type Parent @auth(
query: { rule: "{$canQueryParent: { eq: "\true\" } }" }
add: { rule: "{$canAddParent: { eq: "\true\" } }" }
update: { rule: "{$canUpdateParent: { eq: "\true\" } }" }
delete: { rule: "{$canDeleteParent: { eq: "\true\" } }" }
) {
id: ID
name: String!
children: [Child] @hasInverse(field: parents)
dangerouslyDeleteChildren: DeleteChildPayload @custom(
graphql: ...
)
}
# Dgraph.Authorization {"VerificationKey":"","Header":"","Namespace":"","Algo":"","Audience":[]}
But there are problems with this.
- This could be accidentally ran on a get*, query*, add*, update*, or delete* operation.
- The graph mutation to for deleteChild is not currently able to filter by the parent id, to delete children.