Make new_email POST request handler idempotent
#102
Comments
|
On Sat, Jan 28, 2023 at 17:10 -0800, link2xt wrote:
Currently if POST request succeeds, but connection fails before the client receives a response, an account is created but nobody will use it. In extreme case of one-use token (#89), this will result in making token unusable without creating an account on user device.
If the request was idempotent, user device could resend a POST request again and receive a password.
Currently the only parameter is `t`, the token. I propose to add another optional (for backwards compatibility) parameter, lets name it `i`, which contains a random string (token) generated by the client. If specified, it should be used to deterministically generate an username and a password, e.g. username = hash("username" + token + salt + `i` parameter), password = hash("password" + token + salt + `i` parameter). If mailbox already exists, return the response as if it was just successfully created, without even checking if the password is still the same.
Delta Chat will then be able to generate `i` parameter locally, save it in the context config and make as many POST requests as needed to actually get login + password and configure an account, even on a bad connection.
How is an unused row in a database a problem?
Idempotency here adds complexity on both mailadm and DC-side just to avoid
an empty unused account .... which should be pruned/expired anyway if nobody ever logged
in for some weeks and send or received a message.
|
The problem is that the number of accounts is increased, in case of one-time tokens it will hit max-use limit without anyone getting an account. Without |
|
The standard way is to have an There is a standard draft for this at https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/ and it is already implemented by APIs like https://stripe.com/docs/api/idempotent_requests With this implemented, Delta Chat could retry the same request for minutes or hours until it succeeds. If user is connected to some bad network when scanning QR code, they can then switch to another network and still get an account without having to rescan the QR code. |
|
Made a PR: #131 |
Currently if POST request succeeds, but connection fails before the client receives a response, an account is created but nobody will use it. In extreme case of one-use token (#89), this will result in making token unusable without creating an account on user device.
If the request was idempotent, user device could resend a POST request again and receive a password.
Currently the only parameter is
t, the token. I propose to add another optional (for backwards compatibility) parameter, lets name iti, which contains a random string (token) generated by the client. If specified, it should be used to deterministically generate an username and a password, e.g. username = hash("username" + token + salt +iparameter), password = hash("password" + token + salt +iparameter). If mailbox already exists, return the response as if it was just successfully created, without even checking if the password is still the same.Delta Chat will then be able to generate
iparameter locally, save it in the context config and make as many POST requests as needed to actually get login + password and configure an account, even on a bad connection.The text was updated successfully, but these errors were encountered: