API: Provide endpoint(s) to request password-token
HTTP-Clients (schleuder-cli, schleuder-web) must be able to request a token for setting a new password. The API must provide an endpoint to do that.
The workflow shall be this:
- A person that wants an account enters their email-address in a form and clicks a button.
- The web-interface sends the request unauthenticated (because there's no account yet) to the API.
- The API uses the sent email-address to look up a subscription with a usable key.
- If it finds a key, it generates a token (or a link?) and sends that in an encrypted email to the email-address. It returns an positive response to the web interface.
- If it doesn't find a subscription for the email-address at all it returns an error to the web interface.
- If it finds a subscription but none with a usable key it returns a different error to the web interface (so the web interface can display a helpful message).
- The person receives and decrypts the email, copies the token into the web interface (or clicks the link).
- The web interfaces validates the token at the API.
- If that is successful, it presents the person a form to enter and save a new password.
- Or should the person receive a second email, which contains the new password as it was set by schleuder?
- The tokens should be valid only for a given time span (15 minutes?).
- Admins must be able to request a token for a different email-address than their own. List-admins must only be allowed to request a token for email-addresses that are subscribed to one of their admin-lists.
- Should admins receive the token (or link) via HTTP instead of via encrypted email? The request from the web interface to the API is authenticated with their admin-credentials, thus we don't need the proof that they can decrypt a message.
- How to protect against SPAM/DOS-attacks through repeated requests for new tokens against the API? We can't authenticate those requests because there's no account yet.
Edited by paz