-
-
Notifications
You must be signed in to change notification settings - Fork 589
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
Element-R: implement cancellation of verification requests #3505
Conversation
2294b8f
to
96173bc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All comments are small ones, nothing blocking.
src/rust-crypto/verification.ts
Outdated
|
||
/** the method picked in the .start event */ | ||
public get chosenMethod(): string | null { | ||
const verification: RustSdkCryptoJs.Qr | RustSdkCryptoJs.Sas | undefined = this.inner.getVerification(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RustSdkCryptos.Qr | RustSdkCryptoJs.Sas | undefined
union appears a couple of times in this class. Do you think it would warrant becoming a type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly, though there's also an argument that it should be the rust-sdk's job to declare the type; or better yet, to define the return type of getVerification
correctly so that application code doesn't need to do this sort of annoying type assertion (but that's hard because of limitations in the rust tooling).
This code is actually from #3490, so I'll leave it alone for now, in any case. Will consider adding a type if I find myself writing another copy of the union.
src/rust-crypto/verification.ts
Outdated
}, | ||
confirm: async (): Promise<void> => { | ||
const requests: Array<OutgoingRequest> = await this.inner.confirm(); | ||
for (const m of requests) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a bone question. Why m
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
erm, good question. m for message, maybe? Though again, #3490 rather than new in this PR.
function onChange() { | ||
expect(request.phase).toEqual(VerificationPhase.Started); | ||
expect(request.otherPartySupportsMethod("m.sas.v1")).toBe(true); | ||
expect(request.chosenMethod).toEqual("m.sas.v1"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be toBe
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly? I'm not sure it makes any difference, or if there is any particluar convention here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was only asking as using toEqual
suggests to me some sort of object comparison is going on (comparing keys and values I mean) whereas toBe
suggests comparison of primitives. It makes no difference to the output here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we don't normally write method.is("m.sas.v1")
for doing string comparison, so I'm not convinced that toBe
is, in fact, more natural for string comparison.
Also, I come from a Python world, where you definitely need assertEqual
, and not assertIs
:
>>> a = "foo"
>>> a += "bar"
>>> b = "foobar"
>>> a == b
True
>>> a is b
False
// initially there should be no verifications in progress | ||
{ | ||
const requests = aliceClient.getCrypto()!.getVerificationRequestsToDeviceInProgress(TEST_USER_ID); | ||
expect(requests.length).toEqual(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a toHaveLength
matcher available if you prefer how that reads
1398ac0
to
85e0ddf
Compare
* The Browserify artifact is being deprecated, scheduled for removal in the October 10th release cycle. ([\matrix-org#3189](matrix-org#3189)). * ElementR: Add `CryptoApi#bootstrapSecretStorage` ([\matrix-org#3483](matrix-org#3483)). Contributed by @florianduros. * Deprecate `MatrixClient.findVerificationRequestDMInProgress`, `MatrixClient.getVerificationRequestsToDeviceInProgress`, and `MatrixClient.requestVerification`, in favour of methods in `CryptoApi`. ([\matrix-org#3474](matrix-org#3474)). * Introduce a new `Crypto.VerificationRequest` interface, and deprecate direct access to the old `VerificationRequest` class. Also deprecate some related classes that were exported from `src/crypto/verification/request/VerificationRequest` ([\matrix-org#3449](matrix-org#3449)). * OIDC: navigate to authorization endpoint ([\matrix-org#3499](matrix-org#3499)). Contributed by @kerryarchibald. * Support for interactive device verification in Element-R. ([\matrix-org#3505](matrix-org#3505)). * Support for interactive device verification in Element-R. ([\matrix-org#3508](matrix-org#3508)). * Support for interactive device verification in Element-R. ([\matrix-org#3490](matrix-org#3490)). Fixes element-hq/element-web#25316. * Element-R: Store cross signing keys in secret storage ([\matrix-org#3498](matrix-org#3498)). Contributed by @florianduros. * OIDC: add dynamic client registration util function ([\matrix-org#3481](matrix-org#3481)). Contributed by @kerryarchibald. * Add getLastUnthreadedReceiptFor utility to Thread delegating to the underlying Room ([\matrix-org#3493](matrix-org#3493)). * ElementR: Add `rust-crypto#createRecoveryKeyFromPassphrase` implementation ([\matrix-org#3472](matrix-org#3472)). Contributed by @florianduros. * Aggregate relations regardless of whether event fits into the timeline ([\matrix-org#3496](matrix-org#3496)). Fixes element-hq/element-web#25596. * Fix bug where switching media caused media in subsequent calls to fail ([\matrix-org#3489](matrix-org#3489)). * Fix: remove polls from room state on redaction ([\matrix-org#3475](matrix-org#3475)). Fixes element-hq/element-web#25573. Contributed by @kerryarchibald. * Fix export type `GeneratedSecretStorageKey` ([\matrix-org#3479](matrix-org#3479)). Contributed by @florianduros. * Close IDB database before deleting it to prevent spurious unexpected close errors ([\matrix-org#3478](matrix-org#3478)). Fixes element-hq/element-web#25597.
Based on #3504
The final part of element-hq/element-web#25319
Notes: Support for interactive device verification in Element-R.
Here's what your changelog entry will look like:
✨ Features