# Lambda Server on Dgraph Cloud needs update! **URL:** \ **Category:** Dgraph Cloud / Slash GraphQL\ **Tags:** kind:bug, lambda\ **Created:** [April 4, 2023, 2:21pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473 "2023-04-04T14:21:08Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Poolshark](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/poolshark/32/10074_2.png) [@Poolshark](https://discuss.dgraph.io/u/Poolshark)\ **Post date:** [April 4, 2023, 2:21pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/1 "2023-04-04T14:21:08Z")
This issue is related to this [Bug](http://discuss.hypermode.com/t/only-a-single-header-gets-forwarded-to-lambda/18465), 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](https://github.com/dgraph-io/dgraph-lambda) GitHub repo! 1. 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](http://discuss.hypermode.com/t/custom-lambda-not-working-on-dedicated-cluster-with-namespaces-and-acl/17837/6) for more details)_. 2. 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](https://github.com/dgraph-io/dgraph-lambda/blob/main/src/dgraph.ts#L25) or [here](https://github.com/dgraph-io/dgraph-lambda/blob/main/src/dgraph.ts#L40), 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?** ---
**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\ **Post date:** [April 4, 2023, 4:17pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/2 "2023-04-04T16:17:03Z")
> [@Poolshark](#): > > Is this the reason why DQL queries do not care about `@auth` rules? 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. ---
**Author:** ![Poolshark](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/poolshark/32/10074_2.png) [@Poolshark](https://discuss.dgraph.io/u/Poolshark)\ **Post date:** [April 4, 2023, 4:32pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/3 "2023-04-04T16:32:03Z")
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` ? ---
**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\ **Post date:** [April 4, 2023, 5:29pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/4 "2023-04-04T17:29:42Z")
> [@Poolshark](#): > > X-Auth-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. ---
**Author:** ![Poolshark](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/poolshark/32/10074_2.png) [@Poolshark](https://discuss.dgraph.io/u/Poolshark)\ **Post date:** [April 4, 2023, 9:18pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/5 "2023-04-04T21:18:38Z")
@MichelDiz thanks! 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](https://dgraph.io/docs/v21.03/graphql/todo-app-tutorial/todo-auth0-jwt/)! 😂 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. ---
**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\ **Post date:** [April 5, 2023, 5:26pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/6 "2023-04-05T17:26:35Z")
> [@Poolshark](#): > > DG-Auth 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. > [@Poolshark](#): > > thus `Token` might be a bit misleading. Not sure what you mean. Misleading how? ---
**Author:** ![Poolshark](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/poolshark/32/10074_2.png) [@Poolshark](https://discuss.dgraph.io/u/Poolshark)\ **Post date:** [April 6, 2023, 6:30am UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/7 "2023-04-06T06:30:58Z")
According to [this](https://dgraph.io/docs/dgraphcloud/admin/authentication/) `DG-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](https://dgraph.io/docs/graphql/security/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. > [@MichelDiz](#): > > Not sure what you mean. Misleading how? 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. > [@Poolshark](#): > > - 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](http://discuss.hypermode.com/t/custom-lambda-not-working-on-dedicated-cluster-with-namespaces-and-acl/17837/6) for more details)_. ---
**Author:** ![Poolshark](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/poolshark/32/10074_2.png) [@Poolshark](https://discuss.dgraph.io/u/Poolshark)\ **Post date:** [May 4, 2023, 7:55am UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/8 "2023-05-04T07:55:36Z")
@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. ---
**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\ **Post date:** [May 6, 2023, 3:10am UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/9 "2023-05-06T03:10:54Z")
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. ---
**Author:** ![Poolshark](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/poolshark/32/10074_2.png) [@Poolshark](https://discuss.dgraph.io/u/Poolshark)\ **Post date:** [May 6, 2023, 5:27am UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/10 "2023-05-06T05:27:21Z")
Ah ok! Thanks for the update. 🙌 > [@MichelDiz](#): > > 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. Would be great if @Raphael can comment this. 🙌 ---
**Author:** ![Raphael](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/raphael/32/10075_2.png) [@Raphael](https://discuss.dgraph.io/u/Raphael)\ **Post date:** [May 6, 2023, 4:07pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/11 "2023-05-06T16:07:21Z")
@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… ---
**Author:** ![Raphael](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/raphael/32/10075_2.png) [@Raphael](https://discuss.dgraph.io/u/Raphael)\ **Post date:** [May 6, 2023, 4:08pm UTC](https://discuss.dgraph.io/t/lambda-server-on-dgraph-cloud-needs-update/18473/12 "2023-05-06T16:08:47Z")
and if you have a merge request to submit, go ahead, it will certainly help the team.