# Is it possible to allow certain graphql mutations to only be executed by a lambda?

**URL:** https://discuss.dgraph.io/t/is-it-possible-to-allow-certain-graphql-mutations-to-only-be-executed-by-a-lambda/15236
**Category:** GraphQL
**Tags:** kind:question, lambda
**Created:** [August 8, 2021, 2:35pm UTC](https://discuss.dgraph.io/t/is-it-possible-to-allow-certain-graphql-mutations-to-only-be-executed-by-a-lambda/15236 "2021-08-08T14:35:39Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### 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: [August 8, 2021, 5:21pm UTC](https://discuss.dgraph.io/t/is-it-possible-to-allow-certain-graphql-mutations-to-only-be-executed-by-a-lambda/15236/2 "2021-08-08T17:21:24Z")

</div>

Search for any of my posts, and pretty much all of them are talking about this problem.

Currently, there is only one real way to solve the problem: Custom [Lambda Mutations](https://dgraph.io/docs/graphql/lambda/mutation/).

Here is an example of how you would get the information in the mutation, and re-run the query in **DQL**.

> [@Auth variables access on custom resolver](http://discuss.hypermode.com/t/auth-variables-access-on-custom-resolver/13893/2):
>
> In a custom lambda, you can access the authHeader directly, although I think they eventually plan to support @auth fields: And you can repass the header to another graphql request like so: J

However, you can also re-run the **GraphQL** in the docs. Basically, you secure the regular mutations like this:

> [@Federation, API Key gated Mutations](http://discuss.hypermode.com/t/federation-api-key-gated-mutations/15136/2):
>
> ```auto
> type User @auth(
> add: { rule: "{$DENIED: { eq: \"DENIED\" } }"},
> update: { rule: "{$DENIED: { eq: \"DENIED\" } }"}
> delete: { rule: "{$DENIED: { eq: \"DENIED\" } }"}
> ) {
> 
> ```

Obviously, the problem is that you have to create a **custom lambda mutation** for every type you have, possibly 3 different ones (update, add, delete) and secure the regular ones with **deny**. For the moment, this is the only real way to secure your mutation.

It is worth noting, that for certain cases, like the **createdAt** date, you could use the [Lambda Webhook](https://dgraph.io/docs/graphql/lambda/webhook/), which is a **post-hook** to do things **after** the data is already added or updated in the database. However, you have no access to the before data. There are no [pre-hook](http://discuss.hypermode.com/t/webhook-lambda-on-add-update-delete-mutations/12904/8) methods unfortunately.

Here is an [example code](http://discuss.hypermode.com/t/slash-dgraph-backend-security-field-validation-and-timestamps/13317) you could easily copy in the **Lambda Webhook** to add a **createdAt** date, but [automatic timestamps](http://discuss.hypermode.com/t/query-sever-timestamps-in-graphql/7091/20) is another feature request we hope to see one day.

As far as realistic security, a lot could be solved if Dgraph would simply add [update-after](http://discuss.hypermode.com/t/feature-request-update-after-auth-validation/14799). This opens up many new options.

J

---

_[View the full topic](https://discuss.dgraph.io/t/is-it-possible-to-allow-certain-graphql-mutations-to-only-be-executed-by-a-lambda/15236)._