How would you go about protecting parts of your sc...
# orm-help
j
How would you go about protecting parts of your schema? E.g. only revealing that a said query exists if the user provides a valid token? I just learned that schema directives existed yesterday and I'm pretty hyped about those. Currently using them for auth purposes. Would that be something that could solve that problem?
j
Sweet! Thanks a bunch!
Both of these were really cool! The latter is a little outdated, as Apollo recommends to use schema directives instead of the old directives. Problem is, none of them really solves my issue. My goal is to hide the query from being visible to anyone who is not authenticated. So if you don't have a valid auth header you can't even see any of the mutations.
n
@Jenkins that can be solved with a simple Express middleware in the case of you hiding the complete schema
compare to the behaviour of a Prisma API that is secured with a secret and accessed without it - the introspection query is not returning anything.
m
@Jenkins that’s an interesting idea! I thought similarly and had an idea of creating a library to help you with that - heads up I hope it gets released very soon. Nevertheless, I don’t think that’s the best approach. I think that most of the cases can be handled with
shield
or just by wrapping your resolvers. Or, even better, just by writing the correct GraphQL Schema, but that’s a discussion for a blog post. What’s the reason for such immense need of hiding fields? Maybe you could just create two servers in that case! 🙂
n
if you want to hide individual fields, or even rename them, based on the user this can become quite tricky, but is still solvable.
j
For me it's more that there's not necessarily all the functionality of the api that I'd like to reveal to every user. Certain functionality like my own "ease of use tools" I'd like to not display but still be able to access when logged in.
For me, my own \@isAuthenticated directive works like a charm. Maybe I'll upgrade to shield should the need arise.
Thanks for your thoughts and inputs though! I only wish there was a way to "not hide everything" 😛
l
@Jenkins I linked in my article to the GitHub "debate" on exposing introspection queries. Did you give that a look? I'm solving this issue with two different APIs both backed by the same Prisma server. I know that's not a practical solution in many cases, but for apps like mine with public and admin sides, it should work well.
j
I missed that on my first read-through (I'm guilty of skimming). Reading it now!
g
I've used Graphql-shield. It can do the job pretty well. But Prisma says it is not meant to be used to serve directly to client
"You should only access your Prisma service from a frontend for prototyping or learning purposes. Please don't access your Prisma service from a production client side application."
j
I am well aware of that. My goal, however, is not one that graphql-shield solves. My goal is to further protect my outward-facing schema. No one in their right mind would expose their underlying DAL.
g
oh ok. got it.
m
@Jenkins what’s your timeline for this? I thought about putting together the library I mentioned above by the end of July. We could work on it together! 😄
j
Timeline is whenever wherever tbh. I'm only working on this as a hobby project.
And no worries, @Gijo Varghese! 🙂
g
@Jenkins I'm pretty new to Prisma. Just figuring out how this works
j
@Gijo Varghese same here! 🙂