when you want to make several custom resolvers public in Pri Prisma #prisma-whats-new

when you want to make several custom resolvers pub...

rick

01/23/2018, 12:23 PM

when you want to make several custom resolvers public in Prisma, and the rest private, should you

disableAuth: true

or not? Or how should that work now?

Moritz

01/23/2018, 12:43 PM

Maybe for debugging/testing, but i would not recommend it even at dev stage. Take a look at resolver forwarding instead: https://github.com/graphcool/prisma/tree/master/examples/resolver-forwarding

rick

01/23/2018, 12:56 PM

I’ve looked through the code but does

forwardTo

allow you to not specify an authorization header (e.g. for signup) in the client request? Because when I enable auth I always have to send my token when I query my deployed endpoint

Moritz

01/23/2018, 2:18 PM

That fully depends on your server implementation. An authorisation header is not required generally by the server, but you can request auth from the context in the server, and then return the appropriate content or an error for unauthenticated requests. Generally, mutations such as the signUp mutation require logic anyways that should be defined in the server part of your app and should not be simple forwarded in general.

Moritz

01/23/2018, 2:24 PM

Ah I see the problem now, we are talking about slightly different things. The prisma part of the app needs an auth token from the server middleware to restrict the access. If you turn auth off, that is not required. However, that is highly insecure, as anyone knowing you cluster endpoint could alter your data. Simply setup using one of the node/ts boilerplates and deploy both the prisma service and the server. Then make client requests only to the server and you should be fine. If you need to expose some basic prisma methods to the client, do so through resolver forwarding and auth should not be an issue unless you want it to be 😎.

2 Views

Open in Slack

Previous Next