Remove inline styles; drop unsafe-inline style-src CSP; fixes for iframes (#950)#2151
Remove inline styles; drop unsafe-inline style-src CSP; fixes for iframes (#950)#2151scottmakestech wants to merge 1 commit intomainfrom
Conversation
…ames (#950) - Replaced inline style attributes in theme partials, shortcodes, blog posts, paypal_form.html, and translated content with Tailwind utility classes - Refactored newsletter iframe resizing - Moved newsletter form to shared partial - Debug issues with newsletter resizing when the iframe changes height - CPS documents: added scripts/convert-inline-styles.js for converting inline styles - Updated Content-Security-Policy in both server.toml and netlify.toml to remove 'unsafe-inline' from style-src
|
Hi @bdaehlie - this PR covers changes to remove inline styles so we can remove the ability to use inline styles on the site. One thing this affects is the CPS documents - I'm not sure where you're generating these but I assume it's outputting HTML from a Word Processor. My solution is a script that will automatically convert inline styles to class names. It should be pretty easy to use: That way you don't have to change your current process other than this added step. Does that work for future CPS updates? |
|
This PR may cause the hash of our current CP/CPS documents to change, which will cause duplicate documents to be created in CCADB. This issue is tracked here: #2106 This isn't a huge problem, as long as we're completely aware of it and ready to deal with the fallout the next time we update our policy documents in CCADB. But that is a single-point-of-failure problem (how do we make everyone else aware? what if the person doing the update isn't me?), and we need to have a systematic solution before long. Not saying this to block this PR, and there's a chance that this won't actually change anything (it doesn't explicitly touch our current CPS docs, and I don't know if linked stylesheets are included in CCADB's hash). Just making sure we're all aware. |
@aarongable Thanks for bringing this to my attention. If minor HTML changes would cause a hash to change, I think that's a strong case for moving CPS documents to a subdomain, since the templates will drift over time as things shift and things like generated CSS/JS filenames change. If we create a new subdomain, we can create redirects on the main site so a user will still end up at the correct document if they are following the previous URL. Looking into this, it appears only the 2.8 and 2.9 CPS files had inline styles. None of the other CP/CPS documents did, including the 6.0 version which is the destination for cps.letsencrypt.org. So it looks like the current method of exporting these documents no longer includes inline styles, which is great. If modifying the 2.8 and 2.9 documents was truly problematic, I could set the inline-styles to still be permitted on those documents only and block it from the rest of the site. But, as stated in the first paragraph, the site's HTML is going to drift over time, so I think the core issue of #2106 can only be fixed (for future versions) by moving to a sub-domain. Happy to work on a solution that works for you. Sorry if I'm missing/misunderstanding any details about the CPS documents/CCADB, I tried looking for the documents/hashes to get a better understanding but couldn't find them. |
|
I don't think modifying the v2.8 and v2.9 documents will be a problem; I can't think of any reason why CCADB would be prompted to re-fetch those documents and recomupte their hashes. From my first glance at this PR, I thought it was also updating our existing stylesheets to include definitions for the classes you're using, and I was afraid that this update would change the hash of our most recent CP/CPS. But now I see that no such shared resources are being updated, so I think this PR will be safe. Let's keep discussing protecting the CP/CPS from future accidental changes in that bug. |
2 participants
Fixes #950