-
Notifications
You must be signed in to change notification settings - Fork 1
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
Improve password change scenario in lockscreen #1018
Improve password change scenario in lockscreen #1018
Conversation
798bc73
to
676fa01
Compare
676fa01
to
1924a64
Compare
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.
Sorry I didn't realize that during dailies, but although this should work, after reading the code I'm not sure what's the advantage of doing this instead of directly doing the checkInputPassword
part?
My comprehension is the following:
Seems like all "good" scenario will call /settings/passphrase/check
with the password input
If entered password is good, then /settings/passphrase/check
is called with the cached password, but as it must be the same as the entered password, this is equivalent to calling it with the entered password. Then onSuccess()
is called
If the entered password is good but cache is obsolete, then we end up calling /settings/passphrase/check
with entered password. Then onSuccess()
is called
If the entered password is bad, then badUnlockPassword
is returned whatever if the cached password is bad, or if the input password is bad. So there seems to be no distinction for the user. The only one is that if bad password is entered then 2 http requests are made instead of one.
So would it be simpler if you directly call /settings/passphrase/check
only 1 time with input password? And then:
- if 200 and
hashedInputPassword.passwordHash === storedHash
->onSuccess()
- if 200 and
hashedInputPassword.passwordHash !== storedHash
-> updatCache +onSuccess()
- if 403 ->
onFailure(errors.badUnlockPassword)
- else ->
onFailure(errors.serverError)
oronFailure(errors.unknown_error)
I think this would output the same result so unit tests would still be green without any change.
However this PR should work so feel free to merge it
await removeVaultInformation('passwordHash') | ||
await saveVaultInformation('passwordHash', hashedInputPassword.passwordHash) |
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 seems to be redundant with the updateCachedPassword()
content that is called just after this method on line 84
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.
updated
1924a64
to
1c2b0df
Compare
This pull request includes changes to the
validatePassword
function in the lockscreen feature. The function now handles several scenarios, including successful validation with cached password, successful validation with user input password, invalid cached password and invalid user input, unexpected server errors, errors in the success handler, and network or communication errors. These changes improve the overall user experience and ensure that the lockscreen feature is more reliable and secure.