Shrine: Uppy incompatibility due to OPTIONS request

[cilim]

Hi @janko 👋

Before writing the issue details, I wanna say thank you for this amazing gem! Helps out a bunch every day!

And now:

Brief Description

I believe that uppy isn't compatible with Shrine with versions 1.3.0 and newer.

Expected behavior

Direct upload to S3 with uppy & Shrine.

Actual behavior

Uppy sends a OPTIONS preflight request to _/s3/params_ and the response is Method Not Allowed (405)

Simplest self-contained example code to demonstrate issue

const fileInput = this.fileTarget # file input from HTML
fileInput.style.display = 'none'

const uppy = Uppy({
  autoProceed: false,
  restrictions: {
    maxFileSize: 10737418240,
    maxNumberOfFiles: 1,
    allowedFileTypes: ['video/*']
  }
})

uppy.use(Dashboard, {
  inline: true,
  target: '.drag-drop-area',
  showProgressDetails: true,
  browserBackButtonClose: true
})

uppy.use(AwsS3, {
  companionUrl: '/'
})

uppy.on('upload-success', function(file, response) {
  var uploadedFileData = JSON.stringify({
    id: file.meta['key'].match(/^cache\/(.+)/)[1],
    storage: 'cache',
    metadata: {
      size:      file.size,
      filename:  file.name,
      mime_type: file.type
    }
  })

  var hiddenInput = fileInput.parentNode.querySelector('.upload-hidden')
  hiddenInput.value = uploadedFileData
})

The exact same code passes when using uppy < 1.3.0

System configuration

Ruby version: 2.6.5

Shrine version: 3.0.1

[janko]

Before writing the issue details, I wanna say thank you for this amazing gem! Helps out a bunch every day!

That's great to hear! ❤️

Uppy sends a OPTIONS preflight request to /s3/params and the response is Method Not Allowed (405)

Yes, this is a known issue, but I haven't opened a ticket for it yet, so thanks for doing that 😃

Even though the OPTIONS request is failing, the direct upload itself should still succeed, at least that's how it is for me locally on Chrome/Firefox. So, it's more of an annoying failed request in the network inspector tab than an incompatibility.

That being said, we definitely plan to fix this. We need the presign_endpoint to implement an OPTIONS route with some basic CORS response (we can see some examples in Uppy Companion and tus-ruby-server). It seems from RequestClient.js that Uppy only looks at the Access-Control-Allow-Headers response header.

[janko]

@cilim Let me know if you would perhaps like to give it a try 😉 (I think it shouldn't be difficult, though having some Rack knowledge would definitely help).

Otherwise we'll probably find time for it sometime next week.

[jrochkind]

Any chance that such a fix could be backported to shrine 2.x too?

[mike1o1]

I ended up fixing this by overwriting the getUploadParameters method on Uppy to make a get request directly. Here is the code snippet if that helps anybody else:

  .use(AwsS3, {
    limit: 5,
    getUploadParameters(file) {
      let url = `/s3/params?filename=${file.name}&type=${file.type}`;
      return fetch(url, {
        method: 'get',
        headers: {
          accept: 'application/json',
          'content-type': 'application/json'
        }
      })
        .then((response) => {
          return response.json();
        })
        .then((data) => {
          return {
            method: data.method,
            url: data.url,
            fields: data.fields
          };
        });
    }
  })

[janko]

Any chance that such a fix could be backported to shrine 2.x too?

There should be no need, as the upload itself should still be working. Uppy is the one making the OPTIONS request to fetch information from the Uppy Companion (which in our case is presign_enpdoint predending to be Uppy Companion), so it's not the browser that's making the request (browsers only make preflight requests for non-GET verbs), and Uppy still seems to proceed with the upload when the OPTIONS verb is not implemented.

[janko]

Since this doesn't seem to be causing any problems at the moment, I will leave this as an opportunity for others to send a PR for the OPTIONS route.

[cilim]

@janko I'm up for helping out and implementing an OPTIONS route on the presign_endpoint, but I won't make it this week, since the holidays are around the block and all clients have deadlines 🙈

[subvertallchris]

There is a scenario where this causes a problem: if you use headers to authenticate, the rejected OPTIONS request prevents Uppy from being able to read response headers, which makes requests fail. A happy OPTIONS response is necessary for this to work correctly. I'm currently working around it by patching Uppy to ignore the preflight response but this isn't workable forever, it would be best for Shrine to implement this.

[janko]

Shrine master branch adds an OPTIONS endpoint which should resolve the issue. There are a few more things that need to be done before the release, though, but it should be stable.

[subvertallchris]

Very nice! It's not so urgent that I'll upgrade immediately but this is great to know, I'll keep my eyes open for that new version. Thanks for your work!