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

[techraed]

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]

So a few questions:

• After creating the new account, does that new account now exist within Scatter?
• If so, have you re-logged-in to add permissions for that new account?

[techraed]

@nsjames

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

[nsjames]

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]

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]

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.