# Recommended way of running queries or mutations from the backend? **URL:** \ **Category:** GraphQL\ **Tags:** kind:question\ **Created:** [March 27, 2021, 8:58am UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427 "2021-03-27T08:58:15Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Saikat\_Das](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/saikat_das/32/7375_2.png) [@Saikat\_Das](https://discuss.dgraph.io/u/Saikat_Das)\ **Post date:** [March 27, 2021, 8:58am UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/1 "2021-03-27T08:58:15Z")
I have a backend API along with my single page app that will run queries and mutations to my database. Ideally, the @auth directives I’ve setup on my types should only apply to queries that come from my frontend. The backend should have unrestriced access to run any kinds of queries or mutations on the database. I’ve tried doing it with the Dg-Auth header along with a client API key on Slash GraphQL and sending requests using this from my backend but that doesnt seem to work. Are there any docs or guidance along doing this? ---
**Author:** ![Saikat\_Das](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/saikat_das/32/7375_2.png) [@Saikat\_Das](https://discuss.dgraph.io/u/Saikat_Das)\ **Post date:** [March 27, 2021, 9:25am UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/2 "2021-03-27T09:25:58Z")
To provide some more perspective, I come from a Firestore background where I did something similar. The Firestore auth rules apply to only queries coming from the firebase client running on users’ browsers. I would also have a REST API endpoint where I would be running firebase admin which would bypass the auth rules that are imposed on the client. Looking to do something similar here Here’s what I’m doing: - I’ve created a client API key on Slash GraphQL ![image](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/2/2aa384d20540a0d9df3f962275716f7f9e45b658.png) - I’m making requests to dgraph with a mutation like this from my backend ([Upload and share screenshots and images - print screen online | Snipboard.io](https://snipboard.io/Y7EMTR.jpg)) - Request headers look like this. The Dg-Auth is equal to the client token from slash ([Upload and share screenshots and images - print screen online | Snipboard.io](https://snipboard.io/UucKyX.jpg)) - Oh, and my schema looks like this ```auto type User @auth( add: {rule: "{$DENIED: {eq: \"DENIED\"}}"} update: { rule: """ query ($FUID: String!) { queryUser(filter: { firebaseUID: { eq: $FUID } } ) { firebaseUID } } """ } delete: {rule: "{$DENIED: {eq: \"DENIED\"}}"} ) { firebaseUID: String! @id displayName: String photoURL: String userContactDetail: ContactDetail! } ``` I’ve setup the add like above so that frontend users cant create new users, only my backend can Please help P.S. Apologies for the snipboard links, but discourse wont let me attach multiple screenshots ---
**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 27, 2021, 1:30pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/3 "2021-03-27T13:30:40Z")
When you say **backend** , are you talking about lamdas? I got backlash for pointing out that there should be no need for @auth directive when calling the query / mutation on a lambda. That query itself should be secured by you before it is run. > [@Slash DGraph Lambdas Feature Requests / Small Change](http://discuss.hypermode.com/t/slash-dgraph-lambdas-feature-requests-small-change/13288/1): > > Get rid of the need for all auth rules in lambdas when calling **graphql**. This would be a **breaking change** (even though it makes more sense), so I have not yet seen any support for this by my request. However, you can run **DQL** on the backend (you have to learn it) without @auth directive necessity. In a week or so, it will also support **JSON Mutations** … > [@Why does custom dql not support mutation?](http://discuss.hypermode.com/t/why-does-custom-dql-not-support-mutation/10366/11): > > Yes, we will get this done for the 21.03 release. But to answer your question, a backend should never need @auth rules. However you are calling that backend should (or be secure). At least in all standard software products… J ---
**Author:** ![Saikat\_Das](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/saikat_das/32/7375_2.png) [@Saikat\_Das](https://discuss.dgraph.io/u/Saikat_Das)\ **Post date:** [March 27, 2021, 1:36pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/4 "2021-03-27T13:36:47Z")
@jdgamble555 By backend I mean a separate NodeJS environment running an Express server, not running on DGraph Lambda It is secured in that it is a trusted environment that will only run queries that I’ve programmed in there on a specific route and is authenticated in that every request made to it goes through an auth middleware that makes sure only authorized users are trying and allowed to do what the particular endpoint logic is programmed to do. Does that answer your question? ---
**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 27, 2021, 1:42pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/5 "2021-03-27T13:42:25Z")
I think **DQL** still answers your original question, as I don’t know a way to disable @auth requirements in dgraph graphql in general… ---
**Author:** ![Saikat\_Das](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/saikat_das/32/7375_2.png) [@Saikat\_Das](https://discuss.dgraph.io/u/Saikat_Das)\ **Post date:** [March 27, 2021, 1:44pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/6 "2021-03-27T13:44:39Z")
@jdgamble555 Essentially, what I’m asking is, is there a way to run queries and mutations on my database bypassing the @auth rules specified on the types? Isn’t the client/admin API keys supposed to do that on Slash GraphQL? Is so, what’s the right way? Any documentation I can refer? ---
**Author:** ![Saikat\_Das](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/saikat_das/32/7375_2.png) [@Saikat\_Das](https://discuss.dgraph.io/u/Saikat_Das)\ **Post date:** [March 27, 2021, 1:45pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/7 "2021-03-27T13:45:55Z")
@gja Any thoughts on 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 27, 2021, 2:26pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/8 "2021-03-27T14:26:09Z")
I don’t believe so directly. If you want to do all that, you might as well host your own **dgraph** in a docker on your own server somewhere. SOMEONE PLEASE CORRECT ME IF I’M WRONG From my understanding the client token is to restrict anonymous access, and the admin token is for schema changes… [https://dgraph.io/docs/slash-graphql/admin/authentication/](https://dgraph.io/docs/slash-graphql/admin/authentication/) However, you can run a custom resolver to query your backend changes, and then post it: [https://dgraph.io/docs/graphql/custom/mutation/](https://dgraph.io/docs/graphql/custom/mutation/) But for more direct control of changes, you would create your own custom mutation through lamdas, which do give you direct access to **DQL** without @auth rules… [https://dgraph.io/docs/graphql/lambda/mutation/](https://dgraph.io/docs/graphql/lambda/mutation/) If you run your own **dgraph** server, you should have access to /mutation, /query, /alter… but even then it is **DQL** , not **graphql** … [https://dgraph.io/docs/get-started/](https://dgraph.io/docs/get-started/) This is my understanding, again, there may be another way I missed in the docs. **Note:** Really, the easiest way would be to create an ADMIN role in your @auth directives. That way you can call it however you want. That really depends on your authorization api… J ---
**Author:** ![chewxy](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/chewxy/32/4339_2.png) [@chewxy](https://discuss.dgraph.io/u/chewxy)\ **Post date:** [March 29, 2021, 1:19am UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/9 "2021-03-29T01:19:40Z")
I believe you can run mutations without auth if you use an admin token. ---
**Author:** ![Saikat\_Das](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/saikat_das/32/7375_2.png) [@Saikat\_Das](https://discuss.dgraph.io/u/Saikat_Das)\ **Post date:** [March 29, 2021, 5:04am UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/10 "2021-03-29T05:04:58Z")
@chewxy I get the same results with an admin token. ![image](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/b/bca33bfa9fe10bd1d2b19ab0c36bb80d7217fec5.png) I think it’s getting filtered out by the auth rules. Thoughts? ---
**Author:** ![maaft](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@maaft](https://discuss.dgraph.io/u/maaft)\ **Post date:** [March 29, 2021, 12:49pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/11 "2021-03-29T12:49:54Z")
1. Add additional `Role` field to your JWT 2. Chain multiple rules in your auth directive, e.g.: ```auto @auth( query: { or: [ # Admins can see all users { rule: "{$ROLE: { eq: \"ADMIN\" }}" } # users can see only their own data { rule: "query($USERNAME: String!) { queryOwnable{owner(filter: { username: {eq: $USERNAME }}) { username }}}" } ] } ``` ---
**Author:** ![Saikat\_Das](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/saikat_das/32/7375_2.png) [@Saikat\_Das](https://discuss.dgraph.io/u/Saikat_Das)\ **Post date:** [March 29, 2021, 12:53pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/12 "2021-03-29T12:53:49Z")
@maaft In case I go the Role route, how would I generate the JWT for the server? I am using firebase auth and following the guide provided here [https://dgraph.io/docs/graphql/todo-app-tutorial/todo-firebase-jwt/](https://dgraph.io/docs/graphql/todo-app-tutorial/todo-firebase-jwt/) So, here Firebase auth generates short lived 1 hour access token JWTs that Dgraph verifies using the auth mechanism specified. However, for the backend server, I dont see a straightforward way for the server to generate its own ADMIN role JWT tokens. Thoughts? ---
**Author:** ![maaft](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@maaft](https://discuss.dgraph.io/u/maaft)\ **Post date:** [March 29, 2021, 12:57pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/13 "2021-03-29T12:57:04Z")
I don’t know much about firebase, but: - you can generate an admin token and paste it on [jwt.io](http://jwt.io) to see its contents - if you see that the admin role is encoded somewhere, use this in your auth directive you can also have a look at: [Create Custom Tokens  |  Firebase](https://firebase.google.com/docs/auth/admin/create-custom-tokens) ---
**Author:** ![Saikat\_Das](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/saikat_das/32/7375_2.png) [@Saikat\_Das](https://discuss.dgraph.io/u/Saikat_Das)\ **Post date:** [March 29, 2021, 1:08pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/14 "2021-03-29T13:08:24Z")
I’ll wait to see if the team has any other suggestions where I dont have to do the heavy lifting myself in terms of generating custom tokens and maintaining them. And also sprinkling that extra line of checking if role equals admin on all the auth directives seems boilerplatey. I would love if what @chewxy suggested would work where I could just generate an admin token on Slash and that bypasses the auth roles completely ---
**Author:** ![maaft](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@maaft](https://discuss.dgraph.io/u/maaft)\ **Post date:** [March 29, 2021, 1:43pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/15 "2021-03-29T13:43:02Z")
For the boilerplate part: I suggest using interfaces and implement the auth rules there: E.g. ```auto interface Ownable @auth (....) { owner: User! } type Foo implements Ownable { ... } ``` ---
**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 29, 2021, 2:28pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/16 "2021-03-29T14:28:16Z")
1.) There are other use cases (in lambdas) for bypassing @auth directive on the server end when calling graphql. I again, submit this as a feature request. Of course it needs to be optional to not break the code when @auth is needed. 2.) There still should be a way to call **DQL** directly, bypassing @auth, so you might want to mess with that. 3.) There may also be a way with an ADMIN token to do this, **SOMEONE FROM DGRAPH PLEASE COMMENT HERE** so that we can see how it is done. 4.) As far as Firebase, you can easily use the ADMIN SDK to create a custom token. Of course, you need a user. You would just pick the uid of a user with the ADMIN role: ```auto admin .auth() .createCustomToken(uid) ``` Of course, that assumes the user already has the custom claim. If you add the custom claim on **user.onCreate** , then it should already be there. See my repo: > Hope this helps, J ---
**Author:** ![chewxy](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/chewxy/32/4339_2.png) [@chewxy](https://discuss.dgraph.io/u/chewxy)\ **Post date:** [March 29, 2021, 11:31pm UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/17 "2021-03-29T23:31:56Z")
> [@jdgamble555](#): > > 3.) There may also be a way with an ADMIN token to do this, **SOMEONE FROM DGRAPH PLEASE COMMENT HERE** so that we can see how it is done. It would appear I was mistaken. Sorry. ---
**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 30, 2021, 1:11am UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/18 "2021-03-30T01:11:52Z")
@chewxy - Is there a way to access **DQL** on the dgraph backend (not slash dgraph) besides within lambdas? ---
**Author:** ![chewxy](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/chewxy/32/4339_2.png) [@chewxy](https://discuss.dgraph.io/u/chewxy)\ **Post date:** [March 30, 2021, 3:18am UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/19 "2021-03-30T03:18:21Z")
Ya. You can connect to your Slash instance with your favourite Dgraph clients (mine’s [dgo](https://github.com/dgraph-io/dgo)). With it you can do all the DQL! ---
**Author:** ![d4nielhdz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/d4nielhdz/32/7610_2.png) [@d4nielhdz](https://discuss.dgraph.io/u/d4nielhdz)\ **Post date:** [May 5, 2021, 1:22am UTC](https://discuss.dgraph.io/t/recommended-way-of-running-queries-or-mutations-from-the-backend/13427/20 "2021-05-05T01:22:52Z")
I’m facing the same issue right now and the workaround I’m implementing is the following: - Create an admin user in Firebase auth (just a normal user) - Retrieve that user’s ID - When initializing the Apollo client, first use the `createCustomToken` method from admin passing that user ID and adding the ADMIN claim or whatever claim you want to use - Pass that token to Apollo client