Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Catch exceptions when encrypting events #137

Merged
merged 2 commits into from
Jun 9, 2016
Merged

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Jun 9, 2016

If an exception was thrown by the encryption process, the event would be queued, but the exception would not be handled. This meant that the event got stuck as a grey 'sending' event in the UI.

Fixing this correctly is slightly more complex than just handling the exception correctly. A naive approach would mean that the event would be shown as a red 'unsent' message, and clicking 'resend' would then send the message in the clear. Hence, move the encryption to _sendEvent, where it will be called again
when the event is resent.

If an exception was thrown by the encryption process, the event would be
queued, but the exception would not be handled. This meant that the event got
stuck as a grey 'sending' event in the UI.

Fixing this correctly is slightly more complex than just handling the exception
correctly. A naive approach would mean that the event would be shown as a red
'unsent' message, and clicking 'resend' would then send the message *in the
clear*. Hence, move the encryption to _sendEvent, where it will be called again
when the event is resent.
if (!e2eRoomInfo || !e2eRoomInfo.algorithm) {
// not encrypting messages in this room
return;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be wise to wrap up these two 'are we encrypting this room' checks into a single function that will be the same one you can to determine whether there's a padlock or whatever displayed in the room. These two checks make me wonder how easy it would be to show a room as being encrypted and then accidentally end up without a sessionStore which here would cause the message to be sent in the clear.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. There are some more changes afoot, which move the is-the-room-being-encrypted configuration out of the sessionstore and into the room state, which will make this look a bit different anyway. I think I'll leave this for now.

@dbkr
Copy link
Member

dbkr commented Jun 9, 2016

otherwise lgtm

@dbkr dbkr assigned richvdh and unassigned dbkr Jun 9, 2016
@richvdh richvdh merged commit 53b9154 into develop Jun 9, 2016
@richvdh richvdh deleted the rav/encrypt_exceptions branch June 9, 2016 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants