* Process all verification event
* Add test for `isVerificationEvent`
* Review changes
* Remove null comparison and add doc to remote echo
* review changes
* Ensure we don't overinflate the total notification count
By correctly comparing push rules before & after decryption
* DRY the code
* Testsssss
* Update tests
* stub backupmanager
* Implement `CryptoApi.getActiveSessionBackupVersion`
* Revert unnecessary change
we can do this later, once we have better test coverage
* more test coverage
---------
Co-authored-by: Richard van der Hoff <richard@matrix.org>
These tests have broken on Node.js 18.17.0.
This is due to Node.js adopting an updated version of the URL parser, in which
the internal `Symbol(query)` property is populated lazily.
We shouldn't be relying on the internal state of the URL object anyway. Let's
just compare the stringified copy.
* Ensure non-thread relations to a thread root are actually in both timelines
* Make thread in sendReceipt & sendReadReceipt explicit rather than guessing it
* Apply suggestions from code review
* Fix Room::eventShouldLiveIn to better match Synapse to diverging ideas of notifications
* Update read receipt sending behaviour to align with Synapse
* Fix tests
* Fix thread rel type
* Simple request logging with status and duration
* remove url params from logs
* superfluous toString()
* Add tests
* Apply suggestions from code review
* update snapshots
* update log format
* Apply suggestions from code review
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* update snapshot
---------
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <richard@matrix.org>
* Offer `m.qr_code.scan.v1` verification method by default
Normally, the application specifies the supported verification methods when
creating the MatrixClient (and matrix-react-sdk does so). If the application
leaves it unset, then the idea is that the js-sdk offers all known verification
methods.
However, by default, the rust-sdk doesn't specify `m.qr_code.scan.v1`. So
basically, we need to set our own list of supported methods, rather than
relying on the rust-sdk's defaults.
* Factor out base class from `RustSASVerifier`
* Implement QR code scanning
* Update src/rust-crypto/verification.ts
* use oidc-client-ts during oidc discovery
* export new type for auth config
* deprecate generateAuthorizationUrl in favour of generateOidcAuthorizationUrl
* testing util for oidc configurations
* test generateOidcAuthorizationUrl
* lint
* test discovery
* dont pass whole client wellknown to oidc validation funcs
* add nonce
* use oidc-client-ts for oidc response
* validate user state and update tests
* use oidc-client-ts for code exchange
* use oidc-client-ts in completing auth grant
* use client userState for homeserver
* more comments
* use oidc-client-ts during oidc discovery
* export new type for auth config
* deprecate generateAuthorizationUrl in favour of generateOidcAuthorizationUrl
* testing util for oidc configurations
* test generateOidcAuthorizationUrl
* lint
* test discovery
* dont pass whole client wellknown to oidc validation funcs
* add nonce
* use client userState for homeserver
* implement `VerificationRequest.pending`
* Implement `VerificationRequest.timeout`
* Rust crypto: allow using a memory store (#3536)
* Rust crypto: allow using a memory store
It turns out that, for some usecases (in particular, "bot users" for cypress
tests), we don't need persistent storage and an in-memory store will be fine.
* Rust crypto: use a memory store for the unit tests
* Pass `supportedVerificationMethods` into `VerificationRequest`
... so that the application can later call `accept()` and we know what to send.
* Implement `VerificationRequest.accept`
* Implement `VerificationRequest.declining`
* Update src/rust-crypto/verification.ts
* integ tests: factor out some utility methods
* Add `VerificationRequest.startVerification` to replace `beginKeyVerification`
The rust SDK ties together creating the verifier and sending the
`m.key.verification.start` message, so we need to combine
`.beginKeyVerification` and `.verify`.
* add some unit tests
* utils for authorization step in OIDC code grant
* tidy
* completeAuthorizationCodeGrant util functions
* response_mode=query
* add scope to bearertoken type
* add is_guest to whoami response type
* doc comments
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* use shimmed TextEncoder
* fetchMockJest -> fetchMock
* comment
* bearertokenresponse
* test for lowercase bearer
* handle lowercase token_type
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Return uploaded keys from `/keys/query`
* Basic implementation of SAS verification in Rust
* Update the `verifier` *before* emitting `erificationRequestEvent.Change`
* remove dead code
A couple of tests were waiting for a request that wasn't happening, so timing
out after 1.5 seconds. Let's avoid the extra slowth.
(This was introduced by changes in
https://github.com/matrix-org/matrix-js-sdk/pull/3487, but the changes in this
PR do no harm anyway)
* Element-R: wait for OlmMachine on startup
Previously, if you called `CryptoApi.getUserDeviceInfo()` before the first
`/sync` request happened, it would return an empty list, which made a bunch of
the tests racy. Add a hack to get the OlmMachine to think about its device
lists during startup.
* add a test
* validate m.authentication, fetch issuer wellknown
* move validation functions into separate file
* test validateWellKnownAuthentication
* test validateOIDCIssuerWellKnown
* add authentication cases to autodiscovery tests
* test invalid authentication config on wk
* improve types
* test case for account:false
* use hasOwnProperty in validateWellKnownAuthentication
* comments
* make registration_endpoint optional