steps to reproduce:
- create collection
- create key without any access to that collection
- execute mutation graphql update
expected
permissions exception / error
actual response:
{“result”:null}*
steps to reproduce:
expected
permissions exception / error
actual response:
{“result”:null}*
When you don’t have permission to read a document, it appears to GraphQL as if you are requesting to update a document that doesn’t exist. This is not a bug, but rather what we expect from validating your query before trying to mutate something.
Here is me duplicating the behavior by trying to update a Document in the demo database with an empty Role. In the demo database, I know that Ref(Collection("products"), "201")
exists. The result is updateProduct: null
If I switch back to an admin role, and change the ID to one that I know doesn’t exist, I get the same result: updateProduct: null
Adding read permissions to the Role, the query finds that the Document does exist. Since it exists, the queries tries to apply the update, and then you get a “permission denied” error.
For the example that I shared, the updateProduct
mutation is translated into FQL similar to this:
Let(
{
ref: Ref(Collection("products"), "201"),
updated: If(
Exists(Var("ref")), // `Exists` returns false if you don't have READ permissions
Update(Var("ref"), /* ... */) // Update only if the document exists. Will cause an error if you don't have WRITE permissions.
null // returns `null` if doc does not exist to caller
)
},
{
updateProduct: If(
IsNull(Var("updated")),
null,
{
/* selected fields */
}
)
}
)
If we call Exists
from the shell, we can test how it works with different permissions. Exists
returns the true
only if it exists and you have permission to read the Document.
sounds good, the explanation makes sense, thank you for the prompt and detailed response!
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.