Asciidoctor :: Discussion

Content-Security-Policy Troubles

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Gary Keim

Content-Security-Policy Troubles

Recent updates to some browsers (FF, Chrome) have brought some issues relating to the newly-enforced Content-Security-Policy. We can view our docs via Jenkins, but after these updates embedded styles fail to load because the default policy disallow that, as well as external styles like Font Awesome via the CDN.

There are two (2) ways I can see to fix this: (1) linkcss and (2) using docinfo1 to added a new psuedo-header with:

<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline' 127.0.0.1 https://cdnjs.cloudflare.com">

Using linkcss is problematic because we also use preserveDirectories, meaning a bunch of different files need to do this:

:top: ../..
:stylesdir: {top}/stylesheets

Using docinfo1 almost works but unfortunately the content gets appended as the last elements of <head>, too late to take affect on the earlier <style> elements.

Anyone one else run into this and maybe have a brilliant solution I hadn't considered?

mojavelinux

Re: Content-Security-Policy Troubles

Administrator

First of all, I can't believe that Chrome and Firefox are breaking the web as we know it. That's just insane.

Complaining aside, let's talk about what we can do...

First, I recommend using linkcss whenever you are publishing to production. Embedding the stylesheet is the default behavior to make development simpler (as you don't need to worry about paths), but it bloats pages and generally not how web content is typically managed.

Just like with any site that has nested pages, you probably want to use an absolute web path to the stylesheet file. To accomplish that, you'd use:

-a linkcss -a copycss! -a stylesdir=/styles

Obviously, you need to deploy the stylesheet separately to the docs site.

We do want to make it easy to change the base CDN URI globally (see https://github.com/asciidoctor/asciidoctor/issues/659). Until then, there are some attributes you can use to control the URI for specific assets. In the case of Font Awesome:

-a iconfont-remote!

Then put the Font Awesome stylesheet in the stylesdir and name it font-awesome.css. (see https://github.com/asciidoctor/asciidoctor/blob/master/lib/asciidoctor/converter/html5.rb#L75-L82) (the fonts need to go in the adjacent fonts directory).

If you want to pursue your original idea of adding a <meta> element, then I recommend injecting it into the HTML using a custom script or an Asciidoctor postprocessor. Docinfo is not designed for this use case.

Of course, I'd be completely willing to add this <meta> element to the header by default. That's probably the most correct thing to do here. Please file an issue so we can discuss.

Cheers,

-Dan

On Mon, Feb 8, 2016 at 1:30 PM, Gary Keim [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Recent updates to some browsers (FF, Chrome) have brought some issues relating to the newly-enforced Content-Security-Policy. We can view our docs via Jenkins, but after these updates embedded styles fail to load because the default policy disallow that, as well as external styles like Font Awesome via the CDN.

There are two (2) ways I can see to fix this: (1) linkcss and (2) using docinfo1 to added a new psuedo-header with:

<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline' 127.0.0.1 https://cdnjs.cloudflare.com">

Using linkcss is problematic because we also use preserveDirectories, meaning a bunch of different files need to do this:

:top: ../..
:stylesdir: {top}/stylesheets

Using docinfo1 almost works but unfortunately the content gets appended as the last elements of <head>, too late to take affect on the earlier <style> elements.

Anyone one else run into this and maybe have a brilliant solution I hadn't considered?

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Content-Security-Policy-Troubles-tp4281.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen

Gary Keim

Re: Content-Security-Policy Troubles

Yeah, it's not a new browser thing, it's a new Jenkins "feature":

https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy

mojavelinux

Re: Content-Security-Policy Troubles

Administrator

That makes a lot more sense. Thanks for the clarification (and for saving me from panicking about support requests).

I still think the content security policy header might be a good thing to explore, because this could be a common need for sites that do enable it.

Until then, I recommend injecting it directly into the <head> element using regexp (or something like a JSTransformer).

-Dan

On Tue, Feb 9, 2016 at 11:49 AM, Gary Keim [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Yeah, it's not a new browser thing, it's a new Jenkins "feature":

https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Content-Security-Policy-Troubles-tp4281p4287.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen

Jeremie Bresson

Re: Content-Security-Policy Troubles

In reply to this post by Gary Keim

It was also the case in our company.

We are building our adoc documentation on our CI server (Jenkins) and the readers open the PDF or the HTML version directly from there. The URL is something like
buildserver.ourcompany.local:8088/jenkins/job/documentation-job/lastSuccessfulBuild/artifact/doc/target/generated-docs/example-manual.html

After a Jenkins Update we needed to modify the CSP header sent by Jenkins to work around the problem (this is somehow OK, because the server is not accessible from outside our company). It is definitively not nice, and we would prefer a solution at Asciidoctor level.

Caden Howell

Re: Content-Security-Policy Troubles

In reply to this post by mojavelinux

I realize that this thread is more than a year old, but I've just run into this issue with a new AsciiDoctor project. This information was valuable to me:

Multiple meta tags or headers that specify a Content-Security-Policy can only further restrict the content security policy. So, if Jenkins is adding a strict Content-Security-Policy, you can not undo that by adding a meta tag with a Content-Security-Policy. At least, this is what I'm seeing with our Jenkins server and experimenting with Content-Security-Policy meta tags.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#Multiple_content_security_policies