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

Issues Dgraph
1

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?

2

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?

3

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
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:

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

5

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?

6

Hi @pawan,

Here’s the very last lines of my schema:


# 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.

7

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

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

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.

2 Likes