Public bug reported:
Currently there is no way to check a user's credentials via the REST API. While there were discussions on implementing a middleware "hook" to implement complex authentication logic, there should also be a simple way to check if a given combination of a user's credentials (user name and password) matches the one stored in mailman's internal db.
A good way to do this (as discussed on IRC a while ago) could be to implement a SQL stored procedure-like behavior in the REST API. Meaning: A client sends a uname/pwd-combination to a specific URL resource and receives a plain True or False (1 or 0?) if the combination matches. This way, no password string is sent out via the API.
Things to discuss or consider:
1.) How is the password stored in MMs internal db? (plaintext or hashed? if hashed, which algorithm is used?) 2.) (How) should the pwd be encrypted when sent to the API (depends on 1.)? 3.) Should this API resource be limited to requests from localhost and/or via SSL?
** Affects: mailman Importance: Undecided Status: New
** Tags: mailman3
** Description changed:
Currently there is no way to check a user's credentials via the REST API. While there were discussions on implementing a middleware "hook" to implement complex authentication logic, there should also be a simple way to check if a given combination of a user's credentials (user name and password) matches the one stored in mailman's internal db.
A good way to do this (as discussed on IRC a while ago) could be to implement a SQL stored procedure-like behavior in the REST API. - Meaning: A client sends a uname/pwd-combination to a specific URL resource and receives a plain True or False (1 or 0?) if the combination matches. This way, no password string is sent out via the API. + Meaning: A client sends a uname/pwd-combination to a specific URL resource and receives a plain True or False (200/403 status codes?) if the combination matches. This way, no password string is sent out via the API.
Things to discuss or consider:
1.) How is the password stored in MMs internal db? (plaintext or hashed? if hashed, which algorithm is used?) 2.) (How) should the pwd be encrypted when sent to the API (depends on 1.)? 3.) Should this API resource be limited to requests from localhost and/or via SSL?
** Changed in: mailman Milestone: None => 3.0.0b1
** Changed in: mailman Status: New => Confirmed
** Changed in: mailman Importance: Undecided => High
** Changed in: mailman Assignee: (unassigned) => Barry Warsaw (barry)
** Changed in: mailman Milestone: 3.0.0b1 => postponed
I'm actually going to close this as Fix Committed. Here's what you can do; if this is insufficient, please reopen this bug (although it may indeed get postponed until after 3.0).
Let's say you're Postorius and someone has just typed their email address and password. You GET this resource:
http://localhost:9001/3.0/users/anne@example.com
Dig out the `password` attribute in the json. Now, you are armed with the encoded-hashed password of the user, and the cleartext password they typed into the form. You then use this Python code to do the verification:
from flufl.password import verify if verify(json_password, typed_password): # The user successfully logged in.
See http://packages.python.org/flufl.password/docs/using.html#verifying-a-passwo... for details.
** Changed in: mailman Milestone: postponed => 3.0.0b2
** Changed in: mailman Status: Confirmed => Fix Committed
** Changed in: mailman Status: Fix Committed => Fix Released
Oops, actually the above has been available for a while now, so it's Fixed Released.
-
Barry Warsaw -
Florian Fuchs