DQL queries need to respect GraphQL @auth rules

[gotjoshua]

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)

[amaster507 (Anthony Master)]

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?

[arijit (Arijit Das)]

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.

[gotjoshua]

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)

[amaster507 (Anthony Master)]

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:

We have a foe among friends

I’ve come up with an interesting setup myself here Cloudflare Workers + Access + Argo Tunnel - Workers - Cloudflare Community I have a DigitalOcean Droplet running Dgraph (for now… will use Kubernetes later) and Cloudflare Argo Tunnel running on my Dgraph Alpha Port (8080). I’ve got Cloudflare Access in front of my Load Balancer that makes the queries to Dgraph, so that only my Workers can send requests to it

[gotjoshua]

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:

@amaster507

There needs to be some built in security service besides enterprise ACL to block ANYONE from just firing up ratel and pointing it at my :8080/ endpoint and having full access bypassing the GraphQL endpoint entirely.

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:

@MichelDiz

For me, reverse proxies are the holy grail.

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

some references to proposals from the previous thread:

@pawan

Maybe we could also support starting Dgraph in GraphQL only mode which disables these endpoints by default so that the user doesn’t have to do this.

@pawan

Another solution here could be that we apply poor man’s Auth to query and mutate endpoint as well. It’s already applied to Admin operations but can also be used to secure the /query endpoint.

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

[pawan (Pawan Rawal)]

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.

[gotjoshua]

Thanks for your considerations !

@pawan

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.

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?