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?
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/
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.
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
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!
