GraphQL Authorization
Authorizations can be applied in these places:
- Types:
- Objects (all classes descending from
::Types::BaseObject) - Enums (all classes descending from
::Types::BaseEnum)
- Objects (all classes descending from
- Resolvers:
- Field resolvers (all classes descending from
::Types::BaseResolver) - Mutations (all classes descending from
::Types::BaseMutation)
- Field resolvers (all classes descending from
- Fields (all fields declared using the
fieldDSL method)
Authorizations cannot be specified for abstract types (interfaces and unions). Abstract types delegate to their member types. Basic built in scalars (such as integers) do not have authorizations.
Our authorization system uses the same DeclarativePolicy
system as throughout the rest of the application.
- For single values (such as
Query.project), if the currently authenticated user fails the authorization, the field resolves tonull. - For collections (such as
Project.issues), the collection is filtered to exclude the objects that the user’s authorization checks failed against. This process of filtering (also known as redaction) happens after pagination, so some pages may be smaller than the requested page size, due to redacted objects being removed.
Also see authorizing resources in a mutation.
The best practice is to load only what the currently authenticated user is allowed to view with our existing finders first, without relying on authorization to filter the records. This minimizes database queries and unnecessary authorization checks of the loaded records. It also avoids situations, such as short pages, which can expose the presence of confidential resources.
See authorization_spec.rb
for examples of all the authorization schemes discussed here.