Skip to content

Feature userdb password restserver

Maxime Besson requested to merge feature-userdb-password-restserver into v2.0

Hi, @guimard I could use your opinion on my attempt to fix #1659 (closed) and #1598 (closed)

In order to do this, I had to expose these new routes in RESTServer:

# - Endpoints for proxy auth/userdb/password
#   * POST /proxy/getUser                        : get user attributes (restAuthServer)
#   * POST /proxy/pwdReset                       : reset password (restPasswordServer)
#   * POST /proxy/pwdConfirm                     : check password (restAuthServer or restPasswordServer)

These routes are protected by Apache, like every other sensitive RESTServer.pm feature, see e77f85db

However, we don't offer the level of protection that we have in the session rest server, where every session write has to be authenticated by some sort of signature (encrypted timestamp). That's because the API of Auth::REST, UserDB::REST and Password::REST does not specify this possibility.

In the current state, turning the new config options restAuthServer and restPasswordServer to On may expose admins to critical security issues (password change of any user without a confirmation) if bugs such as #1943 (closed) or #1933 (closed) appear again in the future.

Edited by Maxime Besson

Merge request reports