DEV Community: Rishichandra Wawhal

Common access control patterns with Hasura GraphQL Engine

Rishichandra Wawhal — Thu, 23 May 2019 18:22:36 +0000

Introduction

In this post, we will look at some access control patterns that can be used with Hasura to granularly allow/restrict the data. This is a summary blog post from Hasura Streams and the video has been uploaded to Youtube. If you prefer watching, similar examples have been covered in this video:

Hasura GraphQL Engine

Hasura GraphQL Engine is a thin GraphQL server that sits on any Postgres database and allows you to CRUD the data with realtime GraphQL and access control

This post assumes that you have basic understanding of Hasura and relational data models. Check out this guide if you have never used Hasura before.

Hasura enables role based access control which can be integrated with most Auth providers. The access control rules in Hasura are functions of session variables. Session variables are x-hasura-* variables like x-hasura-role, x-hasura-user-id that can be decoded from the request headers of the GraphQL request. You could have any number of session variables to make the rules more granular.

Let us see how to set up access control rules as functions of these session variables. Hasura infers the GraphQL schema from the Postgres schema, which means that setting access control rules on the tables, columns and their relationships corresponds to setting access control rules on the fields of your GraphQL schema.

Permissions

UI

The Hasura console has a neat UI for setting permissions. It also has a filter-builder that will make building filters and checks very joyful.

Roles

With each GraphQL request made to it, Hasura checks the role of the client user in the session variable x-hasura-role. Looking at this role, Hasura looks for the permissions for this role and allows or restricts CRUD accordingly.

The roles in Hasura have nothing to do with the Postgres roles and users. These roles are implemented at the Hasura Layer

You can define these roles in the Hasura console and there is no limit on multiple roles being defined.

Insert Permission

The permissions to insert rows in a table is composed of three parts:

Check constraint: This is a boolean value built out of session variables, values of the fields of the row being inserted and all the logical operators. For example, to insert into users table, you want to set a condition like { "id": { "_eq": "x-hasura-user-id" } }. This condition enforces that whenever a row is being inserted to the users table, it can only be inserted if the id of the row is equal to the x-hasura-user-id value in the session variables.
Columns: You can restrict insertion to only particular columns (rest of them being null, default or being inferred from column presets)
Column Presets: Column presets are values that you can set to be assigned to fields while they are being inserted. For example, when an entry is being inserted in a users table, we can take the id from x-hasura-user-id session variable. This helps to avoid parsing the session information on the client.

Select Permission

Filter: This is a boolean value built out of session variables and the values of the fields being selected. For example, in an articles table, you want all users to be allowed to query all published articles, but only their own unpublished articles. To implement that, you would add a filter like:

{
  "or": [
    {
      "author_id": {
        "_eq": "x-hasura-user-id"
      }
    },
    {
      "is_published": true
    }
  ]
}

Columns: Sometimes you want some roles to not have access to particular columns of the table. In such cases, you can explicitly choose which columns to allow and restrict.

Update Permission

Filter: This is a boolean value built out of session variables and the values of the fields being updated. For example, in an articles table, you want users to modify only their own articles. To do that, your update filter would look like:

{
  "author_id": {
    "_eq": "x-hasura-user-id"
  }
}

Columns: You can restrict which columns can be updated. This comes handy in cases when you do not want created_at field to ever be updated, but you might want to update the title field in the articles table.
Column presets: Like with insert, if you want to automatically update certain fields with certain values without it being explicitly mentioned in the request.

Delete Permission

Filter: Like with update, the filter on delete permisson is a boolean condition which needs to be satisfied before the the row can be deleted.

Examples

With the above ideas, let us look at some specific cases and how they can be modelled. Firstly, lets use a base schema for a HackerNews like application. This is the postgres schema:

Let me show you a sample GraphQL query to get all the articles along with their authors, comments, upvotes and downvotes.

query {
  articles {
    id
    title
    content
    content_type
    author {
      id
      name
    }
    comments {
      body
      id
      author {
        id
        name
      }
    }
    article_upvotes_aggregate {
      aggregate {
        count
      }
    }
    article_downvotes_aggregate {
      aggregate {
        count
      }
    }
  }
}

Now let us try to target some specific access control use cases with the above schema.

Enforcing users to insert articles as themselves

Say I am a user with id = 123. This means that the value of x-hasura-user-id in my session information would be 123. Now, when I am inserting an article in the articles table, you would want the author_id to be 123, which means you would want me to insert the article with myself as the author. To enforce that, you could take two approaches:

Through check constraint: In the insert permission of the articles table, you can set a check constraint like { "author_id": { "_eq": "x-hasura-user-id" } }. This would ensure that the article would be inserted only if the author_id in the insert payload matches the x-hasura-user-id in the session variables.
Through column presets: In the insert permission of the articles table, you can disable inserting into author_id column and set a column preset such that the author_id is automatically taken from the x-hasura-user-id session variable. In this way, the author_id would be inserted appropriately without the client needing to explicitly mention it.

You can use exactly the same approach for restricting users from updating articles that are not published by them.

Multiple roles

Say you have two roles: user and moderator. A moderator should be allowed to update the title of every post unconditionally while a user should be allowed to update the title only for their own posts. So the update permission for:

moderator: Should be allowed to update title and content of without any filter.
user: Should be allowed to update the title and content with the filter { "author_id": { "_eq": "x-hasura-user-id" } }.

Also, the moderator should be allowed to delete every post while a user should be allowed to delete only their own posts. So the delete permission for:

moderator: Should be allowed to delete without checks.
user: Should be allowed to delete with the filter { "author_id": { "_eq": "x-hasura-user-id" } }

Access control through views

In a typical news discussion app, the downvotes or upvotes on an article must be anonymous. This means, that the users should not be able to get all the information from article_downvotes and article_upvotes tables. To achieve anonymity, you can create a view that just has the article_id and the number of upvotes or downvotes. For article_downvotes, the view would look like:

CREATE VIEW article_downvote_count as
SELECT article_id,
  count(*) AS downvotes
FROM article_downvotes
GROUP BY article_id;

Now, once this view is created, you can set a select permission on this view such that it can be selected without any checks. You can implement the restriction similarly for article_upvotes table as well.

Downvoting based on Karma

In a website like HackerNews, you get down-voting privilege only when you reach a particular Karma (say 500). So on a table like article_downvotes which is a many to many relationship between articles and users, your insert permission would be:

{
  "and": [
    {
      "user" : {
        "id": {
          "_eq": "x-hasura-user-id"
        }
      }
    },
    {
      "user": {
        "karma": {
          "_gte": 500
        }
      }
    }
  ]
}

The above insert permission ensures that:

The user is inserting an entry as themselves (author_id is equal to x-hasura-user-id)
The insert is successful only if the inserting user has karma greater than or eual to 500.

Enforcing fields to have only particular values

You can emulate enum-like behavior using Hasura Permissions. For example, in the articles table, the content_type field should be either "url" or "text". Any other value is invalid. Therefore, the check condition of the insert permission on articles table looks like:

{
  "_and": [
    {
      "user" : {
        "id": {
          "_eq": "x-hasura-user-id"
        }
      }
    },
    {
      "content_type": {
        "_in": ["text", "url"]
      }
    }
  ]
}

This permission makes sure that:

The user is allowed to insert only as themselves. (author_id is equal to x-hasura-user-id)
In the article being inserted, the content_type field must be either "text" or "url".

You can similarly add different complicated access control rules for different roles and secure your data. Let us know if you have any questions in comments or join our Discord channel where we are super active. Also, let us know if you need more examples in the comments.

Reference

Building an image processing app with GraphQL and async serverless

Rishichandra Wawhal — Tue, 26 Mar 2019 11:17:50 +0000

TL;DR

Image processing is best done asynchronously so that the state is not lost when the app is refreshed
Serverless functions can be used to run the image processing logic
Realtime GraphQL helps you be in sync with the processing state
Hasura GraphQL Engine gives instant realtime GraphQL APIs over Postgres
Source code: client, image processing logic

Introduction

In this post we'll build a basic image processing app that lets you upload an image and add a sepia tone to it asynchronously. We will not go into the code subtleties as this is more of a philosophical rant about how async image processing apps can be built using realtime GraphQL and serverless.

We'll use:

Hasura GraphQL Engine as a free realtime GraphQL server over Postgres.

Hasura gives you realtime GraphQL APIs over any Postgres database

An event sourcing system to trigger external webhooks on mutations

Architecture

This app follows the 3factor.app architecture pattern. 3factor app is an architecture pattern for resilient and scalabale fullstack apps. It involves:

Realtime GraphQL
Reliable Eventing
Async serverless

In case of our image processing app, the flow boils down to:

The client uploads the image to cloud and inserts the image URL into the database with a GraphQL mutation. The client then watches the changes in the database for that particular image with GraphQL subscriptions.
When the image URL has been inserted in the database, Hasura's event system calls an external webhook with the image details
The external webhook converts the image to sepia tone, uploads the converted image to cloud and updates the database with the converted image URL
The client receives the update when the converted image has been uploaded to the database (GraphQL subscriptions)

Backend

First step is to get a realtime GraphQL server running in the form of Hasura GraphQL Engine. Click here to deploy it to Heroku's free tier with free Postgres (no credit card required).

Data Model

We need only one table for this app.

images (
  id serial not null primary key,
  image_uri text not null,
  converted_image_uri text
)

When you create this table called images, Hasura provides the following root fields in its GraphQL schema:

images: To query or subscribe to the list of images (comes with clauses such as where, order_by, limit)
insert_images: To insert one or more images into the images table
update_images: To update one or more images in the images table
delete_images: To delete one or more images in the images table

Image processing logic

We need our image processing logic that takes our uploaded image and adds a sepia tone to it. This could be written in any language or framework and deployed on any platform. For example, in NodeJS, you can write this logic using jimp and serverlessify it using Zeit. The code would look something like:

const jimp = require ('jimp');

function convertImage(image) {
    return jimp.read(image.image_uri).then(function(i) {
      return i.sepia().writeAsync(`/tmp/${image.id}.png`)
    })
}

The above function simply takes an object of the following form, converts it to sepia and stores the converted image at /tmp/.png.

{
    "id": 233,
    "image_uri": "https://mycloudbucket.com/image"
}

Once the image has been converted, you also want to update the converted image URI to the database.

const fetch = require('node-fetch');

function updateConvertedImage(image) {
  convertImage(image).then(function() {
    uploadToCloud(`/tmp/${image.id}.png`).then(function(uploadResp) {
      fetch(
        'https://image-processing-app.herokuapp.com/v1alpha1/graphql',
        {
          method: 'POST',
          body: JSON.stringify({
            query: `
              mutation ($id: Int, $converted: String) {
                update_images (
                  _set: { converted_image_uri: $converted }
                  where: { id: { _eq: $id } }
                ) {
                  returning {
                    converted_image_uri
                    id
                  }
                }
              }
            `,
            variables: {
              converted: uploadResp.secure_url,
              id: image.id
            }
          })
        }
      ).then(function(response) { return response.json() })
      .then(function(responseObj) { console.log(responseObj) })
    })
  })
}

Event sourcing

Hasura lets you define event triggers that listen on mutations and invoke an external webhook with the mutation data. We will create one such event trigger that listens on insert_images mutation and calls the webhook that performs the logic discussed above.

With this, our backend is ready.

Frontend

Most of the logic happens on the backend, so the front-end stays fairly clean. The front-end has two screens:

Upload screen: Uploads image to cloud, inserts the image URL in the database and redirects to the Convert screen with URL param id=<image_id>
Convert screen: Waits for the image to get processed and shows the converted image

Upload screen

This screen does the following:

Takes image from user
Uploads image to cloud
Inserts this image in the database with GraphQL mutation
Redirects to the new screen with URL parameter id= where image_id is the unique id of the inserted image

The GraphQL mutation for inserting the image to the database looks like:

mutation ($uri: String) {
    insert_images (
    objects: [{
        image_uri: $uri
        }]
    ) {
    returning {
            id
        image_uri
    }
    }
}

The above mutation inserts the image URI to database and returns the id of the inserted row. Next, you redirect to the Convert screen where you wait for the processed image.

Convert screen

In the convert screen, you look at the id of the image in URL parameters and make a live query to the database with GraphQL subscriptions. The subscription looks like:

subscription ($id: Int) {
  images (
    where: {
      id: {
        _eq: $id
      }
    }
  ) {
    id
    image_uri
    converted_image_uri
  }
}

While rendering the UI, you would check if the received converted_image_uri is null. If it is, you show a loading indicator, or you show the converted image. If done in React with Apollo's Subscription components, it would look something like:

import React from 'react';
import { Subscription } from 'react-apollo';
import gql from 'graphql-tag';

const ConvertScreen = () => {
  const urlParams = new URLSearchParams(window.location.search);
  const id = urlParams.get('id');

  return (
    <Subscription
      subscription={
        gql`
          subscription ($id: Int) {
            images (
              where: {
                id: {
                  _eq: $id
                }
              }
            ) {
              id
              image_uri
              converted_image_uri
            }
          }
        `
      }
      variables={{id}}
    >
      {
        ({data, error, loading}) => {
          if (error) { console.error(error); return <ErrorScreen /> }
          if (loading) return <LoadingScreen />;
          if (data.images.length === 0) {
            return "Invalid image ID";
          }
          if (!data.images[0].converted_image_uri) {
            return <LoadingScreen />
          }
          return (
            <ImageScreen
              original={data.images[0].image_uri}
              converted={data.images[0].converted_image_uri}
            />
          );
        }
      }

    </Subscription>
  )
}

As you see, in the above component:

If there is an error in subscription, we render some error UI.
If the subscription is in loading state, we show a loading UI.
If the subscription response is empty i.e. there is no row in the database where id is equal to the given id, we say that the id in the URL parameters is invalid.
If we get a response but the converted_image_uri is null, we assume that the processing is still in progress
If we have a valid converted_image_uri, we render it.

Finishing up

We discussed a pattern to build async image processing applications. You could use this architecture to build mostly all kinds of async applications. Check out 3factor.app and hasura.io to know more about building resilient and scalable fullstack applications.

If you have any questions, stack them up in the comments and they'll be answered ASAP.

References

graphql2chartjs: Realtime charts made easy with GraphQL and ChartJS

Rishichandra Wawhal — Fri, 15 Mar 2019 09:49:11 +0000

We started using ChartJS with GraphQL so that we could leverage GraphQL's realtime subscriptions to build realtime charts. Soon enough we realised that we can automate this process of restructuring the GraphQL data to a form that ChartJS expects.

graphql2chartjs is an open source tool that reshapes your GraphQL data as per the ChartJS API. This makes building charts as easy as simply making a GraphQL query.

The idea behind this tool is to generate ChartJS compliant data object from your GraphQL response by simply adding a few aliases in your GraphQL query.

Check out a live demo here

Usage with Hasura

Hasura gives you an instant realtime GraphQL API on an existing Postgres database. You can create views to capture analytics and aggregations on your database and instantly turn them into charts.
If you're using Postgres and Hasura, this is what using graphql2chartjs looks like:

Watch this video below to see a demo/tutorial of using Hasura with an existing Postgres database, creating views and building charts.

Continue reading: https://blog.hasura.io/graphql2chartjs-realtime-charts-made-easy-with-graphql-and-chartjs