GraphQL - Roles defined without read action returns error
See original GitHub issueWhen a role is defined without read
action, mutations performed in the context of that role, returns an error response. However, at the database level, the mutation(update,insert, etc. action) succeeds.
Repro steps:
- In the config file available in the main branch, remove the
read
action for theAnonymous
role - Execute the following mutation request in the context of
Anonymous
role
mutation {
updatebook(id: 1, item: {title: "Harry Potter and the Goblet of Fire"}){
id
title
}
}
Config file:
{
"$schema": "https://github.com/Azure/data-api-builder/releases/download/vmajor.minor.patch/dab.draft.schema.json",
"data-source": {
"database-type": "mssql",
"connection-string": "...",
"options": {
"set-session-context": false
}
},
"runtime": {
"rest": {
"enabled": true,
"path": "/api"
},
"graphql": {
"enabled": true,
"path": "/graphql",
"allow-introspection": true
},
"host": {
"cors": {
"origins": [],
"allow-credentials": false
},
"authentication": {
"provider": "StaticWebApps"
},
"mode": "development"
}
},
"entities": {
"Book": {
"source": {
"object": "books",
"type": "table"
},
"graphql": {
"enabled": true,
"type": {
"singular": "book",
"plural": "books"
}
},
"rest": {
"enabled": true
},
"permissions": [
{
"role": "anonymous",
"actions": [
{
"action": "create"
},
{
"action": "update"
},
{
"action": "delete"
}
]
},
{
"role": "authenticated",
"actions": [
{
"action": "create"
},
{
"action": "read"
},
{
"action": "update"
},
{
"action": "delete"
}
]
}
]
}
}
}
The mutation was executed in the context of Anonymous
role.
In these requests, a) The database operation goes through when the corresponding permission is setup (create action for a create mutation, update action for update mutation, etc.) b) The lack of read action causes the authz error to be thrown.
Note We observe this behavior only in SQL DB types. With cosmos, even when read permission is not setup, valid response (response with values for fields requested in the selection set) is returned.
### Tasks
- [ ] https://github.com/Azure/data-api-builder/issues/1603
Issue Analytics
- State:
- Created 5 months ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Error handling - Apollo GraphQL Docs
Whenever Apollo Server encounters errors while processing a GraphQL operation, its response to the client includes an errors array containing each error ......
Read more >Full Stack Error Handling with GraphQL and Apollo
If networkError is present in your response, it means your entire query was rejected, and therefore no data was returned. For example, the ......
Read more >graphql error: You don't have permission to access this
This works for authenticated users. However, there is currently no way to access the GraphQL API as the public role (neither the GraphiQL ......
Read more >Error Handling in GraphQL
The GraphQL specification defines how errors should be handled and returned in response to client requests. When a GraphQL server encounters ...
Read more >A complete guide to permissions in a GraphQL API
Learn how to implement permissions in GraphQL using three different methods: directives, middleware resolvers, and the GraphQL shield ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
We’ll need to see if HotChocolate supports grouping the update/read-result to be protected by the runtime config defined permissions for the update operation, out of the box.
Since the selection set is a read operation, HotChocolate would enforce the authorization rules we set on the Object Type definition in the GraphQL schema for read operations.
From a GraphQL standpoint, the behaviour of SQL backends is correct while Cosmos is incorrect, based on the auth config provided the
anonymous
user is allows to write but it can’t read data back out, and a mutation is a two-part process, mutate the database then read the database.In a custom GraphQL server where you aren’t doing one-to-one data mapping a mutation doesn’t have to represent a data construct in our backend, it’s indicating a concept that you’re performing. Using a trivia game example, you could have a mutation
createGame
which doesn’t take any parameters but it uses that information to go and create a record in the database with some initial game state, and then there’s a selection set you can pick fields from whatever data structure that is deemed right at that point. This will be implemented as “modify database” and then “query database”, and if you don’t have read permissions you’d get the above outlined error.So is it more of an education piece, people aren’t aware that they are really performing two database operations
CREATE
(orUPDATE
orDELETE
) followed by aSELECT
? And if I am denied permissions forSELECT
then it’d make sense I get an error, unless I try to just get back__typename
(since that doesn’t hit the database).