How to apply Permissions in Redwood

Get Help and Help Others
1

Hello Redwood Team

Good to know that you have announced the Redwood’s 1.0 release date. Have you decided to include yoga-graphql as the GraphQL server in this release or would it be sometime later?

I have a question related to Roles and Permissions. What we usually do is the following:
1 User ----- One or Many roles And 1 role ---- One or Many Permissions

Example:
User John ---- Roles (Admin, Moderator) ---- Permissions (CRUD Users, Moderate Posts)

I have seen in an example that we can apply the @requireAuth directive to a resolver
deletePost(title: String!): Post! @requireAuth(roles: [“admin”, “publisher”])

I am wondering how to associate a role to many permissions and then assign the role to a resolver. Or, shall we treat the resolver name as a permission itself?

Is there any declarative way, just like @requireAuth above that allows us to restrict users based on a certain criteria, let’say, Customer 1 cannot view the Customer 2 details?

2

Yes, thanks to the Guild, release 1.0 does use GraphQL Yoga. Please see the announcement here: Redwood 1.0.0-rc.final is Available 🚀

tl;dr:

:yarn: Yarn 3 Hits the Primetime
:comet: So. Many. New Deploy Providers: baremetal, Flightcontrol, and Layer0
:atom_symbol: GraphQL Server goes Yoga

At the moment, the authentication model out of the box supports RBAC but not ABAC or permissions.

This is on the roadmap for v2. Auth0 and Okta and others do have some mechanism to set that info in their access tokens. Others like Supabase are also thinking about having this feature in the future.

This is something that if you are interested in, you could help define and pick the right tools and patterns – for example, evaluating packages like CASL.js to too if it is a good fit? Redwood will likely need and RFC to help guide that design and implementation process and we’d welcome your (and everyone’s) input.

At the moment, though you may be able to implement something on your own using a Validator Directive – FYI @requireAuth is just prepackaged validator directive – and then do your checks api side.

For web side, if you store some permission info on the user metadata, you may be able to do some permissions checks, but in a page/component rather at the router level.

3

@dthyresson

Good enough ! But the rc-1.0-source’s package,jso has reference to graphql-yoga/common only. And not the entire yoga package? Why so?

I almost forgot about Casl.js. I will again check it. Thank you.

4

I assure you, it’s using exactly what it needs to work with Redwood (including the new GraphiQL Playground). In fact, the maintainers of GraphQL Yoga were instrumental in its implementation.

I believe we don’t need a full http server that the node package uses:

See: graphql-yoga/packages/node/src/index.ts at 3c82b57cae526eb05249786e0212ea084dc12b7d · dotansimha/graphql-yoga · GitHub

import {
  createServer as createHttpServer,
  IncomingMessage,
  Server as NodeServer,
  ServerResponse,
} from 'http'
import { createServer as createHttpsServer } from 'https'
import { getNodeRequest, NodeRequest, sendNodeResponse } from './http-utils'
import { YogaServer } from '@graphql-yoga/common'

That would bundle all that in a serverless function, which isn’t needed.

And in fact the YogaServer itself is in @graphql-yoga/common'.

And the GraphQLHandler processes the request on its own.

1 Like
5

Thanks @dthyresson

I got the gist of what you had said about using yoga in RW. I’m now confident that RW’s GraphQL is much powerful than before.

Few questions and a feature request:
a. I hope RW would allow me using Casl.js with ease and I’d be able to bypass the Redwood’s RBAC. Kindly confirm.

b. Since RW is using yoga now, hope we can use yoga’s support for GraphQL subscriptions. yoga calls it SSE (Server Sent Events)

c. When you said… “Auth0 and Okta and others do have some mechanism to set that info in their access tokens”… which info are you referring to?

d. In production environment, does Redwood use Node pm2 which is the production process manager for Node apps with a built-in load-balancer? Looks like it does not. If not, hope RW team will add its support.

Thank you. So far so good.
Now I am almost sure that we will integrate RW-backend with our existing application and handover almost all tasks (except core business functionality) to RW.

1 Like
6

You can implement your own authorization system. RBAC is optional depending on your use of the authentication methods on the api side, but as I noted on the web side, you would have to have a means of checking roles or permissions other than or in addition to the hasRole available check.

Redwood has not yet tried to implement SSE yet for the graphql-server or tried to use the subscriptions on the web side. As I noted, this is on the V1+ roadmap. SSE and other subscriptions however, would likely need to be done in a server-full environment.

Please see the deploy instructions for “baremetal” here: Introduction to Baremetal | RedwoodJS Docs

This was announced in the latest release notes: Redwood 1.0.0-rc.final is Available 🚀

1 Like