Remove some we don't care about. Set some other ones we do care
about but don't currently adhere to to warn. Set the max warnings
threshold to the current number of warnings, so we don't introduce
more of them. Fix a bunch of legit lint errors and add exceptions
to various places in the test code that does funny things with
'this'.
If we have shared the session with a device which is subsequently blacklisted,
we need to start a new session for the next message.
Rather than doing this proactively (which would be subject to false-positives
and require slightly awkward tracking of who we had shared the session with),
we check the list of who we have shared the session with on each send, and
start a new session if any of them are blocked.
Fixes https://github.com/vector-im/riot-web/issues/2146.
Two main changes here:
* when we get an m.new_device event for a device we know about, ignore it
* Batch up the m.new_device events received during initialsync and spam out
all the queries at once.
Instead of trying to maintain a list of devices we need to share with, just
check all the devices for all the users on each send.
This should fix https://github.com/vector-im/vector-web/issues/2568, and
generally mean we're less likely to get out of sync.
We have decided that signing one-time keys is the lesser of two evils;
accordingly, use a new key algorithm type (`signed_curve25519`), sign the
one-time keys that we upload to the server, and verify the signatures on those
we download.
This will mean that develop won't be able to talk to master, but hey, we're in
beta.
Update a failing test to include user_id and device_id in the right place.
Remove one of the cases since it's somewhat redundant to
matrix-client-crypto-spec anyway.
Check that the user_id and device_id in device query responses match those that
we expect.
This resolves an unknown-key attack whereby Eve can re-sign Bob's keys with her
own key, thus getting Alice to send her messages which she can then forward to
Bob, making Bob think that Alice sent the messages to him.
Previously, the API for uploadContent differed wildly depending on whether you
were on a browser with XMLHttpRequest or node.js with the HTTP system
library. This lead to great confusion, as well as making it hard to test the
browser behaviour.
The browser version expected a File, which could be sent straight to
XMLHttpRequest, whereas the node.js version expected an object with a `stream`
property. Now, we no longer recommend the `stream` property (though maintain it
for backwards compatibility) and instead expect the first argument to be the
thing to upload. To support the different ways of passing `type` and `name`,
they can now either be properties of the first argument (which will probably
suit browsers), or passed in as explicit `opts` (which will suit the node.js
users).
Even more crazily, the browser version returned the value of the `content_uri`
property of the result, while the node.js returned the raw JSON. Both flew in
the face of the convention of the js-sdk, which is to return the entire parsed
result object. Hence, add `rawResponse` and `onlyContentUri` options, which
grandfather in those behaviours.
* if getFilter fails for a filterId, null out the localStorage id and
redirect to the createFilter path
* add spec
* fix unit/matrix-client.spec.js http response not matching synapse
9e89e71e broke uploadContent, making it set 'json=true' on the request, so that
we would try to turn raw content into JSON. It also misguidedly set a
client-side timeout of 30s.
Fix that, and add some tests to check uploadContent works.
In mock-request: distinguish between an expectation (ExpectedRequest)
and an actual request (Request). Add support for checking the headers, and the
request options in general, to Request.
Changed my mind - it's a good idea to wait a short time before
sending a keepalive request: this will make sure we never
tightloop.
This also adds a 'RECONNECTING' state for when a sync request has
failed but there is no reason to suspect there is actually a
connectivity problem. This is necessary for the tests to be able
to advance the clock at the appropriate time, but could be nice
for clients. Add a breaking change changelog entry since
technically this is an API change that might break clients if they
were relying on 'SYNCING' always coming before 'ERROR' for some
reason.
* Go back to previous behaviour of continuing to emit ERROR states if it continues to fail
* Don't set a timer if the timeout is zero
* Change test to assert the continued-error behaviour, not exactly multiple syncs failing
* Update other tests to fail the keepalive requests where appropriate
