Did you find the "correct" config. I am also searching for a secure and working config for the etherpad server.

Why EditOnly on etherpad? I've got etherpad working behind an https reverse proxy via nginx, I just only offer access through tasks (and issues) and allow creating/editing like normal. If you really wanted to lock it down you could probably use an iptables rule to only allow connections over the etherpad port from your ERP or reverse proxy IP.

Thanks for your post. My config is also a dedicated vm with https via nginx. My thought is that it is reachable by everyone "guessing" some etherpad adress. https://myserver:port/ABAJAUADN is hard to guess, but i am not sure if it is impossible. So the content of my pads would be open to everyone if not refused by etherpad-lite. The connection in my understanding is not odooetherpad but odoo->browser of client->etherpad-lite. IP tables does not help here? So, the question is refered to the config of etherpad-lite, without problems with odoo integration. This is my actual etherpad config. /* Users must have a session to access pads. This effectively allows only group pads to be accessed. */ "requireSession" : false, /* Users may edit pads but not create new ones. Pad creation is only via the API. This applies both to group pads and regular pads. */ "editOnly" : false, /* Users, who have a valid session, automatically get granted access to password protected pads */ "sessionNoPassword" : false, /* This setting is used if you require authentication of all users. Note: /admin always requires authentication. */ "requireAuthentication": false, /* Require authorization by a module, or a user with is_admin set, see below. */ "requireAuthorization": false, /*when you use NginX or another proxy/ load-balancer set this to true*/ "trustProxy": true, if my users could use etherpad with ldap authentication additionally to the odoo integration with api would be fantastic. Short: Is this config secure? Thanks

iptables definitely would help. The reverse proxy is the one communicating with etherpad, not the client (that's what makes it a reverse proxy). At that point the only way to reach etherpad would be through the reverse proxy or by SSH tunnels to the reverse proxy server. Etherpad would effectively only ever see connections from your reverse proxy, direct access would be blocked before reaching the socket in the first place.

Hy @sulzi, I think there is a bug somewhere. I had the same problem and etherpad seems to have the options to manage API creation. So I reported a bug : https://github.com/odoo/odoo/issues/6399