# Can I perform queries / mutations to /admin endpoint ignoring the auth rule?

**URL:** <https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999>\
**Category:** Dgraph Cloud\
**Tags:** kind:question\
**Created:** [July 18, 2021, 10:27am UTC](https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999 "2021-07-18T10:27:45Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**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:** [July 18, 2021, 10:27am UTC](https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999/1 "2021-07-18T10:27:45Z")

</div>

Hi there!

I managed to set up a neat system to update the schema on Dgraph Cloud from my local system. This way I can make use of VS Code’s GraphQl language support and other benefits. Since during the development phase I need to change and update the database constantly, I started developing a `seeder` which basically performs mutations to the `/graphql` endpoint. Obviously I am restricted by auth rules here so I was wondering if there is a way I could perform the same mutations via eg. the `/admin` endpoint which lets me perform all mutations without bothering about auth?

Thanks!

---

<div class="post-metadata">

**Author:** ![pshaddel](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pshaddel/32/11584_2.png) [@pshaddel](https://discuss.dgraph.io/u/pshaddel)\
**Post date:** [July 18, 2021, 10:43am UTC](https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999/2 "2021-07-18T10:43:46Z")

</div>

Hello @Poolshark  
I think there is no way to ignore the Auth rules but we did something similar by generating a jwt manually and using it in our requests from one of our servers. You have the `VerificationKey`, `Header Name` and `Algorithm` you can easily generate proper `jwt` with enough access to pass the auth rule. For example we manually added `admin` role as a claim in our `jwt`.  
Also if you want to test it you can generate jwt here: [http://jwtbuilder.jamiekurtz.com/](http://jwtbuilder.jamiekurtz.com/)

---

<div class="post-metadata">

**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:** [July 18, 2021, 7:42pm UTC](https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999/3 "2021-07-18T19:42:50Z")

</div>

Only with DQL queries/mutations, you could ignore any auth or something completely.

---

<div class="post-metadata">

**Author:** ![cjog](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/cjog/32/4709_2.png) [@cjog](https://discuss.dgraph.io/u/cjog)\
**Post date:** [July 19, 2021, 4:35pm UTC](https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999/4 "2021-07-19T16:35:33Z")

</div>

We are using the Managed Cloud offering for Dgraph and the current workflow while modelling schema looks something like this - For all integration tests against the DB, we pass a JWT token For the authenticated user to our GraphQL endpoints to pass the authorization check. The downside is that exploration via the GraphQL query editor integrated with the Cloud UI becomes unusable with the Authorization setup as currently there is no way to pass a token(which should be made available), but the team can still use the DQL editor and queries to poke around the structure and stored data skipping Auth and the GraphQL layer.

---

<div class="post-metadata">

**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:** [July 19, 2021, 6:05pm UTC](https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999/5 "2021-07-19T18:05:42Z")

</div>

> [@cjog](#):
>
> The downside is that exploration via the GraphQL query editor integrated with the Cloud UI becomes unusable with the Authorization setup as currently there is no way to pass a token

Maybe you have missed it. It is there. Look for “Request Headers” in the GraphQL explorer page right below the endpoint selection.

---

<div class="post-metadata">

**Author:** ![cjog](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/cjog/32/4709_2.png) [@cjog](https://discuss.dgraph.io/u/cjog)\
**Post date:** [July 19, 2021, 6:18pm UTC](https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999/6 "2021-07-19T18:18:05Z")

</div>

@amaster507 Thanks. Missed the pink link with request headers! 🙂

---

<div class="post-metadata">

**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:** [July 27, 2021, 4:20pm UTC](https://discuss.dgraph.io/t/can-i-perform-queries-mutations-to-admin-endpoint-ignoring-the-auth-rule/14999/7 "2021-07-27T16:20:36Z")

</div>

Thank’s for all the answers!

I have already thought that I have to solve this via passing a **JWT** to the public `/graphql` endpoint. It still was a bit of a mission since we use **Auth0** for our auth service, which generates the token using the `RS256` algorithm. Unfortunately the **private key** is not exposed in Auth0 and thus I had to sign the token using the **public key** which obviously generates the token with `HS256` (or something else but not RS256).

This left me with a workflow where I publish the entire schema including

```auto
# Dgraph.Authorization { "VerificationKey" : ... , "Algo": "HS256" }

```

then I **seed the data.** All the public nodes in the schema have a rule which grants access to a **deployment claim** in my JWT. This way I can make sure I don’t ha ve to fiddle around with auth.

After seeding I reset the auth back to the `RS256` algorithm.

Not the nicest way I guess but it works… Maybe this helps someone!
