State of CORS on IIIF Image API image resources?

[Robert Casties]

Hello,

in my experiments with my first autogenerated IIIF Presentation
manifests I just ran into problems with CORS headers on image resources.

The digilib default (as per the current spec) sets CORS ACAO=* only on
info resources.

Mirador (http://projectmirador.org/) runs fine with this setup.

Diva.js (https://ddmal.github.io/diva.js/) fails with CORS errors on the
image requests (though the requests are not marked as XHR).

Diva.js works when I configure CORS headers on all requests.

Should I change digilib to make CORS on everything the default?

Should the spec change? What is the current wisdom in this issue?

Thanks
Robert

--
Dr. Robert Casties -- Information Technology Group
Max Planck Institute for the History of Science
Boltzmannstr. 22, D-14195 Berlin
Tel: +49/30/22667-342

[Andrew Hankinson]

Hi Robert,

We set the image crossorigin to 'anonymous' for all image requests in Diva.js. They're not XHR because we load the images in with an <img /> tag which then gets painted to the canvas.

If you need different settings please let me know.

Cheers,
-Andrew

> --
> -- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Robert Casties]

Hi Andrew,

On 29.05.17 14:29, Andrew Hankinson wrote:
> We set the image crossorigin to 'anonymous' for all image requests in Diva.js. They're not XHR because we load the images in with an <img /> tag which then gets painted to the canvas.

I just read up on CORS relating to images and canvas:

https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image

And it seems that by painting the image on the canvas it effectively
becomes an XHR request which somehow makes sense.

> If you need different settings please let me know.

I don't think that any image-crossorigin settings would help me. Could I
set the client so that it does not require a CORS header?

How have you set up your IIIF image server? Do you supply CORS on all
image requests? Or do you just run you scripts on the same server?

Am I the only one that has this problem?

Thanks
Robert

[Andrew Hankinson]

> On 29 May 2017, at 14:38, Robert Casties <cas...@mpiwg-berlin.mpg.de> wrote:
>
> Hi Andrew,
>
> On 29.05.17 14:29, Andrew Hankinson wrote:
>> We set the image crossorigin to 'anonymous' for all image requests in Diva.js. They're not XHR because we load the images in with an <img /> tag which then gets painted to the canvas.
>
> I just read up on CORS relating to images and canvas:
>
> https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image
>
> And it seems that by painting the image on the canvas it effectively
> becomes an XHR request which somehow makes sense.

A CORS request with crossorigin set to 'anonymous' means that the image that is loaded behaves as though it were served from the same origin as the JavaScript that is trying to load it. This is, of course, dependent on the server also having the CORS accept header set to allow "*".

In Diva an image for individual tiles is loaded here:
https://github.com/DDMAL/diva.js/blob/master/source/js/image-request-handler.js#L24-L28

This is not the same as an XMLHTTPRequest -- that is, `X-Requested-With` isn't set to "XMLHTTPRequest" for these requests. Instead, what we're doing here is effectively creating an 'img' tag, but rendering the contents of that tag to the canvas instead of the DOM.

If we were to try and do that with image content from a different domain, the browser would complain about a tainted canvas and refuse to load the image.

>
>> If you need different settings please let me know.
>
> I don't think that any image-crossorigin settings would help me. Could I
> set the client so that it does not require a CORS header?

CORS security is baked into the browser. My understanding is that you cannot load images across origins unless you have both the image set to 'anonymous' and the server providing "Access-Control-Allow-Origin *" on the image resources, since the browser will treat this as an effort to taint the canvas and fail to work.

>
> How have you set up your IIIF image server? Do you supply CORS on all
> image requests? Or do you just run you scripts on the same server?

For examples like this one:

http://ddmal.github.io/diva.js/try/demo/iiif-external.html

Looking at the server response from the BnF for Latin 12044 example, you can see that they serve the images with "Access-Control-Allow-Origin *" for their image results.

The same is true of the "KB 35 4°" example from e-Codices.

For our own servers we generally set the Access-Control-Allow-Origin header to * if we know that the images will be used in a cross-origin context (Which is what most IIIF uses are...).

>
> Am I the only one that has this problem?

CORS is not the friendliest spec to understand. I think it's as confusing to everyone else as it is to me too. :)

-A

[Robert Casties]

On 29.05.17 16:41, Andrew Hankinson wrote:
>> https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image
[...]

> In Diva an image for individual tiles is loaded here:
> https://github.com/DDMAL/diva.js/blob/master/source/js/image-request-handler.js#L24-L28
>
> This is not the same as an XMLHTTPRequest -- that is, `X-Requested-With` isn't set to "XMLHTTPRequest" for these requests. Instead, what we're doing here is effectively creating an 'img' tag, but rendering the contents of that tag to the canvas instead of the DOM.

That is correct. I meant that the request starts to be subject to CORS
which a simple img-request isn't.

> If we were to try and do that with image content from a different domain, the browser would complain about a tainted canvas and refuse to load the image.

The MDN reference above says "Once a canvas has been tainted, you can no
longer pull data back out of the canvas. For example, you can no longer
use the canvas toBlob(), toDataURL(), or getImageData() methods; doing
so will throw a security error." Do you use any of these methods on the
canvas?

I commented out the image.crossOrigin = "anonymous" and the images start
to work for me in diva.js without CORS on the image requests. I haven't
done any extensive testing though.

There seems to be already be diva issue #367 that makes crossOrigin an
option: <https://github.com/DDMAL/diva.js/issues/367>. Maybe it should
be the default if it has no ill consequences.

>> I don't think that any image-crossorigin settings would help me. Could I
>> set the client so that it does not require a CORS header?
>
> CORS security is baked into the browser. My understanding is that you cannot load images across origins unless you have both the image set to 'anonymous' and the server providing "Access-Control-Allow-Origin *" on the image resources, since the browser will treat this as an effort to taint the canvas and fail to work.

It seems that you can use images across origins but you have to live
with a tainted canvas ;-)

>> How have you set up your IIIF image server? Do you supply CORS on all
>> image requests? Or do you just run you scripts on the same server?
>
> For examples like this one:
>
> http://ddmal.github.io/diva.js/try/demo/iiif-external.html
>
> Looking at the server response from the BnF for Latin 12044 example, you can see that they serve the images with "Access-Control-Allow-Origin *" for their image results.

If ACAO=* needs to be the default for image request then this should be
in the next revision of the IIIF Image API spec (and in the notes for
the current spec).

>> Am I the only one that has this problem?
>
> CORS is not the friendliest spec to understand. I think it's as confusing to everyone else as it is to me too. :)

That is true %-) On top of being hard to read it also sprouts new
extensions over time like the img-request suddenly being subject to CORS
when its used in a canvas which I had not encountered before.

Cheers

Robert


--
Dr. Robert Casties -- Information Technology Group
Max Planck Institute for the History of Science
Boltzmannstr. 22, D-14195 Berlin

Tel: +49/30/22667-342 Fax: -299