search

ether / etherpad-lite

Etherpad: A modern really-real-time collaborative document editor.
http://docs.etherpad.org/
Apache License 2.0
16.78k stars 2.86k forks source link

admin page not reverse-proxy friendly in v.2.2.6 #6752

Open risacher opened 2 weeks ago

risacher commented 2 weeks ago

(I've been running etherpad-lite behind a reverse-proxy since 2012.) Just upgraded to v2.2.6 and the admin pages do not work properly when not running at '/'.

For example, in my installation, etherpad-lite is accessible through the reverse proxy as "https://servername/pad/". I.e. a pad named test would be accessible as 'https://servername/pad/p/test'. This works okay, but the admin pages do not.

https://servername/pad/admin/ refers to the following URLs: https://servername/admin/assets/index-CSz1dsBf.js and https://servername/admin/assets/index-BSQTLHmC.css. Note that these URLs do not include the '/pad/' directory that allows the reverse-proxy to correctly route requests to etherpad-lite. (This happens for /favicon.ico too.)

FredMa01 commented 2 weeks ago

Are you using Apache reverse proxy ?

SamTV12345 commented 2 weeks ago

If you are using Nginx with Subdomains the configuration is already updated. With Apache it's currently a bit mixed. The very simple installation guide works at least for me. But haven't had a chance to play with the more complicated once.

risacher commented 2 weeks ago

For reasons that are obscure, I use a custom reverse proxy that I wrote (https://github.com/risacher/yxorp-edon) based on node-http2-proxy. This proxy has worked for Etherpad for the last 8 years, and it simultaneously works with Wekan, WordPress, Apache httpd, OwnCloud, Gitea, and a host of custom web apps. So it's probably not the proxy server...?

Although if there's something the proxy should be doing that it isn't I could add that.

risacher commented 2 weeks ago

FWIW, when I upgraded to 2.2.6, I hadn't adjusted anything in settings.json. I added all the new options in settings.json.template and deleted all the old ones, but it made no difference.

risacher commented 2 weeks ago

I'm puzzled if/how this works for any reverse proxy. In /src/static/pad/socketio.js there is logic that explicitly uses etherpadBaseUrl to set the options for socket.io, which correctly routes socket.io endpoints to the baseUrl path. Alas, equivalent logic does not exist for /admin/src/App.tsx and /admin/src/store/store.ts, and that code therefore tries to open socket.io endpoints bypassing the base path.

To get this far, I set "base" in /admin/vite.config.ts to "/pad/admin" (as a workaround) and then tried changing "/admin-auth/" to "../admin-auth/" in /admin/src/App.tsx and /admin/src/pages/LoginScreen.tsx and now it successfully logs in my admin user (according to console.log), but then fails because it can't create the socket.io endpoint.

Investigation continues.

SamTV12345 commented 2 weeks ago

There is a workaround for this. You need to set the x-proxy-auth header. Then everything should be rewritten.

risacher commented 1 week ago

I think you mean x-proxy-path? I added that header to my proxy server and it doesn't seem to work. I see the code in etherpad-lite/src/node/hooks/express/admin.ts that seems like it should handle this, but at first blush it doesn't seem to be. I'm looking at it. [edit: I was setting x-forwarded-path, not x-proxy-path]

SamTV12345 commented 2 days ago

Great. So everything should work hopefully :)