Description
Etherpad doesn't seem to call the authenticate plugin hook when users attempt to log in to the admin panel via /admin-auth/. This makes it impossible for authentication plugins (I tested with ep_hash_auth, but presumably any plugin relying on this hook) to handle admin logins.
Steps to reproduce
- Install
ep_hash_auth on Etherpad 3.3.2 and configure it with a hash_dir and valid bcrypt .hash files
- Add a user to the
users block in settings.json with is_admin: true but no password field
- Attempt to log in to
https://your-instance.url/admin
- Observe 401, with nothing logged by
ep_hash_auth
Expected behavior
Logging in as an admin user whose password is stored on the server as a hash should be possible with ep_hash_auth installed and correctly configured.
Server (please complete the following information):
- Etherpad version: 3.3.2
- OS: Debian 13
- Node.js version: 24.18.0
- npm version: 11.16.0
- Is the server free of plugins: No
- Are you using any abstraction IE docker? No
Desktop (please complete the following information):
- OS: Linux Mint
- Browser Tested on Firefox and Chromium
- Version 22.1
Additional context / investigation
The /admin-auth/ endpoint is defined in src/node/hooks/express/openapi-admin.ts as a built-in Express endpoint (verifyAdminAccess) that handles Authorization: Basic headers internally and returns 200/401/403 directly, before the plugin hook system gets involved. As a result, admin authentication seems to be hardwired to check settings.users[username].password in settings.json and I'm not sure whether plugins cannot intercept or override it.
This means that the only way to protect the admin panel (afaik) is a plaintext password in settings.json. This constitutes a regression for installations that use ep_hash_auth specifically to avoid keeping plaintext passwords on disk.
Adding console.log statements directly to ep_hash_auth's authenticate function produced no output when admin login was attempted, despite the browser correctly sending Authorization: Basic <base64> (confirmed via browser dev tools network tab). The hook is registered correctly per ep.json and fires for pad-level authentication; the issue seems to be specific to /admin-auth/.
ep_hash_auth v11.0.24 was tested. The expressCreateServer hook registered by ep_hash_auth only handles logout and does not provide an alternative interception path. There is no version of ep_hash_auth that I'm aware of that can work around this, so any fix would have to come from Etherpad core.
A plaintext password field in settings.json does work for admin authentication, confirming that Etherpad's internal handler reads credentials directly from settings.json.
Description
Etherpad doesn't seem to call the
authenticateplugin hook when users attempt to log in to the admin panel via/admin-auth/. This makes it impossible for authentication plugins (I tested withep_hash_auth, but presumably any plugin relying on this hook) to handle admin logins.Steps to reproduce
ep_hash_authon Etherpad 3.3.2 and configure it with ahash_dirand valid bcrypt.hashfilesusersblock insettings.jsonwithis_admin: truebut nopasswordfieldhttps://your-instance.url/adminep_hash_authExpected behavior
Logging in as an admin user whose password is stored on the server as a hash should be possible with
ep_hash_authinstalled and correctly configured.Server (please complete the following information):
Desktop (please complete the following information):
Additional context / investigation
The
/admin-auth/endpoint is defined insrc/node/hooks/express/openapi-admin.tsas a built-in Express endpoint (verifyAdminAccess) that handlesAuthorization: Basicheaders internally and returns 200/401/403 directly, before the plugin hook system gets involved. As a result, admin authentication seems to be hardwired to checksettings.users[username].passwordinsettings.jsonand I'm not sure whether plugins cannot intercept or override it.This means that the only way to protect the admin panel (afaik) is a plaintext password in
settings.json. This constitutes a regression for installations that useep_hash_authspecifically to avoid keeping plaintext passwords on disk.Adding
console.logstatements directly toep_hash_auth'sauthenticatefunction produced no output when admin login was attempted, despite the browser correctly sendingAuthorization: Basic <base64>(confirmed via browser dev tools network tab). The hook is registered correctly perep.jsonand fires for pad-level authentication; the issue seems to be specific to/admin-auth/.ep_hash_authv11.0.24 was tested. TheexpressCreateServerhook registered byep_hash_authonly handles logout and does not provide an alternative interception path. There is no version ofep_hash_auththat I'm aware of that can work around this, so any fix would have to come from Etherpad core.A plaintext
passwordfield insettings.jsondoes work for admin authentication, confirming that Etherpad's internal handler reads credentials directly fromsettings.json.