Etherpad: Uncaught TypeError: Cannot read property 'setStateIdle' of null

[Kim-Alexander Brodowski]

Hello,

once again I have a quick workaround for issues we've been noticing recently with Google Chrome.

Google has changed their cookie policy and at least for our particular setup this also affects BBB.

When accessing the shared notes tab users receive the following error message:

An error occurred
The error was reported with the following id: 'zkGUMu1ZaT0WQA3j00SK'

Please press and hold Ctrl and press F5 to reload this page, if the problem persists please send this error message to your webmaster:

'ErrorId: zkGUMu1ZaT0WQA3j00SK
URL: https://bbb1c613.videoconference.iserv.eu/pad/p/f7e8f429?showLineNumbers=false&showChat=false&noColors=true&showControls=true&rtl=false&userName=Kim%20Brodowski&userColor=%237b1fa2&lang=en&sessionToken=a9owwrin0pqw3mpa
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
Uncaught TypeError: Cannot read property 'setStateIdle' of null in https://bbb1c613.videoconference.iserv.eu/pad/javascripts/lib/ep_etherpad-lite/static/js/pad.js?callback=require.define at line 3'

Workaround:

Add the following line to your nginx BBB server block:

proxy_cookie_path / "/; SameSite=none; Secure";

Why is this error shown in the first place? My assumption is that Etherpad sets cookies with neither the SameSite attribute nor the secure flag. The latter might be the result of our particular setup where traffic is routed over HTTP internally (without TLS), but with TLS externally, which might lead Etherpad to believe the connection is insecure. Together with the new cookie policy from Google and lack of an explicit SameSite attribute this causes issues.

The workaround above has the added benefit of preventing downgrade attacks, since all cookies will be flagged secure.

Technically speaking this is an Etherpad bug, but from what I can tell upstream versions now correctly set the SameSite attribute. BBB 2.3 should be able to just pull newer Etherpad versions which will fix the issue there.

I hope this helps someone.

Best regards,
Kim-Alexander Brodowski

IServ GmbH

[Pedro Beschorner Marin]

This doesn't make much sense to me.

Since Etherpad runs inside an iframe, SameSite=None and Secure are already the default configuration and you can verify that at demo.bigbluebutton.org. Etherpad runs 4 cookies if you are not sure on what to look for: express_sid, language, prefs and token.

Not sure what else you run in your servers. Saw similar problems before. Once because there was some kind of third-party proxy running inside the server that was dropping the connections' headers so express wasn't able to validate TLS and other one when the whole client was running inside an iframe and JSESSIONID cookie configuration wasn't respecting that.

[Kim-Alexander Brodowski]

As I've said. We do run another proxy, but that's also in front of any BBB traffic. See the sceenshot below for what we receive.

As far as the SameSite attribute is concerned: Not setting any SameSite attribute is equivalent to SameSite=Lax. This is why I consider this an Etherpad bug, becuase SameSite=none is sent without the secure flag. SameSite=Lax should have worked for us.

I did actually get this wrong in the explanation above, not sure why.

[Pedro Beschorner Marin]

By your screenshot I'm almost sure your problem is express.js not being able to recognize a https header. While you check that out (and If you rather use SameSite=Lax) there is an option at Etherpad's configuration file that disables the SameSite=None for embedded setups. At /usr/share/etherpad-lite/settings.json, set forceSameSiteNone to false and restart Etherpad's service.