# Slash DGraph Lambdas Feature Requests / Small Change **URL:** \ **Category:** Dgraph Cloud / Slash GraphQL\ **Tags:** slash-graphql, dgraph, kind:feature\ **Created:** [March 18, 2021, 10:17pm UTC](https://discuss.dgraph.io/t/slash-dgraph-lambdas-feature-requests-small-change/13288 "2021-03-18T22:17:45Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![jdgamble555](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/jdgamble555/32/7503_2.png) [@jdgamble555](https://discuss.dgraph.io/u/jdgamble555)\ **Post date:** [March 18, 2021, 10:17pm UTC](https://discuss.dgraph.io/t/slash-dgraph-lambdas-feature-requests-small-change/13288/1 "2021-03-18T22:17:45Z")
**Feature 1:** : Get rid of the need for all auth rules in lambdas when calling **graphql**. * * * Just a few posts on the topic: > [@Passing HTTP headers for @lambda](http://discuss.hypermode.com/t/passing-http-headers-for-lambda/11710/9): > > You can entirely bypass auth by making dql queries from lambda > [@How do I protect certain fields with Slash GraphQL](http://discuss.hypermode.com/t/how-do-i-protect-certain-fields-with-slash-graphql/13148): > > HI All, I am new here. Last few days I spent a lot of time reading and watching videos about DGraph and Slash. I have a starter account setup on Slash and we are trying to get a POC rolling for a big project that we are developing. So my setup is that the Frontend is going to be connected to the Slash Graphql directly and there are no other middle servers. I am failing to understand a very basic question. Which is a very common usecase IMO, but I did not find anything on this, so I will ask … * * * I believe they are completely unnecessary. If I can call a regular **DQL** query, it is definitely not more secure. Simple is better. Hacking the auth rules and changing them is bad coding IMHO, and erroneous work for developers. If the lambda is called from a custom mutation, that custom mutation should have it’s own auth rules. Simple. **Feature 2** : This is probably the easiest fix. Allow **DQL** within lambdas to accept JSON Mutation Format. You could easily [update the code here](https://github.com/dgraph-io/dgraph-lambda/blob/8bb34dd627d0522fe8c0516cf784a5ecadc89523/src/dgraph.ts#L39). My suggestion would be something as simple as: ```typescript "Content-Type": typeof obj == 'object' ? "application/json" : "application/rdf" ``` It may be a little more complicated than that, but you get the drift. Thanks, J ---
**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:** [March 18, 2021, 11:05pm UTC](https://discuss.dgraph.io/t/slash-dgraph-lambdas-feature-requests-small-change/13288/2 "2021-03-18T23:05:46Z")
Feature 1: Please don’t… Just because we can use dql to bypass auth rules does not mean that we want to bypass auth rules when also using graphql. I think this would also be more work than #2 Feature2: I assumed already that there was a way for the mutation to accept either json or rdf, but I hadn’t used it yet within a lambda. I 2nd this. ---
**Author:** ![jdgamble555](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/jdgamble555/32/7503_2.png) [@jdgamble555](https://discuss.dgraph.io/u/jdgamble555)\ **Post date:** [March 18, 2021, 11:59pm UTC](https://discuss.dgraph.io/t/slash-dgraph-lambdas-feature-requests-small-change/13288/3 "2021-03-18T23:59:16Z")
Feature 1: My argument is that **lambdas** are called from custom Mutations, Queries, and Types. All of those should have _their own auth rules_. The lambda field itself should be able to have its own auth rules. When **graphql** is called server-side, it makes no sense to require a second auth check on the graphql call. If you have some custom code with a situation that needs to check auth rules 2x, then maybe we make it optional. _Creating a new custom auth header to allow Admin access to a graphql mutation or query should not be an auth header hack._ In my mind calling **graphql** from on server-side should not have to require any headers, as it is being called on the admin level. That being said, the custom lambda field needs to be secure with its own auth rules. Feature 2: Nope, but should be a simple fix. * * * You’re not really calling **graphql** , you’re calling a function that calls **graphql** , which not all cases need secured **graphql** access since you customize and call that function in your own specific way. ---
**Author:** ![elyn\_T.G](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/elyn_t.g/32/7075_2.png) [@elyn\_T.G](https://discuss.dgraph.io/u/elyn_T.G)\ **Post date:** [March 19, 2021, 4:58pm UTC](https://discuss.dgraph.io/t/slash-dgraph-lambdas-feature-requests-small-change/13288/4 "2021-03-19T16:58:40Z")
While I am currently affected with this, Regarding #1 I would suggest that graphql should accept a different token from within lambdas. I can get or generate a new auth token in the lambda, slight inconvenience, but it can be done. and then if I can pass that new token in the graphql requests, it would allow me to send admin tokens. Also would recommend if we can allow having environment variables in the lambdas (I am going to create a new topic for it). so then I can add the admin credentials in the env, read those in the lambda, call a server or service to get a new JWT for admin and pass that to the graphql calls. EDIT: ok I see now that in the following post, it is already explained how to pass a new token to graphql, if that works then that is a proper solution IMO for #1 > [@Enforce one field based on another - kebab-case example](http://discuss.hypermode.com/t/enforce-one-field-based-on-another-kebab-case-example/12765/15): > > docs PR: [add auth header by verneleem · Pull Request #127 · dgraph-io/dgraph-docs · GitHub](https://github.com/dgraph-io/dgraph-docs/pull/127) A resolver example using a graphql call and manually overriding the authHeader provided by the client: async function secretGraphQL({ parents, graphql }) { const ids = parents.map((p) =\> p.id); const secretResults = await graphql( `query myQueryName ($ids: [ID!]) { queryMyType(filter: { id: $ids }) { id controlledEdge { myField } }\> }`, { ids }, { key: 'X-My-App-Auth' value: 'eyJhb… ---
**Author:** ![jdgamble555](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/jdgamble555/32/7503_2.png) [@jdgamble555](https://discuss.dgraph.io/u/jdgamble555)\ **Post date:** [March 19, 2021, 5:43pm UTC](https://discuss.dgraph.io/t/slash-dgraph-lambdas-feature-requests-small-change/13288/5 "2021-03-19T17:43:58Z")
> [@jdgamble555](#): > > Allow **DQL** within lambdas to accept JSON Mutation Format. Anyone at dgraph think we could get Feature 2 fixed? Thanks, J ---
**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:** [March 22, 2021, 2:07pm UTC](https://discuss.dgraph.io/t/slash-dgraph-lambdas-feature-requests-small-change/13288/6 "2021-03-22T14:07:29Z")
Feel free to open a PR and ping me.