[Html2PdfConverter] Content Security Policy (CSP) blocking images and CSS

[Html2PdfConverter] Content Security Policy (CSP) blocking images and CSS

  
Forge Component
(52)
Published on 30 Oct by Guilherme Pereira
52 votes
Published on 30 Oct by Guilherme Pereira

After activating the CSP on lifetime for the Production environment the PDFs are being generated without any formating or images. After a few tests we figured out that img-src and style-src rules need to have a '*' besides the 'self' to allow the corrcet generation of the PDF.

Since the 'self' is already there the '*' shouldn't be necessary since the URLs requested for the images and CSS are from the same server (self).

Any ideas on what might be happening here?

Thanks,

Pedro Delgado

Hi Pedro,

I asked for help on this one.

Let's hope someone can answer your question!

Cheers,

João

Hello,

Self is VERY restrictive. It says that the only trustworthy source is the domain itself. If the images are in a subdomain, they will not be loaded (don't know if it restricts paths, also)
The * says "load from everywhere"

So, my FIRST guess would be that the images and so on, that he is trying to load, are not exactly in the "same" place as the application. Also, if the site is http and he is trying to access is using https, it would block the images if using Self.

And, finally, what I was looking for.
Here: https://stackoverflow.com/questions/16627310/wkhtmltopdf-not-loading-local-css-and-images#16650685

It seems that if you add a "base" tag to the header, could solve the problem (it seems that is a problem of the executable not sending the information correctly to the server)

Seems really to be a problem of communication between the wkhtmltopdf executable and the server...

Cheers,
Eduardo Jauch

I'm not sure whether Eduardo's link above is really related to wkhtmltopdf's troubles with CSP. For us, the solution was to add 127.0.0.1 besides self for img-src, script-src and style-src. This is because HtmlToPdfConverter was invoking wkhtmltopdf with a local url starting with http://127.0.0.1.

Toni Juvani wrote:

I'm not sure whether Eduardo's link above is really related to wkhtmltopdf's troubles with CSP. For us, the solution was to add 127.0.0.1 besides self for img-src, script-src and style-src. This is because HtmlToPdfConverter was invoking wkhtmltopdf with a local url starting with http://127.0.0.1.

And the self is not enough because the executable is not fetching the images from the same domain (the app domain), even if they are in the same server.


Eduardo Jauch wrote:

Hello,

Self is VERY restrictive. It says that the only trustworthy source is the domain itself. If the images are in a subdomain, they will not be loaded (don't know if it restricts paths, also)
The * says "load from everywhere"

So, my FIRST guess would be that the images and so on, that he is trying to load, are not exactly in the "same" place as the application. Also, if the site is http and he is trying to access is using https, it would block the images if using Self.

And, finally, what I was looking for.
Here: https://stackoverflow.com/questions/16627310/wkhtmltopdf-not-loading-local-css-and-images#16650685

It seems that if you add a "base" tag to the header, could solve the problem (it seems that is a problem of the executable not sending the information correctly to the server)

Seems really to be a problem of communication between the wkhtmltopdf executable and the server...

Cheers,
Eduardo Jauch

Thankyou for sharing these information Mr.Jauch, 

it works..

How did you add the base tag? I tried calling HttpRequestUtility.SetBaseTag and passed in the HREF parameter (Target parameter as empty) but I didn't see a new tag when checking the source with a client.

Toni Juvani wrote:

How did you add the base tag? I tried calling HttpRequestUtility.SetBaseTag and passed in the HREF parameter (Target parameter as empty) but I didn't see a new tag when checking the source with a client.

Here I tried another method, in that i added the base tag in the value of an expression.