Element Android reuses txnId for to-device events in the verification process #3589
Labels
Milestone
Comments
|
That's very good catch. We will have a look |
poljar
added a commit
to poljar/element-android
that referenced
this issue
Jul 20, 2021
Verification flows have something called a transaction id. This is a client-set custom ID that identifies the flow and is established by the first message that gets sent out. This transaction ID needs to be kept the same and be part of all events that are sent during the verification flow. To-device requests have something called a transaction id. This is a client-set custom ID that identifies a given request. It is used to ensure idempotency of requests, i.e. retrying to send a request won't result in two events being sent as long as the transaction id is kept the same. This patch removes usage of the first type of transaction ID for the second use-case. This closes: element-hq#3589.
poljar
added a commit
to poljar/element-android
that referenced
this issue
Jul 20, 2021
Verification flows have something called a transaction id. This is a client-set custom ID that identifies the flow and is established by the first message that gets sent out. This transaction ID needs to be kept the same and be part of all events that are sent during the verification flow. To-device requests have something called a transaction id. This is a client-set custom ID that identifies a given request. It is used to ensure idempotency of requests, i.e. retrying to send a request won't result in two events being sent as long as the transaction id is kept the same. This patch removes usage of the first type of transaction ID for the second use-case. This closes: element-hq#3589.
6 tasks
|
Should be fixed on develop and in Element Android 1.1.14. @timokoesters should be nice if you can confirm that! Thanks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are two types of transaction ids in the to-device verification process:
The txnId, which is a path parameter for the /sendToDevice request. As far as I understand, this should never be reused unless the previous try failed (https://spec.matrix.org/unstable/client-server-api/#put_matrixclientr0sendtodeviceeventtypetxnid).
Then there is a transaction_id field that is shared by the other messages of the verification session (https://spec.matrix.org/unstable/client-server-api/#key-verification-framework).
Element Android uses the same id for both txnId and transaction_id, so on Conduit most sendToDevice requests are dropped because the txnId was already used before. This is probably the reason for #3183
How to fix:
Only use the session's transaction_id for the transaction_id field of verification message contents. Generate a new id for the txnId of /sendToDevice requests.
The text was updated successfully, but these errors were encountered: