1.8.13: page load broken with 'self' content security policy (Ace2Editor.init() error event while waiting for load event)
#4975
Comments
|
works for me on ff 87.0/node 15.12.0/npm 7.7.4 Do you see any other errors in developer console when this happens? |
|
same issue with a reverse proxy and authenticatication in the proxy. |
|
Interesting! Would be cool to get this fixed. |
|
maybe related to #4820 |
my bad, failed with or without reverse proxy. |
here are the result : and same thing with node 16 and npm 7.10 |
|
Can you post a list of your installed plugins+version please. |
|
I can, but actually i restarted from a fresh install.
It works behind an apache RP with authentication through apereo CAS.
hope it can help. I still have something that bothering me. Regards |
|
Could it be that the server (a proxy server like nginx) is setting a Content-Security-Policy header (CSP)? That can be checked in the server configuration, or in a web browser’s inspector/developer tools (in Firefox for example: Tools → Web Developer → Web Console, then expanding the GET requests and looking for Response Headers; in that console you also see the errors if something is blocked by CSP), or in a tool like curl ( I noticed the mentioned error message and non-working pads with Etherpad Lite version 1.8.13 when in the proxying nginx a Content-Security-Policy was set. The error was gone when the Content-Security-Policy was not set (or a permissive one like |
|
I just upgraded etherpad from 1.8.6 to 1.8.13 and hit this issue. Previously something like this worked just fine Now |
|
I was able to bisect it, |
|
Do all browsers behave the same? This looks like a browser bug to me (see MDN), but I don't know enough about CSP to be sure. |
|
I see the problem in Firefox 89 and I do not see it in Chromium 90. I'm just running 1.8.12 instead for now. |
|
Not a browser bug, but non-perfect spec, see w3c/webappsec-csp#459 and https://bugzilla.mozilla.org/show_bug.cgi?id=1567970 :-( |
|
I can confirm that adding the host to the CSP header explicitly "fixes" this. However, given that 40448606 broke this, I'd appreciate this being fixed in etherpad, rather than waiting for mozilla to investigate this. |
|
Reverting commit 4044860 is not feasible, and it's unclear to me how to work around this in Firefox. If someone can figure out an approach that works I'd be happy to apply it. |
Those links are talking about an unrelated issue. (Those are regarding the meaning of "self" when used in a I did some more digging and to me the standard is clear on this topic:
So I really think this is a Firefox bug, not a flaw in the standard. I couldn't find it reported anywhere so I did some more investigation and this bug only happens when you have nested srcdoc iframes ( |
|
I really appreciate the effort @rhansen! In CSP3 draft the cited paragraph doesn't appear anymore and there is:
Our inner iframe has an opaque origin (srcdoc) and has inherited it's policy (from the outer iframe where it was dynamically generated), but not sure it is a "local scheme document".
(we don't use sandbox or explicit base hrefs, though) Because of this I thought CSP3 is way more clear than CSP2 (although the above paragraphs might not apply to our use case), then I found https://github.com/antosart/policy-container-explained which I probably misinterpreted (it seems to talk about unifying the different approaches to inheritance across all the various policies out there). Indeed I run the tests with meta tags - ignoring that policies won't be enforced to anything above the meta tag. Besides that my understanding is that it shouldn't make a difference if CSP is applied via header or meta?! So thanks again for filling the bug report and let's see if we get some insights from mozilla. @dvzrv Is anything blocking you from not using self? Maybe we can add some other code that helps setting a correct header not using "self"? It was a bigger effort to get to where we are now regarding page load, so reverting the commit is not an option imo. @rhansen Just in case: What do you think, if we'd try to remove iframes entirely from Etherpad? There was a PoC PR some time ago. IMO, this would be a clever step for the future, but I'm not sure if it'll break anything badly. |
|
It's getting even weirder: (After adding require-kernel/ace2inner/ace2common to script tags instead dynamically adding from parent) Adding any or both of innerFrame.csp and outerFrame.csp with a value of Adding |
Using srcdoc, especially with multiple nested iframes, seems to be problematic when using `self` in CSP policies.
|
@rhansen If you'd accept something like #5124 (probably with relative links) I can add some more templating, so that it would reduce the amount of script/style injections etc in ace.js. I expect a large amount of code in ace.js to become obsolete after doing this. At least this seems to fix the CSP issue, as it works with I must admit, I don't remember why we used |
The CSP3 draft is difficult to read, but I think it's more subtle than that. The location for srcdoc iframes is a URL with a local scheme ( (I'm far from an expert on this topic, so my understanding of the spec could be wrong.)
In the long run I think it would result in better code, but I think it would take a considerable amount of effort. In particular, we would need to figure out a way to migrate plugins (example).
Setting CSP in a srcdoc iframe's meta tag is the topic of the bugs you originally linked. In other words, the standard is not clear. (If you set the CSP in the meta tags for the top-level frame (
I like the approach in PR #5124. For the first iteration I would prefer to serve empty HTML and leave the code in |
rhansen
changed the title
'self' content security policy (Ace2Editor.init() error event while waiting for load event)
Using srcdoc, especially with multiple nested iframes, seems to be problematic when using `self` in CSP policies.
Using srcdoc, especially with multiple nested iframes, seems to be problematic when using `self` in CSP policies.
|
This is also happening with the newest version of etherpad. Works in FF, but fails in chrome / android. Please add a |
|
So as an Option? As far as I can see this can imply security issues with XSS. I'll have a look how to implement that. |
|
Yep, that'd be best. Only add the CSP headers if |
|
Alright. I'll try that. If it's simply another header being conditionally added it should not be too hard. |
Found the plugin suitable for this: #4031 |
|
@dessalines |
|
For me it works on Chrome (123) and Chrome on Andoid (119?). In case you cannot provide working steps to replicate, can you try to Disabling seems like a workaround, but the underlying problem needs to be identified. |
|
Whoa, I waited a few hours and the issue cleared up. Not even restarting my machines, or reinstalling etherpad worked at first. Sorry about that yall. It probably had to do with not enabling |
|
Great that this is resolved now |
Describe the bug
After updating from 1.8.12 to 1.8.13 (no plugins, plain packaged version that I provide in the AUR), I get the following on loading any pad:
Reloading the page doe not fix the issue.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
pad loads normally
Screenshots
Server (please complete the following information):
node --version): v15.12.0npm --version): 7.7.4Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
Downgrading to 1.8.12 fixes the issue.
The PKGBUILD that creates the package can be found here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=etherpad-lite
The text was updated successfully, but these errors were encountered: