DQL queries need to respect GraphQL @auth rules

If I set up a GraphQL schema with @auth rules, do / will DQL queries respect them?

It seems that I can freely query via the DQL /query endpoint even though the /graphql endpoint is requiring an auth header… ( It also seems that this is by design or for some reason considered by the core team to be fine )

Is there a way to disable the DQL endpoint or otherwise convince it to respect the @auth rules?

I mean I know @auth rules via JWT are literally called PoorMansAuth… but that doesn’t mean they ought to be soooooo easily subverted.

If this is an up-sell strategy then I guess I can say “fair enough”

(Dgraph IS giving away a seriously awesome product)

… if that is the case, I’d prefer that this apparent awkwardness be explicitly portrayed as a strategic limitation, intended to make enterprise ACL more attractive.

… if not, then it would be great to have some sort of simple way to disable DQL
or better yet, teach DQL to respect the GraphQL @auth rules (as the schema’s are so intimately linked anyway)

1 Like

DQL does not respect and cannot respect GrqphQL auth rules as those rules are at a higher level in the algorithms. Having DQL is like having direct database access without an API and the graphql endpoint would be equivalent to an API using the data.

You can get core ACL with the enterprise edition which may be needed for some use cases.

The DQL endoints are normally whitelisted in self hosted environment. In Slash, you have to have the auth token to use the DQL endpoints. I believe this is only for the DQL endpoints on Slash though. Maybe someone from @core-devs could confirm this?

3 Likes

Yes. DQL endpoints are not openly accessable in slash. The Graphql layer sits on top of DQL layer. You can configure to make the DQL API accessable.

That’s good to know about slash… I am most concerned with self hosted community edition… Trying to wrap my head around best practices… And to understand what features belong to which situation… (Enterprise, slash, community)

You can use another service to restrict access to your restricted endpoints if you are using self-hosted. You could even setup similar to Slash on a self-host by creating a auth layer between dgraph and the world. Check out what @dmitry did here:

well yes a lot is possible with extra layers,
i also already set up traefik to block the DQL query endpoint… but…

I fully agree with this sentiment:

for me this could be as simple as an alpha command line flag something like :
--disable-dql-endpoints or more fine grained:
--disable-dql-query --disable-dql-alter etc…

and i don’t quite agree with this sentiment:

although I do indeed respect traefik and will use that technique if nothing else is possible.

some references to proposals from the previous thread:

Is there any movement on these possibilities in the core team?

1 Like

Have to discuss this with the team but I think we could have a command-line flag for Alpha called mode which could have the value as graphql or classic. In the GraphQL mode, /query, /mutate and /commit would not be available. /alter would still be available but that’s behind Poor man’s auth anyway. In classic mode, everything would be available.

Another option is to apply Poor man’s auth to these endpoints but that might be too restrictive for some users who are already using us.

Thanks for your considerations !

I think this would be another helpful option
--endpoint-mode=graphql | classic | classic+auth
Then it would be “opt-in” and those who find it too restrictive would automatically avoid it.
There is also an accepted issue about this. Maybe the discussion about what to call the flags and if you want to offer a poorman’s auth option for the endpoints belongs there…

Side question:
Does the term “Poor man’s auth” refer only to protecting the /alter endpoint with a static token, or does it also include the @auth GraphQL directives?