How to handle Authorization with @custom queries

Users GraphQL
#1

I’m not sure how i should implement programmatic access control to a given resource.

For example, i only want users who have a specific data attribute to be able to consume a specific resource. This goes beyond “roles”, it’s literally executing business logic to determine access.

For example, how can i leverage @custom to determine if a user has access to a resource and return an error of sorts, or a custom payload, if the @custom directive’s result doesn’t grant access to the requested resource?

It would be nice to see this as a code example somewhere :slight_smile:

Improvements to Custom DQL feature
#2

Hey @davidLeonardi, I see that your last two questions are related to GraphQL. So, it should be at Users/GraphQL. I have moved it.

I think that would be a case for ACL. Not sure if the GraphQL Auth feature would do it.

I will ping someone.

1 Like
#6

Thanks for moving the topic!

In if it were about user roles, i’d agree that its an ACL issue. But it’s more about determining at runtime if the resource is authorized or not by executing arbitrary business logic.
I’m not trying to “cheap out of enterprise” here, its just a different usecase.
In essence, can i build a custom resolver for some endpoint that allows me to return whatever the logic determines to be fit for purpose? I have the feeling that @Custom is more appropriate? But thats just a hunch.

Thanks for any input!

#7

You can forward a JWT header token back to a @custom graphql query and apply that logic using @auth at that level not onside of the @custom directive.

1 Like
#8

Yes, you can.

Although, there is no way to combine @auth and @custom on a single field at present. But, as @amaster507 said you can always let your external @custom API handle that logic by forwarding the JWT. The external API can decide based on the JWT what response it should return. And your external API can also just be Dgraph’s GraphQL API where you can have @auth as pointed by @amaster507 :smiley:

Refer forwardHeaders in the docs here.

1 Like
Does dgraph support cascading delete？
Does dgraph support cascading delete？
#9

Is there any way to correctly format or forward errors when the authentication at the custom endpoint fails? Now you get:

{
  "errors": [
    {
      "message": "Evaluation of custom field failed because external request returned an error: unexpected status code: 401 for field: getCustomQuery within type: Query.",
      ...
      ]
    }
  ],
  ...
}
#10

No, none yet. No way to return errors from custom REST APIs, but custom GraphQL API errors are returned back in response.

Could you please put your opinion on this thread about how you would like to see errors returned in GraphQL response?

2 Likes
#12

This has since changed and in v20.11, errors returned from custom REST endpoints in a specific format (with errors key being an array of objects) would be returned back to the user. You can look at Feat(GraphQL): This PR allows to return errors from custom REST endpoint. by JatinDevDG · Pull Request #6604 · dgraph-io/dgraph · GitHub for more details. We’ll also get the docs up for it soon.

1 Like