Failed to read a named property 'document' from 'Window': Blocked a frame with origin "https://etherpad.domain.tld" from accessing a cross-origin frame.

[tgrymatt]

I have installed etherpad-lite on a Debian 12 machine and configured an apache server. It is configured like this:

<IfModule mod_ssl.c>
    <VirtualHost *:443>
        ServerName etherpad.domain.tld

        # SSL configuration
        SSLEngine on
        # If you hold wildcard certificates for your domain the next two lines are not necessary.
        SSLCertificateFile "/etc/letsencrypt/live/etherpad.domain.tld/fullchain.pem"
        SSLCertificateKeyFile "/etc/letsencrypt/live/etherpad.domain.tld/privkey.pem"

        ProxyVia On
        ProxyRequests Off
        ProxyPreserveHost on

        <Location />
            ProxyPass http://192.168.16.203:9001/ retry=0 timeout=30
            ProxyPassReverse http://192.168.16.203:9001/
        </Location>
        <Location /socket.io>
            # This is needed to handle the websocket transport through the proxy, since
            # etherpad does not use a specific sub-folder, such as /ws/ to handle this kind of traffic.
            # Taken from https://github.com/ether/etherpad-lite/issues/2318#issuecomment-63548542
            # Thanks to beaugunderson for the semantics
            RewriteEngine On
            RewriteCond %{QUERY_STRING} transport=websocket    [NC]
            RewriteRule /(.*) ws://192.168.16.203:9001/socket.io/$1 [P,L]
            ProxyPass http://192.168.16.203:9001/socket.io retry=0 timeout=30
            ProxyPassReverse http://192.168.16.203:9001/socket.io
        </Location>

        <Proxy *>
            Options FollowSymLinks MultiViews
            AllowOverride All
            Order allow,deny
            allow from all
        </Proxy>

#RequestHeader unset Access-Control-Allow-Origin
#RequestHeader unset Set-Cookie

#Header set Access-Control-Allow-Origin "*"
#Header append Set-Cookie "Path=/; HttpOnly; SameSite=Lax"
#RequestHeader set X-Forwarded-Proto "https"
#RequestHeader set Access-Control-Allow-Origin "*"

Header set Content-Security-Policy "script-src 'self' jitsi.domain.tld etherpad.domain.tld;"


    </VirtualHost>
</IfModule>

If I open https://etherpad.domain.tld on my computer everything is working fine. In the settings.json file I configured:

(...)

  "trustProxy": true,
  "cookie": {
    "keyRotationInterval": 86400000, // = 1d * 24h/d * 60m/h * 60s/m * 1000ms/s (86400000)
    "sameSite": "None",
    "sessionLifetime": 864000000, // = 10d * 24h/d * 60m/h * 60s/m * 1000ms/s (864000000)
    "sessionRefreshInterval": 86400000 // = 1d * 24h/d * 60m/h * 60s/m * 1000ms/s (86400000)
  },

(...)

Now I installed Jitsi Meet on a different server to jitsi.domain.tld and I added the configuration for Etherpad to Jitsi:

etherpad_base: 'https://etherpad.domain.tld/p/',

If I am click on the Etherpad icon in a jitsi meeting, the website is showing me this error message:

An error occurred
Please press and hold Ctrl and press F5 to reload this page

If the problem persists, please send this error message to your webmaster:

SecurityError: Failed to read a named property 'document' from 'Window': Blocked a frame with origin "https://etherpad.domain.tld" from accessing a cross-origin frame.
at unknown at line -1
ErrorId: tSzug5ObJqVpLmSKc8lq
Unhandled Promise rejection
URL: https://etherpad.domain.tld/p/it-coffebreak?showControls=true&showChat=false&showLineNumbers=true&useMonospaceFont=false&userName=fdsf
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

But if I am using a different Etherpad which are public available like for example https://etherpad.bildung-rp.de it is working fine without any changed on the jitsi machine. (Sure, I changed the etherpad_base variable to https://etherpad.bildung-rp.de/p/)

Any ideas or hints?

[tgrymatt]

It looks like, that it is regarded to the master-branch and to the version 2.2.2. With Version 2.1.1 I don't have this problem.

[SamTV12345]

It seems like this is related to the JavaScript change. Seems like it can't access the document when accessing from within an iframe. Do you have something like a docker compose where I could work on a fix? Haven't used Etherpad with Jitsi yet.

[tgrymatt]

@SamTV12345 we installed Jitsi and Etherpad manually. But I have a docker, where I could deploy an Etherpad and try it with my test Jitsi. So if this helps you, contact me.

[ger82]

Hi, I have nearly the same problem. I get this massage: SecurityError: Blocked a frame with origin "https://app.example.org" from accessing a cross-origin frame. Protocols, domains, and ports must match. And this: SecurityError: Failed to read a named property 'document' from 'Window': Blocked a frame with origin "https://app.example.org" from accessing a cross-origin frame.

With Version 2.1.1 it works.

I have install it from git on a ubuntu 20.04 maschine.

[zib-ctrl]

Have same issue:

SecurityError: Failed to read a named property 'document' from 'Window': Blocked a frame with origin ......... accessing a cross-origin frame.

With version 2.1.1 everything works fine.

[ger82]

Is there a fix for this Problem?

[fmcsecurity]

Yep, same error on 2.2.4 whilst running with Odoo. Reading the pads works fine, but creating/editing doesn't.

The instances are on different subdomains, same TLD.

[dcht00]

Also see #6618

[SamTV12345]

@tgrymatt @ger82 @zib-ctrl @fmcsecurity Please try the latest develop image of Etherpad. I removed all cross origin iframe requests.

[SamTV12345]

I'll close this for now. Someone already posted that it works now :)

[dcht00]

Confirming it works for me to, just make sure you're on the 'develop' (not 'master') branch.

[cboylan]

Is this the commit that fixes things: https://github.com/ether/etherpad-lite/commit/a61f634586017dcadffd859820b66cd5916cef3a ? We also run a jitsi meet server with embedded etherpad documents and are hitting a similar issue (the errors are actually more similar to those in https://github.com/ether/etherpad-lite/issues/6618). I'm wondering if we can cherry pick this specific fix onto 2.2.4 to minimize the delta between what we run and released code.

Or maybe a 2.2.5 release will be happening soon? It looks like there are a handful of other fixups on the develop branch currently.