samvera-labs / openseadragon-react-viewer

A React wrapper around the OpenSeadragon viewer which extends viewer functionality.
https://samvera-labs.github.io/openseadragon-react-viewer/
27 stars 7 forks source link

Access to XMLHttpRequest at 'https://ids.lib.harvard.edu/ids/iiif/5981094' from origin 'http://localhost:3000' has been blocked by CORS policy #48

Open ranamdissa opened 4 years ago

ranamdissa commented 4 years ago

I am using this viewer library of openseadragon, and I am getting the title's error. I 'm not sure how to solve this issue. It's happening on my local server as well as our test servers. Doesn't anybody know how this can be solved?

Many thanks R

adamjarling commented 4 years ago

Hi @ranamdissa This looks like an access configuration issue on the server serving your IIIF manifest files. Do you have access to making access configurations on the server?

fnandoz21 commented 4 years ago

Hi I am also having this issue as well, is it simply that I may not have access to display these files in the viewer?

fnandoz21 commented 4 years ago

Is there a sample manifest URL that would provide real output that I can try to use? I have tried finding some from various sources and keep running into a similar error.

This is the output in the console: "Access to XMLHttpRequest at 'https://media.nga.gov/iiif/public/objects/1/0/6/3/8/2/106382-primary-0-nativeres.ptif' from origin 'http://localhost:3001' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource."

This is from when I try to use https://media.nga.gov/public/manifests/nga_highlights.json as the manifestUrl in the code. It's strange because it allows me to download the photo and it's perfect there, it just comes up as all black in the viewer.

adamjarling commented 4 years ago

@fnandoz21 Yea, I'm getting the same results running the Viewer in it's local dev environment, and using your manifest url in the test display at: src/components/OpenSeadragonViewer/Readme.md

image

I'm not a CORS expert, but believe it's because your application is making the network request (which is getting blocked), as opposed to just viewing the image url in a browser (which works, but is a different way of making the network request).

If your application was hosted on the same domain (https://media.nga.gov) or a subdomain, it'd work.

This Stack Overflow post has some more info:

https://stackoverflow.com/questions/20035101/why-does-my-javascript-code-receive-a-no-access-control-allow-origin-header-i

Do you think displaying a friendlier error message giving details on why the item is not being displayed, would be helpful?

ryantomaselli commented 3 years ago

Just adding this in case others encounter.

I needed to add not only the Access-Control-Allow-Origin for my domain but also Access-Control-Allow-Credentials to the manifest URL end point response header.

Like so:

          'Access-Control-Allow-Origin': 'https://my.react-app.com:3000',
          'Access-Control-Allow-Credentials': true
adamjarling commented 3 years ago

Thanks for the addition @ryantomaselli Yes, this type of configuration should be supported. I'll try to get some pass through props action happening before too long.

ryantomaselli commented 3 years ago

Thanks @adamjarling! Yes, being able to pass options into the OpenSeadragon instance would be great.

It would be nice to be able to control which buttons in the Toolbar are visible too. I would like to turn off the Download and Navigation buttons.

adamjarling commented 3 years ago

@ryantomaselli Just updated the package to support passing through OSD configuration values, and also customizing which Toolbar controls are displayed. Check out the notes here in the Readme, or the updated docs

ryantomaselli commented 3 years ago

@ryantomaselli Just updated the package to support passing through OSD configuration values, and also customizing which Toolbar controls are displayed. Check out the notes here in the Readme, or the updated docs

Excellent. Thanks Adam! Will check it out

devnoot commented 3 years ago

This was holding me up as well. I discovered that in my instance, I had to create a proxy server to get around the CORS issues.

// This file contains proxy middleware for proxying API requests in gatsby.
const express = require('express');
const {createProxyMiddleware} = require('http-proxy-middleware');

const app = express();
const port = process.env.PROXY_PORT || 3000;

const proxy = createProxyMiddleware({ 
    target: 'https://some.url.to.your.iiif.api.server/iiif/2', 
    changeOrigin: true,
    logLevel: 'debug',
    pathRewrite: {
        '^/api': ''
    }
}) 

app.use('/', proxy);

app.listen(port, () => {
    console.log(`Proxying requests on port ${port}`);
});

Then, on the client-side of things, make your API requests to the proxy server instead.

You can also test if the server you're trying to access supports cors through this site: https://www.test-cors.org/