This adds a step after login to complete security for your new session. At the
moment, the only verification method is entering your SSSS passphrase, but nicer
paths will be added soon.
This new step only appears when crypto is available and the account has
cross-signing enabled in SSSS.
Fixes https://github.com/vector-im/riot-web/issues/11214
This moves the details of dialogs that may be needed when accessing secret
storage to centralised helper. In addition, this clears the secret storage key
cache so that keys are only live for a single operation.
This adds dialogs for creating and accessing secret storage via a passphrase or
recovery key. These flows are adapted from the ones used for key backup.
This passes a callback to the JS SDK which it can use to get IS access tokens
whenever needed for either talking to the IS directly or passing along to the
HS.
Fixes https://github.com/vector-im/riot-web/issues/10525
https://github.com/matrix-org/matrix-react-sdk/pull/3101 meant we
don't get logged straight in after registering if using an email
address, but this was the point at which we made a chat with the
welcome user. Instead, set a flag in memory that we should try &
make a chat with the welcome user for that user ID if we get a
session for them.
Of course, if the user logs in on both tabs, this would mean each
would make a chat with the welcome user (although actually this
was a problem with the old code too). Check our m.direct to see if
we've started a chat with the welcome user before making one (which
also means we have to make sure the cached sync is up to date...
see comments).
https://github.com/matrix-org/matrix-react-sdk/pull/2826 checked
that we had data in the crypto store if the had credentials in
localStorage. However, SSO stores creds in localStorage and then
redirects the browser to remove the loginToken parameter from the
URL without starting crypto, so after the redirect, we see creds
in localStorage but no crypto data, and error.
Fix by marking when we've successfully initialised crypto and only
erroring if that flag is set.
Fixes https://github.com/vector-im/riot-web/issues/9695
This watches the `IndexedDBStore` in case it degrades. If it does, we track this
in analytics so we can observe how often it happens in the field.
Should help track errors like https://github.com/vector-im/riot-web/issues/7769
To try & diagnose https://github.com/vector-im/riot-web/issues/7769
Null check on e before looking for the `name` property and log it
separately rather than appending it to a string (not that this will
help if it's undefined, but it's more useful in general).
`createMatrixClient` and surrounding paths support an argument to disable
IndexedDB, but it is never actually used. This removes the option to simplify
the code.
This implements a dream of one day being able to listen for changes in a settings to react to them, regardless of which device actually changed the setting. The use case for this kind of thing is extremely limited, but when it is needed it should be more than powerful enough.
In making the settings more positive, we flipped 'disable peer to
peer' but didn't change the caption, so the setting was inverted
from what it was labelled as.
Also, forcing p2p isn't the inverse of forcing turn.
Change the setting to be 'allow p2p' and the label to match.
Fixes https://github.com/vector-im/riot-web/issues/6435
This is done through an on-the-fly inverter for the settings. All the settings changed are boolean values, so this should be more than safe to just let happen throughout the SettingsStore. Typically a change like this would be done in the individual handlers (similar to how setting names are remapped to different properties or even different storage locations on the fly), however doing that for this many settings would be a huge nightmare and involve changing *all* the layers. By putting a global "invert this" flag on the setting, we can get away with doing the inversion as the last possible step during a read (or write).
To speed up calculations of the default values, we cache all the inverted values into a lookup table similar to how we represent the defaults already. Without this, the DefaultHandler would need to iterate the setting list and invert the values, slowing things down over time. We invert the value up front so we can keep the generic inversion logic without checking the level ahead of time. It is fully intended that a default value represents the new setting name, not the legacy name.
This commit also includes a debugger for settings because it was hard to visualize what the SettingsStore was doing during development. Some added information is included as it may be helpful for when someone has a problem with their settings and we need to debug it. Typically the debugger would be run in conjunction with `mxSendRageshake`: `mxSettingsStore.debugSetting('showJoinLeaves') && mxSendRageshake('Debugging showJoinLeaves setting')`.
If we can't start indexeddb, fall back to a different store.
Previously we just ignored the exception and ploughed on anyway, on
the assumption that startup() was just for the indexeddb store to
load data anyway, and if that failed it would just do an initial
/sync instead (and also we'd keep trying to save the sync back which
would fail...). Then, in the previous release we started pulling
the settings out of the store on startup, making the assumpton that
the store actually worked, so the read obviously failed and the app
failed to start up.
This makes Riot work in Tor browser / firefox in daft mode again.
As we need an option to turn lazy loading on (we can't just accept a filter,
as /messages has an incompatible filter), better only pass the option
and create the filter inside startClient
