-
Notifications
You must be signed in to change notification settings - Fork 45
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
Persist state and sync between tabs #975
Conversation
🦙 MegaLinter status: ✅ SUCCESS
See errors details in artifact MegaLinter reports on CI Job page |
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.
reading about how this works
return encryptedString | ||
} | ||
|
||
export async function decryptWithPassword<T>(password: string, encryptedString: EncryptedString): Promise<T> { |
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.
on the surface level it's an awkward asymmetry with encryptWithKey
, but deeper down, it really would make a lot of sense to expose a decryptWithKey
instead. the only callsite other than in tests pairs it up with another deriveKeyFromPassword
, because it also needs the key itself (foreshadowed by encryptWithKey
to save any updates will the key). the password-to-key derivation being something that's supposed to be expensive, it would be nice not to have to do it twice
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 don't understand :D
A subset of the comment: true, we could avoid deriveKeyFromPassword
(with a new random salt) in decryptState
(on unlock) by returning derivedKeyWithSalt
(with old salt) from decryptWithPassword
. Seems safe
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.
ya I guess, if you prefer to couple the derivation and decryption into one call
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.
security review: we'd be fine using the same salt, as the password is still the same. I'm not aware of any problems with changing it every time either though
2673f2c
to
a11f453
Compare
8cbc6b0
to
ce527a5
Compare
I temporarily deployed it to https://lukaw3d.github.io/oasis-wallet-web/ce527a5/#/ |
Great work @lukaw3d 🎉 |
Hi @lukaw3d - the flow works pretty well! I think it is a good first version - we can later iterate on it and improve it over time (e.g. by adding "remove-account" options etc). There is this minor thing I found: It should be an easy fix. Thanks! |
This comment was marked as resolved.
This comment was marked as resolved.
That was intentional so users can get back to login screen after clicking "Continue without the profile" (without it: user would need to create a wallet to get that same button) |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Fixing 1. is annoying
|
This comment was marked as resolved.
This comment was marked as resolved.
<Button | ||
label={t('persist.loginToProfile.skipUnlocking', 'Continue without the profile')} | ||
onClick={() => { | ||
navigate('/') |
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.
Is this redirect needed? when I open /account/oasis1..
I would expect that continue
will allow me to see acc details.
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.
Good UX question. I've been considering the skipped profile like incognito mode, not read-only profile.
- Against:
- We've removed search for foreign accounts, so read-only view is barely supported.
- I was considering removing remove account ID from URL. To have fewer sources of state. That would also increase privacy - after locking wallet, someone couldn't check browser history (or click skip) to get your address.
- For:
- Would allow wallet owner to quickly get their account's address. Pre-redirect URL might not be locked account (open a foreign account URL from bookmark and click skip). More complex proposal is to have a wallet pin to unlock read-only, and only ask for password before signing transactions.
- Would allow quickly viewing foreign account's balance from URL/bookmark. But this is just worse search.
Fixes wrong selection when opening multiple wallets with persistence: - open 2 accounts from mnemonic - choose password - walletOpened(account0): ??= selects account0 - selectWallet(undefined) and begin delay(1), selectWallet(account0) - walletOpened(account1): ??= selects account1 - setPasswordAsync begins encrypting, decrypting, and setUnlockedRootState - delay(1) ends, selectWallet(account0) - encrypting, decrypting, and setUnlockedRootState ends with account1
|
||
const tab2 = await context.newPage() | ||
await tab2.goto('/') | ||
await expect(tab2.getByRole('button', { name: 'Unlock' })).toBeHidden() |
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.
This is failing on CI, but not locally
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 haven't found a reason why it matches differently on CI, only fixed it with 77be857.
await expect(tab2.getByRole('button', { name: 'Unlock' })).toBeHidden()
on CI matched
<a aria-label="Open wallet">
<button tabindex="-1">
<div>
<svg aria-label="Unlock">..</svg>
Open wallet
</
Wait for tabs to sync, and only skipUnlocking if tabs don't sync. ValidatorList test relied on skipUnlocking being called immediately and triggering selectNetwork.
Hello, Is there any info when will this be published? |
@iSQL I'm not sure. We'll want to deploy it after we move wallet to a new domain (so there's no confusion about saved data on current domain) and perhaps finish more of #792 (comment) |
Reverts part of c125984 and re-fixes #975 (comment) Instead of waiting for tabs to be synced before selecting network initially: - initialize selecting network without syncing that action - using takeLatest cancel initialization task if tabs sync during selectNetwork
Reverts part of c125984 and re-fixes #975 (comment) Instead of waiting for tabs to be synced before selecting network initially: - initialize selecting network without syncing that action - using takeLatest cancel initialization task if tabs sync during selectNetwork
Reverts part of c125984 and re-fixes #975 (comment) Instead of waiting for tabs to be synced before selecting network initially: - initialize selecting network without syncing that action - using takeLatest cancel initialization task if tabs sync during selectNetwork
Reverts part of c125984 and re-fixes #975 (comment) Instead of waiting for tabs to be synced before selecting network initially: - initialize selecting network without syncing that action - using takeLatest cancel initialization task if tabs sync during selectNetwork
@iSQL it is finally published |
Part of #792
Temporarily deployed to https://lukaw3d.github.io/oasis-wallet-web/ce527a5/#/Updated deploy https://lukaw3d.github.io/oasis-wallet-web/32fbe2b/#/
Old preview of 22369e0
Preview of ce527a5
TODO
open account in two tabs http://localhost:3000/account/oasis1qzwl8nn8lt8cv4gxh85skv9rw3h0raudws66q4y5
navigate to home on one tab (dispatches clearAccount)
other tab loses data and shows loading
always show unlock modal and
if profile: on unlock emit setUnlockedRootState
if profile: on skip emit event like setUnlockedRootState to use in networkSaga
if no profile: auto click skip login emit event like setUnlockedRootState to use in networkSaga
Deferred and moved to issue: