# Authorization issue when schema is updated via /admin/schema?

**URL:** <https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795>\
**Category:** Dgraph\
**Tags:** graphql\
**Created:** [February 16, 2021, 3:07am UTC](https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795 "2021-02-16T03:07:32Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![matthewmcneely](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/matthewmcneely/32/4774_2.png) [@matthewmcneely](https://discuss.dgraph.io/u/matthewmcneely)\
**Post date:** [February 16, 2021, 3:07am UTC](https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795/1 "2021-02-16T03:07:32Z")

</div>

There seems to be an issue when trying to use authorization when schemas are managed from the /admin endpoint.

Dgraph Version: v20.11.1  
Docker: v20.10.2

In graphql/schema/schemagen.go::parseSecrets() a bufio.Scanner is supposed to iterate over the schema lines, but via tracing this I can see the schema that is passed to `parseSecrets` is glommed together (with no newlines).

I searched for issues regarding this, didn’t see any. If this is a duplicate can you please close this and point me to the open issue?

---

<div class="post-metadata">

**Author:** ![dmai](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/dmai/32/1254_2.png) [@dmai](https://discuss.dgraph.io/u/dmai)\
**Post date:** [February 19, 2021, 4:59pm UTC](https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795/2 "2021-02-19T16:59:15Z")

</div>

Is there an error that you’re seeing? I’m not exactly sure what the issue is here.

Can you share any reproducible steps and what you expect to see?

---

<div class="post-metadata">

**Author:** ![matthewmcneely](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/matthewmcneely/32/4774_2.png) [@matthewmcneely](https://discuss.dgraph.io/u/matthewmcneely)\
**Post date:** [February 19, 2021, 5:48pm UTC](https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795/3 "2021-02-19T17:48:36Z")

</div>

OK, sorry I wasn’t clear. The title of this issue should have been:

“Authorization configuration not recognized when schema is updated using admin REST endpoint”

Steps to reproduce:

1. Add a `# Dgraph.Authorization` line to a schema
2. Add an @auth directive to any type
3. Update the schema via the admin REST API

```auto
curl -v -X POST --header 'content-type: application/octet-stream' localhost:8080/admin/schema -d '@./schema.graphql'

```

1. Restart dgraph
2. Make a graphql request with a valid JWT that should pass the @auth directive.

The query/mutation will not return/alter (silently which is by design apparently)

Obviously with a valid JTW the expected outcome is that the query/mutation should succeed.

In order to diagnose the problem, I forked dgraph and inspected how the `# Dgraph.Authorization...` was getting parsed. I discovered that the schema was being sent to graphql/schema/schemagen.go::parseSecrets() with no newlines (which that function expects).

In order to test my theory, I made a simple string replacement in that method which appends a newline just before the schema is parsed.

Check out this diff:

> **[Comparing...](https://github.com/dgraph-io/dgraph/compare/v20.11.1...matthewmcneely:matthewmcneely/feature-auth-issues)**
>
> The high-performance database for modern applications - Comparing dgraph-io:v20.11.1...matthewmcneely:matthewmcneely/feature-auth-issues · dgraph-io/dgraph

When the schema is altered by the oneline change in that diff, the query/mutation works.

---

<div class="post-metadata">

**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\
**Post date:** [February 22, 2021, 6:07am UTC](https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795/5 "2021-02-22T06:07:32Z")

</div>

Hey @matthewmcneely

Can you share the GraphQL schema that you used for this? Does it have `# Dgraph.Authorization` on a new line? We store the schema as it is along with whatever newlines are provided and use the same on a restart. Do your query/mutations succeed without doing a restart?

---

<div class="post-metadata">

**Author:** ![matthewmcneely](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/matthewmcneely/32/4774_2.png) [@matthewmcneely](https://discuss.dgraph.io/u/matthewmcneely)\
**Post date:** [February 22, 2021, 7:20pm UTC](https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795/6 "2021-02-22T19:20:08Z")

</div>

Hi @pawan,

Here’s the very last lines of my schema:

```auto

# Dgraph.Authorization {"JWKURL": "http://host.docker.internal:4456/.well-known/jwks.json", "Header":"Authorization", "Namespace":"https://dev.revuud.io/jwt/claims", "Audience":["dev.revuud.io"]}

```

These lines are at the very end of a 800 line file. So yes, it does have that special sequence at the start of a newline. My assertion is that when schemas are updated via the /admin REST API, for some reason all the newline characters are getting stripped out. I confirmed this by dumping the `sch` variable in the `parseSecrets` method: no newlines, the schema comes in as one long string.

Did you see my diff? If I run an alpha image with that code in it, the special authentication line is found and the @auth directives are enforced correctly.

---

<div class="post-metadata">

**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\
**Post date:** [March 2, 2021, 8:59am UTC](https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795/7 "2021-03-02T08:59:56Z")

</div>

hey @matthewmcneely

Sorry, it took so long. So basically new lines are getting stripped because of the `-d` flag that you are using in cURL. If you were to change it to `--data-binary` newlines won’t get stripped. Try this command

```auto
curl --data-binary '@./schema.graphql' -X POST localhost:8180/admin/schema

```

---

<div class="post-metadata">

**Author:** ![matthewmcneely](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/matthewmcneely/32/4774_2.png) [@matthewmcneely](https://discuss.dgraph.io/u/matthewmcneely)\
**Post date:** [March 3, 2021, 6:10pm UTC](https://discuss.dgraph.io/t/authorization-issue-when-schema-is-updated-via-admin-schema/12795/8 "2021-03-03T18:10:29Z")

</div>

Hi @pawan,

Wow, sorry to waste your time on my lame CURL comprehension. Thanks for hunting this down for me…

It does bring up a point that I think this issue illustrated. The declaration of the JWKS credentials or endpoint (`#Dgraph Auth....`) probably doesn’t belong in the SDL this way, relying on newlines to be present to parse correctly.

I know there was some talk of moving authz control to the /admin endpoint. Definitely would help with this and would ease testing and staging, where now manipulating the SDL in CI is required for the jwks URL to point to the correct location.
