Public bug reported:
"mailman" manages users with their individual passwords. It is supposed to be controlled via a REST api which uses a global (user independent) authentication. Obviously, an arbitrary user should not be allowed to change preferences (and other settings) for a different user. This implies that a REST client has to check user access rights and (especially) verify the user's identity. The typical way for user identity verification would be to check that the user knows the password registered with this user in "mailman". However, the REST api lacks a corresponding operation.
The REST api should probably be extended by a "verify_password" user subresource. To avoid passwords being logged by typical webserver logging, the password to be verified should probably be submitted via "POST" (not transmitted as part of the "URL").
If the project does not want to go this route (password verification via a REST operation), then it must document how a client can verify a given cleartext password against the encrypted password information available as user attribute.
** Affects: mailman Importance: Undecided Status: New
** Tags added: mailman3 rest
** Branch linked: lp:~barry/mailman/lp1065447
Here's how I'm going to do this. You post to http://.../users/%7Bid%7D/login and the form data must contain exactly one parameter `cleartext_password`. If the value matches the stored, hashed password, an HTTP 204 (No Content) is returned. If they do not match, an HTTP 403 (Forbidden) is returned. There is no content body in either case, and thus the POST creates no addressable resource.
The nice thing is that this will support hash migration as per passlib.
** Changed in: mailman Milestone: None => 3.0.0b3
** Changed in: mailman Assignee: (unassigned) => Barry Warsaw (barry)
** Changed in: mailman Importance: Undecided => High
** Changed in: mailman Status: New => In Progress
** Changed in: mailman Status: In Progress => Fix Committed
** Changed in: mailman Status: Fix Committed => Fix Released