You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, GraphQL permissions checking is all handled up front by the main GraphQLPostHandler, which is the API entrypoint. This endpoint simply defines the expected set union of permissions for all of our implemented Fetcher and Mutator classes.
This is fragile, because adding a new Mutator might imply a new permission required for users executing this mutation. This requirement will not be captured by the GraphQLPostHandler and is very easy to miss during review.
This doesn't allow for granular user permissions, ex. read-only user roles, when interacting via the GraphQL API. Our standard HTTP API does implement granular permissions per endpoint, so it would make sense for GraphQL's fetchers and mutations to also have granular permissions in the same way.
Related to #947
Related to #760 (granular permissions will be useful for namespace isolation)
The text was updated successfully, but these errors were encountered:
Currently, GraphQL permissions checking is all handled up front by the main
GraphQLPostHandler
, which is the API entrypoint. This endpoint simply defines the expected set union of permissions for all of our implementedFetcher
andMutator
classes.Mutator
might imply a new permission required for users executing this mutation. This requirement will not be captured by theGraphQLPostHandler
and is very easy to miss during review.Related to #947
Related to #760 (granular permissions will be useful for namespace isolation)
The text was updated successfully, but these errors were encountered: