search

GetScatter / scatter-js

Importable JavaScript library that allows web applications to directly interface with Scatter Desktop, Classic and Mobile.
MIT License
262 stars 148 forks source link

Account missing error, but it (private and publicKey are in actually in Scatter) exists and used previously #141

Open techraed opened 5 years ago

techraed commented 5 years ago

I am trying to setcode to a newly created account by my baseAccount. I have made a tx with 2 actions: newaccount and buyrambytes. All these actions were performed by baseAccount. In account creation action I defined permissions such that it results in: newAccount active: baseAccount@active owner: baseAccount@owner

When I try to setcode to a newAccount (using newAccount as an authority), I expect that I can sign this tx with baseAccount@active. But scatter does not pop-up signing data, it, however, returns:

code: 402 isError: true message: "You are trying to sign a request with an account that isn't currently linked or doesn't exist in the user's Scatter" type: "account_missing"

Another fact is that I can actually sign this tx (setcode/setabi) with newAccount@active (before setcode tx I use linkAccount to link newly created account).

nsjames commented 5 years ago

So a few questions:

techraed commented 5 years ago

@nsjames

  1. Yeah, I could find a new account in Scatter after its creation.
  2. I add permissions within account creation transaction.
nsjames commented 5 years ago

Adding permissions to the transaction isn't enough. You'd need to log back in with the other account for Scatter to be able to sign with that account.

techraed commented 5 years ago

Alright... As far as I know, I can sign tx with base account if I have proper permissions over newAccount when using cleos. So, we treat such type of transactioning as normal, this behaviour is provided by EOSIO in general. It would be good if this behaviour was able in Scatter.

As a result, I am bounded to do things that are actually valid from EOSIO perspective.

nsjames commented 4 years ago

Though that's valid from an EOSIO perspective, it isn't from a security perspective.

From the user's side, they haven't given permission to the app to sign with that account, just the account that controls it. So imagine a scenario where a user has an account with no tokens, which controls another account with tokens. The user gives the app permission to use the controlling account, but not the controlled account, and then the app signs a transfer on the controlled account even though the user thought they only signed in with the controlling account.

Slippery slope.