4 ms·

These guides always ignore authentication/authorization. Is there a standard pattern or way to do these when using GraphQL? Edit: a quick search for apollo gra

• foota 9y ago
  For authorization, from what I've seen you'll generally enforce permissions inside resolvers. You can propagate a capability from one field to it's children, which allows you to not have to look up permissions on children fields.
  • patelpankaj 9y ago
    true, the context param in resolvers are the way to do so
    • foota 9y ago
      I was actually thinking more about passing it as part of the root. For instance, if a person can see all their friends, then you could construct the root for the friend with something like "public only" permission to that person's info, which would prevent someone from accessing private info when checked properly inside the person type. (Although you certainly can use context at the first resolver, it gets less useful the further down you go imo for authorization)
      • patelpankaj 9y ago
        that also makes sense; and I guess it's just a matter of use-case and preference.
• patelpankaj 9y ago
  well it is a quick guide. auth is a separate topic. Best way to do it is I guess through context in resolvers
• masklinn 9y ago
  > These guides always ignore authentication Can't you just use whatever transport-level auth you prefer? I'd assume most GQL queries are over HTTPS so you could use cookies, HTTP Basic, HTTP Digest, a custom HTTP Auth scheme, SSL certs, API keys (through Basic or headers), … the world's your oyster. Depending on your requirements or constraints, the authorisation would be handled either once at the top-level or on a resolver-by-resolver basis.
• nikolasburk 9y ago
  This guide really only provides an overview of what GraphQL is so I think it's fair they don't go in depth about auth topics. If you're curios how authorization can be implemented in a GraphQL server, I recommend the following tutorial: https://www.prismagraphql.com/docs/tutorials/graphql-server-development/permissions-thohp1zaih https://www.prismagraphql.com/docs/tutorials/graphql-server-... Also check out these two awesome projects that provide ways for implementing authorization with GraphQL: - https://github.com/a-type/prisma-authorized https://github.com/a-type/prisma-authorized - https://github.com/maticzav/graphql-shield https://github.com/maticzav/graphql-shield If you want to see a practical example of how authorization can be implemented, check out this example project: https://github.com/graphcool/prisma/tree/master/examples/permissions https://github.com/graphcool/prisma/tree/master/examples/per...
• johnernaut 9y ago
  I ran into the issue of authentication when trying to learn GraphQL. I made a Node/GraphQL/React boilerplate with an example implementation of authentication in place. It's my first foray into both Node and GraphQL so I apologize for any inconsistencies. https://github.com/johnernaut/express-graphql-react-boilerplate https://github.com/johnernaut/express-graphql-react-boilerpl...
• joshribakoff 9y ago
  It's simple. In graphql one request matches many routes. That's why when one resolver crashes that field gets null in the response but other fields from other resolvers are still present. (This could cause issues in some apps that would in turn overwrite valid data with a null if the user hits save and the app did not account for null fields). So for authorization your API simply returns the fields allowed but not the ones disallowed. Auth itself is also covered in the official docs for graphQL and express graphql. You can just put your passportJS user in the context as well as the express request object. Pretty straightforward. Hardest part is retrofitting clients to handle sometimes null fields since graphQL still gives a 200 status code. Clients need to be modified to check for graphQL errors object instead of relying on status codes
• zackify 9y ago
  I wrote about this last year, https://zach.codes/handling-auth-in-graphql-the-right-way/ https://zach.codes/handling-auth-in-graphql-the-right-way/ it can be pretty easy to do, but nobody talks about it... Write a parent function that all resolvers go through. you can then add checks if the resolver is public, or whatever you want