-
Notifications
You must be signed in to change notification settings - Fork 92
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
dexc: change application password feature. #978
Conversation
2df9ec2
to
2a725e2
Compare
@chappjc Updated |
4959db8
to
9d326c8
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.
comment message of 9d326c8 maybe should change mutuable -> mutable
The behavior when you enter something wrong differs for these fields:
If you enter the wrong current app pass, the current and new are cleared, but the confirm new is not. If new and confirm are different, it errors but none are cleared. Maybe all should be cleared for any mistake or success?
Unrelated to this pr:
I had the simnet test fail once:
--- FAIL: TestResendPendingRequests (39.07s)
trade_simnet_test.go:823: [client 2] dcr balance change not in expected range 19.00000000 - 20.00000000, got 9.99993000
FAIL
exit status 1
FAIL decred.org/dcrdex/client/core 500.617s
And I see this as an error in client logs, but should maybe be a warning?
[ERR] WEB: max order estimation error: dcr wallet MaxOrder error: error getting network fee estimate: -32603: no bucket with the minimum required success percentage found
return err | ||
} | ||
// Update xcWallets' encrypted passwords. | ||
err = c.updateWalletsEncPW(oldCrypter, newCrypter) |
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.
An error here or below would be fairly devastating, since the password has already been changed, because presumably the wallet's encPW
updates are incomplete.
Ideally, this entire operation would be a db.DB
method performed using a single bbolt.Tx
, but since we are using the Store
method for the key params, that gets a little sloppy. This is a consequence of bad design on my part. The general purpose Store
and Get
methods are cheap and I'm already getting rid of them. I'm okay with this in the meantime. I plan to follow up quickly.
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.
👍
3aabdc6
to
f739e48
Compare
4f823e1
to
326eff0
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.
I had forgotten a pending review, sorry. Just a couple tiny nits, but it's working for me.
@chappjc updated |
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.
Tests well.
@buck54321 updated mate |
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.
One last thing, but looks great.
Needs a rebase after #985. |
@amassarwi I just rebased it. Sorry didn't see your comment |
@chappjc all good, thank you |
Closes #678