| 2011-10-05 11:51:04 |
Florian Fuchs |
description |
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? |
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 (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? |
|
