Embedding etherpad-lite without cookies?

[sumpfralle]

---

name: Feature request about: Suggest an idea for this project title: Embedding etherpad-lite without cookies? labels: enhancement assignees:

---

Is your feature request related to a problem? Please describe.

I am using etherpad-lite as an integration widget in Matrix/element. Thus etherpad-lite (provided by some external service provider, e.g. pad.disroot.org) is embedded via iframe into the website.

Sadly this fails to work, if the browser is configured to block 3rd party cookies.

Privacy oriented browsers (Tor browser, Brave) block 3rd party cookies by default.

Since March 2020 even Safari blocks 3rd party cookies by default. The announcement also contains some hints, how services can handle this change.

Thus it will probably become harder and harder to embed etherpad-lite into external websites. This would be a pity.

Describe the solution you'd like

I can image the following ways to work around the 3rd party cookie blocking:

• A) use the Storage Access API instead
• B) gracefully ignore cookie rejections (not storing a session)

But I have little knowledge in this field. Thus feel free to ignore my suggestions.

[JohnMcLear]

I swear this is a duplicate. I'm sure I addressed this a bunch of times before and the conclusion is for a good experience you should use reverse proxy of same domain.. did you look through previous issues before creating a new one?

[JohnMcLear]

https://github.com/ether/etherpad-lite/issues/4157 some details here..

[JohnMcLear]

https://github.com/ether/etherpad-lite/issues?q=is%3Aissue+is%3Aclosed+embed is general history of this issue..

[ptandler]

even if this might be a duplicate: I just experienced a lot of issues when trying to embed etherpad cross-domain ... so I +1 for this.

Without reading the referenced issues yet some thoughts: in fact you only need the cookies for reload or when navigating. If you could avoid app internal need for navigation (as currently to the pad history page, not sure is somewhere else) and also do this as single page app, then it might not be a (big) issue if no cookies can be stored.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[webzwo0i]

I would also love this feature

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ptandler]

To prevent it from closing: This is still something that I regard as very useful

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ptandler]

hm, reopen again ...?

[luukschipperheyn]

I encountered the same problem. An etherpad in an iframe on safari would fail to load because of an unhandled promise rejection:

TypeError: null is not an object (evaluating 'this.readPrefs_()[e]') -- {
  errorId: 'zztHuOF6QUx2ckIIep3v',
  type: 'Unhandled Promise rejection',
  msg: "TypeError: null is not an object (evaluating 'this.readPrefs_()[e]')",
  url: 'https://redacted/p/testpad',
  source: 'unknown',
  linenumber: -1,
  userAgent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.3 Safari/605.1.15',
  stack: 'getPref@https://[redacted]/javascripts/lib/ep_etherpad-lite/static/js/pad.js?callback=require.define&v=64b43bca:13:756\n' +
    '@https://[redacted]/javascripts/lib/ep_etherpad-lite/static/js/pad.js?callback=require.define&v=64b43bca:1:6216\n' +
    'promiseReactionJob@[native code]'
}

I don't have time atm to make a proper pull request but here's how I fixed it. in src/static/js/pad_cookie.js I changed getPref and setPref to handle cases where readPrefs would return null:

  getPref(prefName) {
    console.log('getPref', prefName);
    const prefs = this.readPrefs_()
    return prefs ? prefs[prefName] : null;
  }

  setPref(prefName, value) {
    const prefs = this.readPrefs_();
    if(!prefs) {return}
    prefs[prefName] = value;
    this.writePrefs_(prefs);
  }

[kfogel]

Is commit ada245affa118 in the ZUMTeam fork of Etherpad Lite a reasonable improvement? I.e., does it at least get Etherpad to the point where if someone who has configured their browser to disallow sites from setting cookies just wants to view a public Etherpad document, they could do so without error?

Right now, they would get an error like this:

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:
TypeError: this.readPrefs_() is null
at https://pad.example.com/javascripts/lib/ep_etherpad-lite/static/js/pad.js?callback=require.define&v=243ef3a8 at line 13
ErrorId: IpumQRweOwBH22fKEEjU
Unhandled Promise rejection
URL: https://pad.example.com/p/some-pad
UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0

We haven't tested that patch ourselves yet, but we might (CC @smpsnr). I'm not competent to review it, but if it at least allows the above then it might make sense to try to get it -- or something like it -- into stock Etherpad Lite.

[lislis]

Second what @kfogel says, it would be nice if people could just look at the pad without getting bombarded by messages