This issue is related to this Bug, but, in my option, even it is even more critical.
The behaviour of a custom resolver when using namespaces is almost identical to the behaviour when using a local setup. However, the lambda source is definitely not the same on cloud as it is in the official dgraph-lambda GitHub repo!
For GraphQL queries AND DQL queries the X-Dgraph-AccessToken seems to be somehow forwarded, because BOTH of the built in functions (graphql, dql.query) work WITHOUT wrapping it into a custom fetch wrapper (see here for more details).
Both functions dqlQuery and dqlMutate seem to get an X-Auth-Token which is (or at least could have been) mounted on launch of the Dgraph lambda source. We can see this here or here, where an X-Auth-Token is extracted from the env object! Is this the reason why DQL queries do not care about @auth rules? If yes, what is the shape of this token? Could this be a security vulnerability?
Not related, no. DQL does not respect @auth rules because they are out of scope of the DQL.
When you run a GraphQL operation the GraphQL layer has the scope of the auth rules and rewrites using the rules compiling down into a singular DQL operation (or a mutate/query transaction in case of a mutation since DQL mutations do not return the data like GraphQL mustering expect). This is what I was trying to explain on a previous post with you.
But what has that to do with previous conversations?
If I find more time I will try to dig deeper into this to understand better what is going on. I assume that when a GraphQL schema gets deployed and the DQL schema gets generated, the DQL schema then simply doesn’t get the @auth rules since there is simply no way to do that in DQL (unless I’ve missed sth.). However, since all gets rewritten in DQL the same rewritten @auth queries could get attached to “nodes” which represent the dgraph.type when querying via DQL. But yes, this would be a bit weird to do and obviously a bit hacky.
The question now got even more interesting: If DQL does not respect @auth rules then why even attaching the X-Auth-Token to DQL requests? And what (if there is any) is that process.env.DGRAPH_TOKEN ?
That is Cloud related. In the community version you don’t have this. X-Auth-Token is not related to GraphQL Auth feature. It is “auth” for the cloud backend.
For some reason I had in mind that the X-Auth-Token is equivalent than the X-My-Auth-Token which holds the user claim. It’s been a long time since I’ve set up auth… Sorry!
However, if I understood correctly the X-Auth-Token is equivalent to the DG-Auth header which controls the unauthenticated access on cloud. The DG-Auth value is either a client or an admin key and thus Token might be a bit misleading.
Any comments on 1?
Update
@MichelDiz by the way, I knew that the X-Auth-Token was the @auth token in earlier docs! Had to check for my own sanity… However, I think the X-Auth-Token header value should be removed and replaced by DG-Auth only. It’s not a token, it’s either an admin or a client KEY. Not sure where else it appears in the source code though.
Is the a Cloud header, not Dgraph (it is in our cloud code). I think they are maintained due compatibility maybe. You can just ignore if it is not working for you case.
According to thisDG-Auth and X-Auth-Token are equivalent. You need it to allow anonymous access, which does not exist locally (and by the way, also not when using a Dedicated Cluster with ACL activated on Cloud).
Client applications accessing the Dgraph Cloud cluster endpoint
/graphql
with anonymous access not set on the requested operation, must present a valid client or admin API key in the Dg-Auth or X-Auth-Token header of every HTTP request.
I mean, that the X-Auth-Token value is a KEY and not a TOKEN(in terms of JWT) and thus this might be a bit confusing for some. It did for me but this relates to the fact that in earlier docs the X-Auth-Token was actually referred to as the @auth token.
However, the much more important issue is the forwarding of the X-Dgraph-AccessToken since without this, neither custom resolvers on the Cloud nor with the community version will work correctly.
@MichelDiz quick follow up: is this issue something which is looked into? Would be great since otherwise the required workaround causes quite a bit of unnecessary lambda bundle size, which could be crucial considering we only have 500KB on cloud.
Cheers!
PS.: I’m happy to contribute with a merge request if that would help.
I’m not actually working on it. It has some internal tickets related to Lambda. But I’m not involved. However feel free to send a PR if you have the solution.
Personally I don’t think this is an issue. But I’ll ping @Raphael to check it.
It is an issue because if you use ACL you cannot use any of the graphql or dql functions which get submitted to your custom resolver and thus you need to implement a custom wrapper for fetch. Furthermore, you have to request another login token (X-Dgraph-AccessToken) inside every custom resolver which is a bit weird considering that you have sent that token with the original request already.
Additionally, if you want to preserve user information regarding ACL rules, you would have to submit username and password (or even worse via a field in the GraphQL request) via the X-Auth-Token since that is the only header which is available.
The only other option is to have a lambda user which is allowed to do everything and to implement custom auth checks inside the resolver.
@Poolshark, I’m busy with conferences this week (TieCon) and next week ( Knowledge Graph conference in NY), but I can confirm that engineering is looking at this in the current sprint as we have both an enhancement request (JWT header in lambda) and an issue (that you kindly logged) about Lambda in multi-tenancy scenario, we talked about the context missing to properly use graphql and dql objects and we have your repro case that helps.
BTW The engineering team is visiting us in California for a couple of weeks. It makes things easier and I hope will make a lot of progress in the coming weeks…
Had to check for my own sanity… However, I think the 
