Handle incoming identity key changes

This ended up turning into a rewrite/refactor of the background page.
For best results, view this diff with `-w` to ignore whitespace. In
order to support retrying message decryption, possibly at a much later
time than the message is received, we now implement the following:

Each message is saved before it is decrypted. This generates a unique
message_id which is later used to update the database entry with the
message contents, or with any errors generated during processing.

When an IncomingIdentityKeyError occurs, we catch it and save it on the
model, then update the front end as usual. When the user clicks to
accept the new key, the error is replayed, which causes the message to
be decrypted and then passed to the background page for normal
processing.
This commit is contained in:
lilia 2014-12-19 16:49:18 -08:00
parent 5762e59c41
commit 9c736df7d0
3 changed files with 241 additions and 116 deletions

View file

@ -362,9 +362,17 @@ window.textsecure.protocol = function() {
});
}
var wipeIdentityAndTryMessageAgain = function(from, encodedMessage) {
//TODO: Wipe identity key!
return handlePreKeyWhisperMessage(from, encodedMessage);
var wipeIdentityAndTryMessageAgain = function(from, encodedMessage, message_id) {
// Wipe identity key!
textsecure.storage.removeEncrypted("devices" + from.split('.')[0]);
return handlePreKeyWhisperMessage(from, encodedMessage).then(
function(pushMessageContent) {
extension.trigger('message:decrypted', {
message_id : message_id,
data : pushMessageContent
});
}
);
}
textsecure.replay.registerFunction(wipeIdentityAndTryMessageAgain, textsecure.replay.Type.INIT_SESSION);