Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Address inputs in non edit mode should accept addresses #3008

Closed
chevdor opened this issue Oct 31, 2016 · 5 comments · Fixed by #3071
Closed

Address inputs in non edit mode should accept addresses #3008

chevdor opened this issue Oct 31, 2016 · 5 comments · Fixed by #3071
Assignees
Labels
F1-security 🛡 The client fails to follow expected, security-sensitive, behaviour.
Milestone

Comments

@chevdor
Copy link

chevdor commented Oct 31, 2016

Warning: The following issue can lead to disasters for normal users.
Disaster = unexpected replacement of the address they typed by 0x0 and of contracts with 0x0 instead of the address they intended.

The address input has 2 modes:

  • edit (we can type 0x124...)
  • search (we can type Bob and search for the account called Bob...)

In various places, I noticed that the mode is set by default to either edit or search depending on the context. That´s fine.

I would propose the following:

  • if the address input component is in 'search' mode
  • and if the user type in a valid address that is not matching a known account
  • then switch for the user to the 'edit' mode

Not doing so is confusing for the user who types a valid address.
The user would see the following:
screen shot 2016-10-31 at 13 04 17
which looks OK for normal users.

However, since we are in 'search' mode and the address is a good one but not in the list of know addresses, the address that will be used when calling the contract will not be the one the user sees, but 0x0 instead.

@gavofyork
Copy link
Contributor

...or just ensure that if the name isn't found in search mode then the action cannot happen.

@gavofyork gavofyork added F1-security 🛡 The client fails to follow expected, security-sensitive, behaviour. M6-ui labels Oct 31, 2016
@gavofyork gavofyork added this to the 1.4 Civility milestone Oct 31, 2016
@derhuerst
Copy link
Contributor

derhuerst commented Oct 31, 2016

...or just ensure that if the name isn't found in search mode then the action cannot happen.

and (in search mode) render it as invalid input.

@jacogr jacogr changed the title UI: Address inputs in non edit mode should accept addresses Address inputs in non edit mode should accept addresses Oct 31, 2016
@derhuerst
Copy link
Contributor

An invalid name is already being rejected, if you selected a name before. If you didn't it doesn't invalidate.

@chevdor
Copy link
Author

chevdor commented Oct 31, 2016

I just tested the current version and I find it totally confusing. If this is in progress, ignore my comment.

Don´t get me wrong, I do understand the difference between the edit and search mode but the visual difference is small for a regular user and the current implementation will lead to friction.

Currently, I am in search mode, I type a valid address, it can see it, and things fail with the message "A recipient network address...."

The good side of it obviously is that it probably (I did not double check) prevents 0x0 to be silently passed. The down side is that it remains totally confusing for the user: he types a valid address in an address input field and things fail.

@derhuerst
Copy link
Contributor

Currently, I am in search mode, I type a valid address, it can see it, and things fail with the message "A recipient network address...."

Cannot confirm.

What I can confirm though is that typing stuff into the input (in search mode) won't put it into the transaction.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F1-security 🛡 The client fails to follow expected, security-sensitive, behaviour.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants