-
Notifications
You must be signed in to change notification settings - Fork 44
Change Password flow #679
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
base: main
Are you sure you want to change the base?
Change Password flow #679
Conversation
|
📦 build.zip [updated at Apr 25, 5:59:44 PM UTC] |
b6e3d67 to
40a057b
Compare
|
New change password flow allows to create a password without warnings/checks for password strength. May be it is worth adding there too |
185e2db to
252f660
Compare
| ...props | ||
| }: React.InputHTMLAttributes<HTMLInputElement> & { customValidity: string }) { | ||
| const ref = useRef<HTMLInputElement>(null); | ||
| useLayoutEffect(() => { |
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.
Can we just use useCustomValidity?
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.
We can, but the point is to test the abstraction at a component level :)
| newPassword, | ||
| }); | ||
| }, | ||
| onSuccess: async () => { |
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.
do we need async 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 guess not!
| </VStack> | ||
| </VStack> | ||
| </label> | ||
| <label style={{ all: 'unset' }}> |
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.
Can we refactor all Unstyled*** components with this?
Not for this task, just interesting :)
| this.notificationWindow = notificationWindow; | ||
| this.wallet = new Wallet(TEMPORARY_ID, null, this.notificationWindow); | ||
| this.on('authenticated', () => { | ||
| // TODO: Call Account.writeCurrentUser() here, too? |
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 we do anything with this TODO?
| newCredentials: SessionCredentials; | ||
| }) { | ||
| const { mnemonic: encryptedMnemonic } = this.getFirstWallet(); | ||
| invariant(encryptedMnemonic, 'Must be a Mnemonic WalletContainer'); |
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 message just don't make sense to me... we have smth similar in static async restoreWalletContainer, however not that important :)
ebc9f36 to
5a0732f
Compare
Implement backup and restore mechanics
5a0732f to
9248c0c
Compare
| return super.getState(); | ||
| } | ||
|
|
||
| setState(...args: Parameters<Store<T>['setState']>) { |
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 we specify setState as async 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.
It wouldn't change the type though
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.
Yes! But will make it a bit more obvious :)
| ); | ||
| } | ||
| } | ||
| super.setState(...args); |
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.
As I can see here, we have both sync and async state updates. Can this cause the racecondition when sync updates will be called in one order, but async saves will be executed in another order which will cause incorrect state after store reload?
| user: PublicUser; | ||
| password: string; | ||
| }>): Promise<PublicUser | null> { | ||
| invariant(!this.account.isWriteLocked, 'Atomic operation in progress'); |
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.
shouldn't logout also be blocked while updating is in progress?
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.
Also it looks like we should lock all Account-write operations while update is in progress
| newCredentials: SessionCredentials; | ||
| }) { | ||
| await this.ready(); | ||
| console.log('reading', { id, credentials, state: this.getState() }); |
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.
remove?
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.
Looks dangerous to expose credentials :)
| private async encryptAndSave( | ||
| id: string, | ||
| encryptionKey: string, | ||
| credentials: Credentials, |
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.
do we need to pass all Credentials 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.
No, but it makes it more consistent with the other signatures. I think it's more proper to pass credentials, it's easier to abstract them this way
| await this.encryptAndSave(id, credentials, record); | ||
| } | ||
|
|
||
| async createBackup(id: string) { |
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.
what do you think about calling this param userId to make to purpose more clear?
| name: 'internal_error', | ||
| message: 'Atomic wallet update failed. Restore from backup failed.', | ||
| }); | ||
| throw new InternalBackupError(getError(error), { didRestore: false }); |
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.
Do we need this param for this Error? It looks like we only use it with didRestore: false
No description provided.