Unable to load manifest for images in deployment but no error message

[Anthony Hashemi]

Hi,

We are able to render pdfs in UV and are now trying to render images with valid IIIF manifests. We are encountering the following console error when we get the Unable to load manifest (we have bundled the JS from the UV dev branch and added it to our webapp repo to get the new console log line).

"Syntax error Compiled template code: // galleryThumbsTemplate/if var v,h=j._html,ret=""+" <input id=\"thumb-checkbox-" +h(data.id)+"\" tabindex=\"-1\" type=\"checkbox\" data-link=\"checked{:multiSelected ? \'checked\' : \'\'}\" class=\"multiSelect\" /> "; return ret; : "Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: <ANONYMISED>". ""

As you can see, it is an issue where the UV source code is using an eval statement and our csp is blocking it. We do not want to allow `unsafe-eval` in our CSP config for the obvious security concerns. Is there an alternative way we can get around this, potentially some other code path via some config? Or is this something that may be fixed soon?

Cheers,
Anthony

[demian...@gmail.com]

Anthony,

I'm not too familiar with the gallery code, but it looks to me like the offending code is not in the UV itself, but in the iiif-gallery-component that it includes. Specifically, it appears to be using some kind of template engine here:

https://github.com/IIIF-Commons/iiif-gallery-component/blob/master/src/index.ts#L180-L195

My strong suspicion is that whatever template engine is being used relies on eval in some fashion. It would take me more time than I currently have available to figure out exactly what template engine is in use (maybe somebody else here already knows), but I think there are several ways to get around the problem. If the template engine is still being maintained, perhaps there is a newer version we could upgrade to that would sort this out "for free." If not, we're only using templating in this one place, so the code could probably be revised to achieve the same effect in a different way. The ideal solution might be to rewrite the whole component in React, since that seems to be the direction we're generally headed in, but that's obviously a bigger and more time consuming job.

Fixing this was not on our roadmap since I don't think anyone had encountered the problem before -- but it's certainly something we can talk about on the next Community Call. Let me know what you think, and whether you have any time available to help! If you need more input from my end, I can try to find time later in the week to investigate more thoroughly.

- Demian

[Anthony Hashemi]

It seems my previous response may only have been sent to Demian himself. I have since dug a bit deeper and found that it is in fact JSRender which  iiif-gallery-component uses to render html from templates that is the source of the unsafe-eval and they do not have plans to change the root cause of this any time soon. See: https://github.com/BorisMoore/jsrender/issues/336.

I have left a comment on it asking whether any of the others who were facing this issue found a suitable workaround but I am doubtful, aside from abandoning the security best practice or migrating to another rendering engine.

I have raised an issue on https://github.com/IIIF-Commons/iiif-gallery-component/issues/30 asking whether they would consider migrating to an alternative rendering engine which is CSP compliant. If yes, that would be great, otherwise we'd be left with the options of forking one of these (although I'd much prefer not to have that extra overhead) or changing the iiif gallery component used by Universal Viewer, although I am not aware of any alternatives currently, do any of you?

Best,
Anthony

[demian...@gmail.com]

Thanks, Anthony -- I've commented on the issue (suggesting that maybe we can eliminate the template engine entirely to simplify things); let's continue the discussion over there if there's more to say!

- Demian