Deferring or avoiding ImageRenderer

[anthonyryan1]

I recently upgraded from an older version of this (qr.js) and noticed that the new version generated a Content Security Policy warning the website where I deployed it. The website doesn't allow data URIs under any circumstances and the ImageRenderer creates an image tag and populates it with a data URL as part of the constructor now.

One solution might be to not render the image until a method call requesting it has been made.

[neocotic]

@anthonyryan1 I'm a bit confused, to be honest. Why don't you simply modify your CSP header? I believe that img-src 'self' data: should allow what you're looking for.

As for the last part, this is already what happens. QRious does not render anything until you instantiate QRious. Also, why would deferring the image rendering workaround CSP?

[anthonyryan1]

That is possible, but data URIs are generally frowned upon within CSP since it's impossible to determine the "origin" of a data URI (as compared to a normal URI where you can use CORS rules and compare to a domain whitelist).

I'm using QRius to print a QR code on a canvas. I'm not using an img tag and I'm not calling any methods (eg: toDataURL) that I thought would generate an image. The violation occurs as soon as any img tag has a data URL attached to it as the source, so in QRius it happens here: https://github.com/neocotic/qrious/blob/master/src/renderer/ImageRenderer.js#L39

I'm happy to submit a patch for this, but I wanted to talk about any reasons the code works the way it does first, in case there's something I'm missing.

My current thought would be that if a canvas element is passed to QRius, we could simply use the CanvasRenderer. But if an img element is passed, both renderers will need to be run, since the canvas is necessary for producing the image.

Does this sound like a good approach to you?

[neocotic]

This makes more sense to me now and I like your approach, however, we'd also need to continue to ensure that image is rendered, if needed. It'd also need to support the rendering of image any time after it has been referenced as it could well have been inserted into the page. We could place the image property behind a getter method to track any access to it.

This sounds like a worthwhile change, but I'll need to consider it further to see if we can achieve it while retaining backwards compatibility.

[neocotic]

These changes will be included in the 2.3.0 release which I'm hoping to push out today (within the next hour probably - see #78). Please let me know how you get on with this.