Graphql-shield doesn't work with multipart requests (Graphql-yoga Upload)
See original GitHub issueBug report
- I have checked other issues to make sure this is not a duplicate.
Describe the bug
I found unexpected behavior of graphql-shield while using it for mutations, that accept file of type Upload as parameter. I use it with apollo client, which transforms requests into multipart, if they have some file included.
To Reproduce
- This is my GraphQL Schema.
scalar Upload
type Mutation {
createUser(
name: String!
avatar: Upload
): User!
}
type Query {
users: [User!]!
}
type User {
id: ID!
name: String!
avatarUrl: String
}
- This is the invoked query
createUser({
variables: {
name: "John Doe",
avatar: new ReactNativeFile({
uri: values.image,
type: 'image/*',
name: `IMG_${new Date().toISOString()}`,
}),
},
})
- I use these permissions
const allow = rule()(async (parent, args, ctx: Context, info) => {
console.log("HERE")
return true
})
const permissions = shield({
Mutation: {
createUser: allow,
},
})
- This is the error I see
Object {
"data": null,
"errors": Array [
Object {
"locations": Array [
Object {
"column": 3,
"line": 2,
},
],
"message": "Not Authorised!",
"path": Array [
"createUser",
],
"stack": "Error: Not Authorised!
at normalizeOptions (/banshee/packages/backend/node_modules/graphql-shield/src/shield.ts:32:32)
at Object.shield (/banshee/packages/backend/node_modules/graphql-shield/src/shield.ts:51:29)
at Object.<anonymous> (/banshee/packages/backend/src/permissions.ts:245:28)
at Module._compile (internal/modules/cjs/loader.js:774:30)
at Module.m._compile (/banshee/packages/backend/node_modules/ts-node/src/index.ts:473:23)
at Module._extensions..js (internal/modules/cjs/loader.js:785:10)
at Object.require.extensions.<computed> [as .ts] (/banshee/packages/backend/node_modules/ts-node/src/index.ts:476:12)
at Module.load (internal/modules/cjs/loader.js:641:32)
at Function.Module._load (internal/modules/cjs/loader.js:556:12)
at Module.require (internal/modules/cjs/loader.js:681:19)",
},
],
}
Expected behavior
- “HERE” displayed in console.
- User created.
Actual behaviour
- “HERE” is not displayed in console.
- User not created, but permissions should not deny this mutation
Additional context
Also, I can successfully create user without avatar.
Versions: backend: “graphql-yoga”: “1.18.0” “graphql-shield”: “^5.7.1” frontend: “apollo-upload-client”: “10.0.0”, “graphql”: “14.2.1”, “react-native”: “https://github.com/expo/react-native/archive/sdk-33.0.0.tar.gz”,
Issue Analytics
- State:
- Created 4 years ago
- Reactions:5
- Comments:17 (4 by maintainers)
Top Results From Across the Web
File Uploads – GraphQL Yoga
GraphQL Yoga supports the GraphQL Multipart Request Specification, allowing you to upload files and consume the binary data inside GraphQL ...
Read more >File upload is not working · Issue #615 · dotansimha/graphql ...
Hello, I would like to notice that file upload is not working anymore. In our service we're using docker and typescript (more info...
Read more >GraphQL Code Libraries, Tools and Services
A JavaScript library for application development using cloud services, which supports GraphQL backend and React components for working with GraphQL data.
Read more >File Upload (multipart) graphql requests does not work - Support
I got this error one i post a multipart request to my graphql api through tyk gateway status_code: 400 { “error”: “invalid character...
Read more >Authorization with GraphQL Shield - YouTube
In this video we'll explore some of the logic and input rules that come with GraphQL Shield to protect against unwanted requests.
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
@maticzav I’ve created an PR which fixes the problem for me. Can you have a look?
Adding
{ cache: "contextual" }
to the related rules is fixing the problem but it should work by default.