Skip to content
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

[DDW-926] Improve error handling for incorrect passphrase / incorrect hardware wallet device #2860

Merged
merged 34 commits into from May 12, 2022

Conversation

marcin-mazurek
Copy link
Contributor

@marcin-mazurek marcin-mazurek commented Feb 4, 2022

This PR improves error handling in scenarios when user provides an incorrect passphrase (different than the one provided while pairing the wallet) or uses an incorrect wallet (in case the user has multiple wallets from the same manufacturer).

Screenshots

Before

Screenshot 2022-02-10 at 12 40 37

After

Screenshot 2022-02-11 at 15 27 28
Screenshot 2022-02-11 at 15 27 58

Testing Checklist

Testing scenarios:

No passphrase provided while pairing, non-empty passphrase provided on making transaction

1. Restart Daedalus
2. Pair a Trezor wallet with no passphrase
3. Try to make a transaction (regular transfer or delegation), provide passphrase abc
4. You should see the new error message
5. Press back
6. Try to make a transaction with no passphrase
7. The transaction should succeed

Then try the same once again, without restarting Daedalus.

Non-empty passphrase provided while pairing, no passphrase provided on making transaction

1. Restart Daedalus
2. Pair a Trezor wallet with passphrase abc
3. Try to make a transaction (regular transfer or delegation), provide empty passphrase
4. You should see the new error message
5. Press back
6. Try to make a transaction with passphrase abc
7. The transaction should succeed

Then try the same once again, without restarting Daedalus.

Passphrase provided while pairing, different passphrase provided on making transaction

1. Restart Daedalus
2. Pair a Trezor wallet with passphrase xyz
3. Try to make a transaction (regular transfer or delegation), provide passphrase abc
4. You should see the new error message
5. Press back
6. Try to make a transaction with passphrase xyz
7. The transaction should succeed

Then try the same once again, without restarting Daedalus.

Ledger wallet paired using standard PIN, transaction made with hidden PIN

1. Pair a Ledger wallet with standard PIN
2. Set up a hidden passphrase wallet on Ledger Nano if you haven't done that yet (https://www.youtube.com/watch?v=RJzSQtGVaA0)
3. Try to make a transaction (regular transfer or delegation) using hidden PIN
4. You should see the new error message

Ledger wallet paired using hidden PIN, transaction made with standard PIN

1. Set up a hidden passphrase wallet on Ledger Nano if you haven't done that yet (https://www.youtube.com/watch?v=RJzSQtGVaA0)
2. Pair a Ledger wallet with hidden PIN
3. Try to make a transaction (regular transfer or delegation) using standard PIN
4. You should see the new error message

Ledger S paired but Ledger X used for transaction

1. Pair a Ledger S wallet
2. Unplug and plug Ledger X wallet instead
3. Try to make a transaction 
4. You should see the new error message
5. Connect the right device
6. Try to make the transaction
7. It should succeed

Ledger X paired but Ledger S used for transaction

1. Pair a Ledger X wallet
2. Unplug and plug Ledger S wallet instead
3. Try to make a transaction 
4. You should see the new error message
5. Connect the right device
6. Try to make the transaction
7. It should succeed

Pairing two Trezor wallets one by one and making transactions

1. Pair a Trezor wallet with passphrase abc
2. Make a transaction with that wallet
3. Pair a Trezor wallet with passphrase def
4. Make a transaction with that wallet
9. Make a transaction with previous wallet
10. You should not see the new error message at any point, all transactions should succeed

Hints: always test on clean state folder, also try to do some transactions after pairing, before making the transaction which should produce the new error.


Review Checklist

Basics

  • PR assigned to the PR author(s)
  • input-output-hk/daedalus-dev and input-output-hk/daedalus-qa assigned as PR reviewers
  • If there are UI changes, Alexander Rukin assigned as an additional reviewer
  • All visual regression testing has been reviewed (assign run Chromatic label to PR to trigger the run)
  • PR has appropriate labels (release-vNext, feature/bug/chore, WIP)
  • PR link is added to a Jira ticket, ticket moved to In Review
  • PR is updated to the most recent version of the target branch (and there are no conflicts)
  • PR has a good description that summarizes all changes
  • PR contains screenshots (in case of UI changes)
  • CHANGELOG entry has been added to the top of the appropriate section (Features, Fixes, Chores) and is linked to the correct PR on GitHub
  • There are no missing translations (running yarn manage:translations produces no changes)
  • Text changes are proofread and approved (Jane Wild / Amy Reeve)
  • Japanese text changes are proofread and approved (Junko Oda)
  • Storybook works and no stories are broken (yarn storybook)
  • In case of dependency changes yarn.lock file is updated

Code Quality

  • Important parts of the code are properly commented and documented
  • Code is properly typed with typescript types
  • React components are split-up enough to avoid unnecessary re-renderings
  • Any code that only works in main process is neatly separated from components

Testing

  • New feature/change is covered by acceptance tests
  • New feature/change is manually tested and approved by QA team
  • All existing acceptance tests are still up-to-date
  • New feature/change is covered by Daedalus Testing scenario
  • All existing Daedalus Testing scenarios are still up-to-date

After Review

  • Update Slack QA thread by marking it with a green checkmark

Copy link
Contributor

@tomislavhoracek tomislavhoracek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcin-mazurek I left a few comments/explanations. Please take a look!

@marcin-mazurek marcin-mazurek removed the WIP label Feb 8, 2022
@marcin-mazurek marcin-mazurek self-assigned this Feb 8, 2022
@marcin-mazurek marcin-mazurek changed the title [DDW-926] Improve Trezor error handling for incorrect passphrase [DDW-926] Improve error handling for incorrect passphrase / incorrect hardware wallet device Feb 8, 2022
@@ -49,6 +49,12 @@ const messages = defineMessages({
defaultMessage: '!!!Exporting the public key failed',
description: '"Exporting public key failed" device state',
},
unrecognized_wallet: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be camel case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, I followed the existing pattern where we map the HwDeviceStatus enum values directly to translations. The enum uses snake_case therefore we have this mapping which doesn't follow JavaScript naming conventions. Would you like me to refactor this? I would have to introduce an additional map to map statuses to translation keys.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok, sounds good.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about using lodash's camelCase for mapping enum values to translations? This way we could kill two birds with one stone. (btw it is a funny sentence)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would work, however I'm afraid that it will make it harder to refactor and track which translations are actually in use. Currently you can just find translations by a string, with camelCase function it's not going to be that easy anymore.

@alexander-rukin
Copy link
Contributor

alexander-rukin commented Feb 9, 2022

can we center "x" icon?)

image

@marcin-mazurek
Copy link
Contributor Author

@alexander-rukin I've uploaded the latest screenshots. The issue is no longer visible:
Screenshot 2022-02-10 at 12 47 04

@marcin-mazurek
Copy link
Contributor Author

@tomislavhoracek please re-review :)

Copy link
Contributor

@tomislavhoracek tomislavhoracek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcin-mazurek AMAZING!!! 💯

Copy link
Contributor

@alexander-rukin alexander-rukin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

path: devicePath,
},
});
deviceFeatures = await TrezorConnect.getFeatures();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ManusMcCole
Copy link

ManusMcCole commented Mar 21, 2022

Hi @marcin-mazurek. I can confirm that the error handling is working for Trezor now 👍. However there is one scenario where the new correct error message is not shown

When a wallet is setup with a passphrase and when user is prompted for the passphrase and enters an empty(blank) passphrase the old message "Disconnect and reconnect your hardware wallet to restart the process" appears. Any other incorrect passphrase that isnt blank triggers the correct message Screenshot

@marcin-mazurek
Copy link
Contributor Author

marcin-mazurek commented Mar 24, 2022

@gabriela-ponce You actually came across two issues.

First issue (DDW-970) is related to incorrect logic in address verification, which @szymonmaslowski is addressing in this PR: #2906.

Second issue is with Daedalus losing track of Ledger USB path - anytime you see the "Cannot open device with path..." error, that isn't an issue with logic for a particular action - it's an issue related to Ledger connectivity implementation and unfortunately may happen at various points while interacting with Ledger wallet. Currently @renanvalentin is heavily changing the way we handle Ledger USB paths in this PR: #2900. Hopefully when his piece of work is finalized and merged, we should no longer experience those path issues. For now, when you get an issue like this one: https://drive.google.com/file/d/1a48WtwdQaX71QDfuZ13wY73QB0jJ8ucy/view (or like the ones reported by @ManusMcCole here - #2860 (comment)) - the only workaround is to unplug the device and plug it again, then retry.

@ManusMcCole could you please re-test Trezor scenarios again? I've extended the error handling further to account for cases you've found, but this increases the risk and it would be good to do a full hardware wallet regression test before we ship this.

…rrent wallet ID does not match device wallet ID
@marcin-mazurek marcin-mazurek force-pushed the fix/ddw-926-trezor-error-handling branch from 03c32cd to 68fa148 Compare March 24, 2022 23:31
@ManusMcCole
Copy link

Hi @marcin-mazurek. I have completed another round of testing.Tested on build 21375 on Mac OS. I found one scenario where a correct passphrase was not accepted

Pair a wallet with a passphrase. Initiate transaction. Insert Incorrect passphrase. Correct message "We do not recognise this wallet on your device" pops up.Press Back.Press Send again.Insert Correct passphrase this time and it still is accepted as false and the "We do not recognise this wallet on your device" pops up again

For a passphrase protected wallet for some reason getting the passphrase wrong one time causes even the correct passphrase to fail in subsequent attempts

Wallet with a blank passphrase accepts correct passphrase after an incorrect one has been entered previously

@marcin-mazurek
Copy link
Contributor Author

@ManusMcCole this is ready for another round of review. I've added several more test cases to the PR description and executed them and they all seem to pass. Please re-check.

@ManusMcCole
Copy link

Hi Marcin. Here is the newest testing report for build 21659 Intel MacOS Testnet.Mostly all of the scenarios worked except when device is connected and unlocked after Send transaction has been initiated

There seems to be an issue for Ledger X for hidden pincode wallets when the device is only connected after Send is already selected for a transaction. Initiate a transaction then connect and unlock device. Even with a correct hidden pin entered a Transaction Confirmation failed error appears. Screenshot

For normal pincode wallets same scenario on Ledger X instead of the above error the device is not recognised after unlock(with correct or hidden pin entered) and continues to say "Connect the Ledger X device". Screenshot

My Ledger S device is currently not operational so this issue may also appear there too I was not currently able to test

@marcin-mazurek
Copy link
Contributor Author

Hey @ManusMcCole, please have a look at the latest build which includes #2900 which brought significant improvements for Ledger. In the latest build I'm not able to reproduce scenarios you've posted.

Copy link

@ManusMcCole ManusMcCole left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job @marcin-mazurek. Looks good 👍

@marcin-mazurek
Copy link
Contributor Author

marcin-mazurek commented May 12, 2022

Can't believe it 😱

Copy link
Contributor

@danielmain danielmain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job @marcin-mazurek !!! you can now rest in peace 😂

@danielmain danielmain merged commit 65d0800 into develop May 12, 2022
@danielmain danielmain deleted the fix/ddw-926-trezor-error-handling branch May 12, 2022 17:37
michalrus added a commit that referenced this pull request Jun 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants