Opt In Overwrite #13
Opt In Overwrite #13
Conversation
bh2smith
force-pushed
the
opt-in-overwrite
branch
from
def079a to
41da6a0
Compare
| #[near_bindgen] | ||
| impl EthKeys { | ||
| // Sets the encrypted key for the sender's account. | ||
| pub fn set_key(&mut self, encrypted_key: String) { | ||
| pub fn set_key(&mut self, encrypted_key: String, overwrite: bool) { | ||
| // TODO - would be nice if there was some way to validate | ||
| // that the encrypted key actualy contains expected data. | ||
| let account_id = env::signer_account_id(); |
There was a problem hiding this comment.
There are nuances around signer_account_id and predecessor_account_id, I would have to verify, but this way a rogue smart contract might be able to set a new key for a user. It's also common practice to require a yoctoNEAR deposit, which can only be done using FullAccessKeys, but not with FunctionCallKeys.
There was a problem hiding this comment.
Very interesting. Thanks. I was under the impression that the yoco deposit would be a separate change that would also have to make the function payable. I had captured this in issue #2. However, your comment seems to mean two different things here (something about how other accounts can overwrite other's keys)... Are these two different things, or does having attached deposit somehow prevent this?
There was a problem hiding this comment.
#2 covers everything, except the signer/predecessor. Most of this comment is just information about NEAR smart contracts and common practices.
There was a problem hiding this comment.
Sounds a bit like the analogue of sender vs something else when contracts make delegate calls to others. So then would you say it's "approved"?
There was a problem hiding this comment.
Left a comment on #2, I think it's better addressed there.
To protect users from overwriting their key, we have a boolean-flag (overwrite) which must be set to true to overwrite values.
Closes #5.
Adjusted Rust Tests.