IIIF sources without CORS headers won't display

[mberkowski]

https://geo.btaa.org/catalog/ark-85335-m5xp6wf8x

This is possibly due to tightening security in browser defaults. IIIF sources from MSU lack an Access-Control-Allow-Origin header and are rejected by the browser. Most likely, this has to be fixed upstream on the server d.lib.msu.edu

Access to XMLHttpRequest at 'https://d.lib.msu.edu/sites/all/libraries/openseadragon/images/iiif-server/iiif/2/maps:493/info.json' from origin 'https://geo.btaa.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

[karenmajewicz]

I will check with MSU on this. We have seen this issue before with ArcGIS Servers, but not with IIIF.

Although, many of the MSU items from the same system (Islandora) do work, which seems odd. To compare:

Working link:

https://geo.btaa.org/catalog/ark-85335-m5gq6sd72 (https://d.lib.msu.edu/sites/all/libraries/openseadragon/images/iiif-server/iiif/2/maps:585/info.json)

Blocked:

https://geo.btaa.org/catalog/ark-85335-m5xp6wf8x (https://d.lib.msu.edu/sites/all/libraries/openseadragon/images/iiif-server/iiif/2/maps:493/info.json)

Related documentation: https://github.com/Islandora/islandora_openseadragon/blob/9d4bf30b96bb0c0117d09cae082867ae80f6c49d/README.md#reverse-proxy

[mberkowski]

It actually seems sporadic as to whether they load. Of your two above, both initially loaded for me then failed on a reload.

Here are response headers when it loaded:

access-control-allow-origin: *
cache-control: max-age=2592000, public, no-transform
content-encoding: gzip
content-type: application/json;charset=utf-8
date: Fri, 25 Mar 2022 16:35:30 GMT
server: Jetty(9.4.34.v20201102)
set-cookie: nlbi_2402946=redacted; path=/
set-cookie: visid_incap_2402946=redacted+; expires=Sat, 25 Mar 2023 09:36:10 GMT; HttpOnly; path=/
set-cookie: incap_ses_1483_2402946=redacted==; path=/
vary: Accept,Accept-Charset,Accept-Encoding,Accept-Language,Origin
x-cdn: Imperva
x-iinfo: 16-251228503-251226738 2NYN RT(1648226130104 0) q(0 0 0 -1) r(0 0)
x-powered-by: Cantaloupe/5.0.3

And headers when it failed:

cache-control: no-cache, no-store
content-length: 122
content-type: text/html
date: Fri, 25 Mar 2022 16:35:40 GMT
location: https://d.lib.msu.edu/iiif-server/iiif/2/https%3A%2F%2Fd.lib.msu.edu%2Fislandora%2Fobject%2Fmaps:493%2Fdatastream%2FJPG%2Fview/info.json
server: Apache/2.4.29 (Ubuntu)
set-cookie: visid_incap_2402946=redacted; expires=Sat, 25 Mar 2023 08:53:23 GMT; HttpOnly; path=/
set-cookie: incap_ses_1442_2402946=redacted==; path=/
set-cookie: nlbi_2402946=redacted; path=/
set-cookie: visid_incap_2402946=redacted; expires=Sat, 25 Mar 2023 09:36:10 GMT; HttpOnly; path=/
set-cookie: incap_ses_1483_2402946=redacted==; path=/
x-cdn: Imperva
x-iinfo: 10-169577939-0 2NNN RT(1648226140131 16) q(0 0 0 -1) r(0 -1)
x-iinfo: 16-251230662-251223969 2NNN RT(1648226140391 0) q(0 0 0 -1) r(1 1) U11

Perhaps MSU has a load balancer where some requests are hitting a source that correctly sets CORS headers while others do not. I notice x-cdn: Imperva - the CDN could be at fault.

[karenmajewicz]

This is helpful - I will pass it along.

[Weessies]

Thank you for bringing this to our attention. Nathan says, "We've updated the repository (both current and the new Sandhill) to ensure a permissive ‘Access-Control-Allow-Origin’ header is set. The repository is behind a CDN which can sometimes take a while to update. I'll check tomorrow to see if the it has picked up the new header. If not, I'll reach out to our CDN contacts to get the issue solved."

[mberkowski]

I tested the morning of April 11 and am still seeing missing ACAO headers on a portion of requests.

[Weessies]

Nathan says: I apologize for not providing and update before. The fix on our side was not reflected through the campus CDN the next day. I then placed in a ticket for them to look into it (req 1169194 on 4/1/2022). Unfortunately, campus IT is extremely short staffed and responses to tickets can take quite some time. If you feel it's an urgent matter to get fixed, I could reach out to the team directly and see if they could expedite addressing the issue.

[mberkowski]

Not urgent! I had just set a reminder to look back on this after a week or so.

[karenmajewicz]

The example https://geo.btaa.org/catalog/ark-85335-m5xp6wf8x seems to be working fine. Is this still an issue?

[karenmajewicz]

I am now seeing this issue for all of the University of Maryland maps https://geo.btaa.org/?f%5Bgbl_resourceClass_sm%5D%5B%5D=Maps&f%5Bschema_provider_s%5D%5B%5D=University+of+Maryland

[mberkowski]

The IIIF service at https://iiif.lib.umd.edu is not setting any Access-Control-Allow-Origin headers. They will need to adjust any setting that recently was changed to restore any CORS headers they were setting before. It's pretty essential for a service like IIIF, meant to be consumed by many clients

For whatever it's worth, server CORS support is a SHOULD rather than a MUST in the IIIF spec, but it isn't possible for external sites to use the service without the headers. https://iiif.io/api/image/3.0/#71-cors

[karenmajewicz]

Thanks - I contacted our UMD team member with this info.

[karenmajewicz]

• [x] UMD fixed their server settings and the Maryland maps now display.