React Native CSRF Error

[luco]

Hey, I'm trying to get to work with React Native 0.68.1, wrapping the file with:

const avatar = new ReactNativeFile({
    uri: file.path,
    name: file.filename,
    type: file.mime,
});

And getting this error:
networkError ServerParseError: Unexpected token T in JSON at position 0.

Tried using apollo-upload-client on 17.0.0 and 16.0.0. The mutation doesn't work only when I include a Upload in the variables.

The upload works via Postman.

[jaydenseric]

It would be interesting to see what the rest of the message starting with T is, where the JSON is expected. Are you able to figure out what it is?

[luco]

@jaydenseric In fact no. Tried many ways but no luck. I think is the There was an error... message. I'm still trying to figure out what's happening.

One thing I noticed is that if I disable the csrfPrevention on the server it doesn't happens, but the upload doesn't works.

[jaydenseric]

Note that React Native network inspector tooling has had bugs in the past where it disrupts multipart requests. Try doing the same things but with all your React Native related inspectors closed.

[luco]

I'm not using any inspector. Just trying to use as I always do. It always worked like a charm, so I'm not sure why is not working this time.

[jaydenseric]

For this issue to stay open, we need some specific minimal reproduction steps, and ideally an identified bug in apollo-upload-client code. Otherwise it's unactionable; we don't have the ability to debug the peculiarities of your project.

Note that even if you add minimal reproduction steps, I don't have a React Native environment on my end to investigate it with. In the future (when the extract-files dependency is updated, see https://github.com/jaydenseric/extract-files/releases/tag/v12.0.0) we will be removing the ReactNativeFile class and explicit support for React Native. At that time it will be up to React Native to support their users and their need for standard File and Blob globals. IIRC they have made progress on that.

[luco]

@jaydenseric Right, I was able to get the full message.

It has something to do with the csrfPrevention as I presumed. Thoughts?

[jaydenseric]

What is probably happening, is there is some kind of server error, and the default server error response doesn't include the CORS headers you normally set when everything is working in a normal response. I suggest making sure server error responses are sent with the right CORS headers, and then investigating whatever the server error is.

[luco]

Shouldn't apollo-upload-client set a x-apollo-operation-name header?

Making tests on Postman I have seen that if I remove this header it gives me the same error as I'm getting on RN.

[luco]

@jaydenseric Setting the x-apollo-operation-name did fix the error. Should I create a PR?

[jaydenseric]

If you are using Apollo Server you can set up whatever headers it requires via the createUploadLink options options.fetchOptions.headers or options.headers.

apollo-upload-client can be used with any GraphQL servers, not just Apollo Server, and it also doesn't make assumptions about CORS policies and things. So I hesitate to add Apollo Specific headers by default. It's on my backlog to figure out best practices moving forward regarding jaydenseric/graphql-multipart-request-spec#64 (it's a complicated topic I need to fully understand before forcing or recommending any approaches to millions of people).

[luco]

Yeah but since we need the operationName on the header and createUploadLink doesn't allow to access it.

[jaydenseric]

You can create a custom Apollo Link that reads the operation and sets any headers based on that, and use that before the terminating upload link.

https://www.apollographql.com/docs/react/api/link/introduction/#creating-a-custom-link

[luco]

For those who seek this information:

import {ApolloLink} from "@apollo/client";

const CustomLink = new ApolloLink((operation, forward) => {
  operation.setContext({
    ...operation.getContext(),
    headers: {
      ...operation.getContext().headers,
      'x-apollo-operation-name': operation.operationName,
    }
  });
  return forward(operation);
});