Closed dcousens closed 7 months ago
This pull request is automatically built and testable in CodeSandbox.
To see build info of the built libraries, click here or the icon next to each commit SHA.
Latest deployment of this branch, based on commit 614b645283fae7edb6cdb46a471e767df9bac171:
Sandbox | Source |
---|---|
@keystone-6/sandbox | Configuration |
This pull request adds a warning to the field access control documentation to clarify that field access control rules do not apply when using
context.db.*
for database operations.Keystone has a number of access control capabilities, including field-level access control for
read
,create
, andupdate
field operations. The behavior ofcontext.db.*
not adhering to{field}.access.read
is likely not apparent to many developers, especially when many developers often prefercontext.db.*
for the refined Typescript support.Field access control has been designed to co-operate with GraphQL resolvers, ensuring that any data returned by your GraphQL API respects the field access control rules for a set of particular output types. We refer to this in the documentation as
Since
context.db.*
operations don't pass through the GraphQL layer, and interact directly with Prisma, applyingread
field-level access controls isn't straight forward. You especially need to consider that many fields don't have reasonable behavior without passing through GraphQL output resolvers first, such asvirtual
fields.That said, developers are incentivized to use
context.db
for the superior Typescript integration at this stage of Keystone 6's development, therefore we need to capture these limitations more readily in the documentation; and we should potentially review this behaviour in upcoming major versions.This pull request adds some warnings that explicitly state that
access.read
field access control rules are not applied tocontext.db
operations. This should help prevent confusion until we bridge the gap betweencontext.query
and Typescript.