Hardcoded crossOriginPolicy:Anonymous breaks manifests whose image host lacks CORS headers

[tacman]

Summary

viewer-element.ts hardcodes OpenSeadragon's crossOriginPolicy: "Anonymous" and loadTilesWithAjax: true with no way for a host page to override it. Any manifest whose image server doesn't send Access-Control-Allow-Origin (very common — many museum/library CDNs don't) fails to render at all, even though the same image loads fine with plain <img>-style loading (no CORS needed for basic display).

https://github.com/DDMAL/diva.js/blob/v7.3.1/src/viewer-element.ts#L133

const options = {
    element : this.container,
    ...
    crossOriginPolicy : "Anonymous",
    loadTilesWithAjax : true,
    ajaxWithCredentials : false,
    ...
} as any;
this.viewer = OpenSeadragon(options);

Reproduction

Manifest: https://openaccess-cdn.clevelandart.org/2022.346/2022.346_web.jpg (referenced, no service, plain IIIF v3 Presentation manifest built from Cleveland Museum's Open Access API). The image response has no access-control-allow-origin header at all (verified via curl -I).

Loading this manifest in diva 7.3.1 results in a blank viewport and a flood of console errors:

Access to image at 'https://openaccess-cdn.clevelandart.org/2022.346/2022.346_web.jpg' from origin '...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Confirmed with an isolated test — same OpenSeadragon version, same image URL, only the tile-source options differ:

// diva's hardcoded settings -> fails
OpenSeadragon({ element, crossOriginPolicy: 'Anonymous', loadTilesWithAjax: true, tileSources: [{ type: 'image', url }] })
// => open-failed: "Error loading image at ..."

// without CORS mode -> succeeds
OpenSeadragon({ element, crossOriginPolicy: false, loadTilesWithAjax: false, tileSources: [{ type: 'image', url }] })
// => opens, fullyLoaded: true

Related history

#489 reported the same class of problem against the old (pre-rewrite) codebase, where imageCrossOrigin: null was available as a workaround/setting. The v7 rewrite appears to have dropped that configurability entirely — there's no equivalent option exposed today, so this isn't just a missing default, it's a missing escape hatch.

Secondary issue found while investigating

With the failing manifest above, diva enters what looks like an unbounded retry loop — DevTools network log showed 75,000+ repeated GET requests to the same failing image URL within about a minute, with no backoff or retry cap. Might be worth its own issue, but flagging here since it was found in the same repro.

Suggested fix

Either:

• Expose crossOriginPolicy / loadTilesWithAjax as configurable settings (restoring rough parity with the old imageCrossOrigin option), or
• Default to crossOriginPolicy: false for plain (non-IIIF-Image-API) static image bodies, since canvas pixel-level access isn't needed for basic display — only tile-pyramid/Image-API sources arguably benefit from AJAX-loaded, CORS-mode tiles.

Environment

• diva.js 7.3.1 (npm)
• Chromium (via Playwright), also reproduces in this project's own browser testing

[ahankinson]

I’m currently working on IIIF Auth 2.0 support, which will probably fix this.

But CORS is constantly a problem, and IIIF servers really should implement it.

[tacman]

Agreed, but these aren't IIIF servers, right? They're just plain servers hosting images. We can write a proxy to get around this, but since the previous version had a workaround (the :null setting), we know it's possible.

Glad to hear you're working on IIIF Auth 2.0, thanks!

[ahankinson]

“Plain” servers can still set CORS. I believe GitHub Pages does, for example.

[tacman]

Sure, they can, but I doubt Cleveland Museum of Art, etc. is going to do that. I'll probably end up with some sort of proxy, but it sounds like you're working on a better solution. Thanks.

[ahankinson]

Can you supply your manifest? The URL above where you say it's a manifest is to a jpg file. Thanks!

[ahankinson]

ping @tacman -- could you send along a manifest so I can check this out? Thanks!

[tacman]

I started down that path and found an error in the manifest itself for that particular image. I think I have some code where the imageUrl is actually a manifest file and not an image.

I'll look though -- you recently updated the library, right? I'll download the latest version and see if the error is still there. Thanks.

[ahankinson]

Yes i put out 7.4.1 yesterday. There were some changes to support IIIF Auth 2.0 in 7.4.0, but I don’t think it addressed this one.

Be aware that 7.4 updated styles (for the better I hope) but it will change the look of any site it’s integrated in.

[ahankinson]

I just pushed a fix for this, with caveats. As of v7.4.3 (currently on develop) You can control the CORS behaviour at initialisation time with:

staticImageCorsPolicy: "required" | "fallback" | "none"

required is the default, and will reject static images that are served without CORS headers. This is so that these images can be loaded into the filters, and accelerated in OpenSeadragon with WebGL. It is still recommended to host static images on CORS-enabled servers so that these features are available.

fallback will first try to load the image with CORS and, if that fails, will fall back to static loading. However, setting this will use the slower Canvas / HTML renderer in OSD for all manifests (even CORS-enabled ones) since it is not possible to load non-CORS images in WebGL.

none will load only non-CORS images. This is for installations that only support static image deployments, and do not allow users to mix with CORS-enabled images. This will reduce the number of requests (will not try the fallback check) but will still only use the slower Canvas / HTML renderer.

[ahankinson]

Also, I have added a manifest, using the clevelandart image above that you can access when you run the /testing/testing.html demo in this repo, and a new option that lets you switch between the different CORS modes.