5 ms·

Looks very cool - How do you see permissions/roles/authenticated access being managed for APIs where say most gets are public but most puts and a few gets are p

by yodon 8y ago

Looks very cool - How do you see permissions/roles/authenticated access being managed for APIs where say most gets are public but most puts and a few gets are private? (I apologize if I missed that in the intro)

murdockq 8y ago
I have done this in a node app that acts as the intermediate / proxy between your frontend and the prisma service. Infact you can even run it as a serverless endpoint just fine to keep it lightweight.
- yodon 8y ago
  Is that whitelisting routes? I’m sure there’s a good solution, I’m just not sure how to make sure I’ve got the full surface area properly covered (which naively feels tricky to do with GraphQL but again I’m still trying to understand what are the best practices)
  - murdockq 8y ago
    I have had good results with https://github.com/maticzav/graphql-shield https://github.com/maticzav/graphql-shield but I am also keeping an eye on https://github.com/prismagraphql/graphql-middleware https://github.com/prismagraphql/graphql-middleware as it is written by the prisma team but isn't ready for production just yet.
tango12 8y ago
We take a slightly different approach at hasura. Every table/view (node) has declarative permissions defined. These are Boolean constraints that can use any property in the graph. The GraphQL data layer then ensures that the generated SQL query is intersected with those constraints for every node being resolved. This is works out well for performance also because you don’t have to proxy to the GraphQL proxy.
sorenbs 8y ago
As murdockq mentions, the recommended approach is to use GraphQL Bindings to create a lightweight GraphQL server that handles authentication and authorization. The combination of bindings and GraphQL Shield (which is awesome, btw - you should totally use it, even though it isn't maintained by the Prisma team) makes it easy to create and maintain this layer. The Graphcool Framework uses an approach similar to what Hasura is doing, but there are many use cases where this is simply not flexible enough.

by yodon 8y ago

murdockq 8y ago

I have done this in a node app that acts as the intermediate / proxy between your frontend and the prisma service. Infact you can even run it as a serverless endpoint just fine to keep it lightweight.

yodon 8y ago
Is that whitelisting routes? I’m sure there’s a good solution, I’m just not sure how to make sure I’ve got the full surface area properly covered (which naively feels tricky to do with GraphQL but again I’m still trying to understand what are the best practices)
- murdockq 8y ago
  I have had good results with https://github.com/maticzav/graphql-shield https://github.com/maticzav/graphql-shield but I am also keeping an eye on https://github.com/prismagraphql/graphql-middleware https://github.com/prismagraphql/graphql-middleware as it is written by the prisma team but isn't ready for production just yet.

tango12 8y ago

We take a slightly different approach at hasura. Every table/view (node) has declarative permissions defined. These are Boolean constraints that can use any property in the graph. The GraphQL data layer then ensures that the generated SQL query is intersected with those constraints for every node being resolved. This is works out well for performance also because you don’t have to proxy to the GraphQL proxy.

sorenbs 8y ago

As murdockq mentions, the recommended approach is to use GraphQL Bindings to create a lightweight GraphQL server that handles authentication and authorization. The combination of bindings and GraphQL Shield (which is awesome, btw - you should totally use it, even though it isn't maintained by the Prisma team) makes it easy to create and maintain this layer. The Graphcool Framework uses an approach similar to what Hasura is doing, but there are many use cases where this is simply not flexible enough.