The definition @policy doesn’t currently include input types or fields. There are some security scenarios where our team would prefer @policy pruning of inputs to be available.
Is this something that is possible for future versions of @policy or should we investigate implementing our own schema directive as an alternative?
Hey @Jonathan_Wondrusch, this sounds like a great feature request for the team: https://support.apollographql.com/
I don’t believe this is something the team has looked at recently but more insights into example schemas where this would be helpful could help us see the potential here.
One question I would have is that, if you put the @policy on a required argument then you really don’t even need it on the argument because it could just go on the field since you would have to provide the argument anyway.
So this is mostly helpful in optional arguments. In that case someone could get around policy checks but just not including the optional arguments, so this would be something in the business logic then where only if you include certain arguments, then it would return certain data which requires policy checks.
Would it be more helpful then instead to have a response policy check on the return data/types? This could still be on types/objects on the schema but we would have to add a response level check as this only happens today at request time