CORS error connecting to api.nft.storage through the browser

[dysbulic]

When I attempt to upload a file using the web UI, I am getting a CORS error and the file isn't added:

Access to fetch at 'https://api.nft.storage/upload' from origin 'https://nft.storage' has been
blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the
requested resource. If an opaque response serves your needs, set the request's mode
to 'no-cors' to fetch the resource with CORS disabled.

POST https://api.nft.storage/upload net::ERR_FAILED

[dysbulic]

The error is misleading. Apparently, I was getting it b/c I was trying to upload a SVG. It works with a PNG.

[hugomrdias]

@dysbulic any chance we can get access to that svg to debug this ?

[dysbulic]

any chance we can get access to that svg to debug this?

Sure. I was disappointed when it didn't work. I tried a couple different ones, and thought it was the script tag, but this one also fails.

[hugomrdias]

Cool thank you im able to reproduce, i will look into it.

[dysbulic]

I didn't realize there was a script tag in the image I referenced. It didn't do anything, but it was there.

Once I removed it, the file uploaded.

There are valid reasons for disallowing images with scripts though honestly the img tag doesn't execute them and that's what people will be using to display NFTs.

[hugomrdias]

Well its actually a security issue, that svg has a inline script tag to inject the animation library which in this case is probably
harmless but for bad actors could be bad.
To be able to upload this you need to use the others options that we have that use FormData and not Blob.
For the js library this would be:

• client.store
• client.storeDirectory

For the HTTP API this would be (https://staging.nft.storage/api-docs/):

• /upload with the body being a multipart/form-data
• /store which is new and not documented yet

[hugomrdias]

what we could improve is to return a better error in this situation, i will look into that

[mikeal]

Can we construct/document an HTML form such that it posts to the form-data API. If the file is taken directly from the file input field it can’t be tampered with by client script and CORS shouldn’t be an issue.

[yusefnapora]

@mikeal can we attach an auth header to the form's POST request without javascript though?

[yusefnapora]

About my last comment... maybe we could generate an id token on the client and put it in a hidden form field. Then it can be POST'ed directly, so our script never needs to see the File data. The backend would need to be updated to check for the DID token field though.

[yusefnapora]

Just updating to mention that the forever fix for this seems to be to always send CARs to the API, which is being tracked in #220.

However, @dysbulic, I noticed in the client code that the storeCar method already accepts a Blob argument and will "promote" it into a CAR file, which should avoid the issue.

So if you're currently using storeBlob, you should be able to just switch to storeCar and just pass the same blob in; storeCar will convert it for you.

If you're not using storeBlob, you could make a CAR yourself and store it with storeCar. There's some docs on working with CARs here: https://docs.web3.storage/how-tos/work-with-car-files/

[yusefnapora]

@dysbulic please disregard my comment above about passing in your blob unchanged to storeCar! A closer reading shows that it only works if you're passing in a Blob of CAR-formatted data. Sorry about the misdirect :)

[Gozala]

@dysbulic I was trying to write up an example to demonstrate how this limitation could be overcome using client.storeDirectory API, however in the process I've discovered that it works now here is the link to an
https://observablehq.com/d/06fdb0bbee195e58 demonstrating it.

Have you by a chance updated a file under the URL you've shared ? If so could you please share the file that causes this ?

[Gozala]

Turns out svg linked does not contain script tag that which is probably why example above worked. That said we have changed cloudfare config to no longer block requests that contain script's in them so this issue is fixed now.