Moving GraphQL Authorization to admin API

Issues GraphQL
, ,
3

Are there any updates for this?

While I still believe Dgraph needs pre-hooks as well as post-hooks, some kind of security rules are a must. @auth is just a taste of what is needed.

Here are some more examples from other similar database systems (not even including Firestore, Firestore Auth, Auth0, or neo4js):

There are really 3 types of rules here:

  • SQL like syntax with checks (postgresql, mysql)
  • Python like syntax with basic functions (firestore, nhost)
  • Where clauses (supabase, @auth)

– But really we are just talking about two things Validation (what) and Authorization (who).

My suggestion would be to have something like Schema Rules separate from the regular schema for readability, basically just a small extension of @auth.

Which brings me to simply extending what we already have:

Current solutions (untested):

type Todo @auth(
    add: { rule: """
         .... insert rule here
        }"""
    }
){
...

required field (not null) - although schema already has this with “!”:

queryPosts(filter: { has: [name, description] } }

field restriction (null) - don’t allow certain fields to be added

queryUsers(filter: { not: { has: role } }

required field - only allow a field to have a certain value

queryUsers(filter: { role: { eq: 'user' } }

min, max restraints - field value can only be between x and y

queryStudent(filter: {age: between: {min: 10, max: 20}}){

required field (allow enum only values)

queryState(filter: {code: {in : ["WA", "VA"]}}){

required field (allow only email type)

queryUser(filter: { email: { regexp: '/^\S+@\S+\.\S+$/' } })

Note: These may not work exactly like this, and will need lots of ands and ors, but you get the point. Please post any corrections here, as I am still learning…

Suggestions (Feature requests):

So in order to have real validation, graphql needs to be more robust in dgraph. This is happening naturally over time with new features to meet the needs of all users, and be as useful as dql.

So, we really just need to add two things here to @auth graphql particularly:

  1. Request data access - a $DATA variable to access incoming request values, or events, to compare data in an update rule
  2. Update after logic - basically add a rule like update-after or update: { after: { that works exactly like the add rule which can run logic on the incoming data as if it were already in the database

This should take care of 99% of the user cases for validation. We can check case logic, incoming update regex, update field validation, old value must equal new value, etc, etc…

And a possible more advanced feature later:

  1. Variable Queries - allow querying a field value and saving it in a variable to compare it to $DATA.field (same way upserts work) – particularly necessary if two nodes are the same but different ids… not sure if this is a big use case or not

With these other requested features to make it complete of course:

  • pre-hooks can handle any custom cases - which is really just @lambdas on existing add / update mutations and not custom mutations, different from post-hook
  • A separate @auth schema for readability
  • Automatic Timestamps to cover date constraints

I feel like this would solve the majority of validation problems many complain is missing… ( or maybe it is just me :wink: )

Thanks,

J

Related Post:

4 Likes