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

So I am working on some lambda mutations to add some data safety. But I feel like I am lacking some know how on how to actually properly protect a mutation in graphql when just a @auth directive seems like not enough.

So to quickly sketch the situation.

There is for example a post type which has a createdDate and that createdDate should not be decided on the client, but from the server it self. So the user should not call addPost which is a mutation generated by draph automatically.

Instead the clien should call a mutation “addNewUserPost” which is attached to a lambda.
Which autofills the createdDate.

But I wanna avoid using DQL and just call the “addPost” graphql mutation instead so any @hasInverse gets properly triggered.

Which works amazingly except that a “malicious” user could still call addPost in the client it self.

So I actually only want to ever allow usage of “addPost” from inside a lambda call and not from anywhere outside of that scope.

How can this be resolved if it’s actually possible?

2 Likes

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.

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

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

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, 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 methods unfortunately.

Here is an example code you could easily copy in the Lambda Webhook to add a createdAt date, but automatic timestamps 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. This opens up many new options.

J

Ah thanks for the reply. I am pretty sure I read almost all the post you have made since I started diving more into dgraph.

And also came to the conclusion on most topics. I made this post with the hope I might have missed something graphql magic related. But it seems that we currently just need to wait for the update-after/field authorization feature.

So just for a short conclusion it’s not possible to have a lambda execute graphql queries that are not exposed to the client.

So to actually secure your graphql mutations you can put DENY auth rules in the create,update and create your own lambda that does it securely using DQL.

No, you can execute any GraphQL query / mutation you want within a lambda. It will, however, require you to pass the JWT if you use any @auth rules on that type. You can circumvent any @auth rules by just running dql.

Basically, yes and no. If the mutation is secured, you have to use dql.

There is another option, if you use firebase auth. You could create a firebase function for each mutation you want, and create the secure JWT in the google environment that can be verified with @auth. Of course this requires firebase functions, another environment outside of dgraph you have to pay for, slowing down the mutation. May be easier than lambdas in some cases.

I thought about writing an article on this, but hoping dgraph starts reading the forums first.

J

Yeah totally get what you mean but maybe I wrote it wrong, my bad for that.

I also approached the idea of using cloud functions to be the security layer and then indeed create JWT and use that in the request to pass auth.

But for now we’re just gonna focus on other parts of our system and keep our fingers crossed for the new dgraph release.

3 Likes