[documentation] Bash tutorial, transferring assets, access rights and account auth

6r1d commented 1 year ago

Documentation URL(s)

Description

Sungod reported an issue with our current documentation: the Bash guide can't be finished, and step 6, "transferring assets", is the reason.

./iroha_client_cli account grant --id "mad_hatter@looking_glass" --permission permission_token.json

The error he sees in the logs is: The signer does not own the asset specified in the permission token. Repeating the attempt causes the same error no matter how often he tries it.

Log contents

``` User: alice@wonderland {"PUBLIC_KEY":"ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0","PRIVATE_KEY":{"digest_function":"ed25519","payload":"9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"},"ACCOUNT_ID":"alice@wonderland","BASIC_AUTH":{"web_login":"mad_hatter","password":"ilovetea"},"TORII_API_URL":"http:\/\/127.0.0.1:8080","TORII_TELEMETRY_URL":"http:\/\/127.0.0.1:8180","TRANSACTION_TIME_TO_LIVE_MS":100000,"TRANSACTION_STATUS_TIMEOUT_MS":15000,"TRANSACTION_LIMITS":{"max_instruction_number":4096,"max_wasm_size_bytes":4194304},"ADD_TRANSACTION_NONCE":false} Error: 0: Failed to grant permission to the account 1: Failed to submit transaction SignedTransaction { payload: Payload { account_id: Id { name: "alice", domain_id: Id { name: "wonderland" } }, instructions: Instructions([Grant(GrantBox { object: EvaluatesTo { expression: Raw(PermissionToken(Token { definition_id: Id { name: "can_transfer_user_assets" }, params: {"asset_id": Id(AssetId(Id { definition_id: DefinitionId { name: "tea", domain_id: Id { name: "looking_glass" } }, account_id: Id { name: "mad_hatter", domain_id: Id { name: "looking_glass" } } }))} })), _value_type: PhantomData }, destination_id: EvaluatesTo { expression: Raw(Id(AccountId(Id { name: "mad_hatter", domain_id: Id { name: "looking_glass" } }))), _value_type: PhantomData } })]), creation_time: 1677062642194, time_to_live_ms: 100000, nonce: None, metadata: {} }, signatures: {iroha_crypto::signature::SignatureOf({ pub_key: ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0, payload: 3BD290B7A7540D7FE610C031EF60234D71A00E0E275D4A0E62851DAB0F85946708BFC3DA7E24462755C8E951C8FCA74F495255DB0D35F63FD732DAE00467F70A })} } 2: Transaction rejected 3: Action not permitted: Validator ``Grant validator` with nested checking` denied the operation `GRANT `can_transfer_user_assets: {`asset_id` : `tea##mad_hatter@looking_glass`}` TO `mad_hatter@looking_glass`` by `alice@wonderland`: Validator `Allow to grant `can_transfer_user_assets` permission token if `the signer is the asset owner`` denied the operation: The signer does not own the asset specified in the permission token 4: Action not permitted: Validator ``Grant validator` with nested checking` denied the operation `GRANT `can_transfer_user_assets: {`asset_id` : `tea##mad_hatter@looking_glass`}` TO `mad_hatter@looking_glass`` by `alice@wonderland`: Validator `Allow to grant `can_transfer_user_assets` permission token if `the signer is the asset owner`` denied the operation: The signer does not own the asset specified in the permission token 5: Action not permitted: Validator ``Grant validator` with nested checking` denied the operation `GRANT `can_transfer_user_assets: {`asset_id` : `tea##mad_hatter@looking_glass`}` TO `mad_hatter@looking_glass`` by `alice@wonderland`: Validator `Allow to grant `can_transfer_user_assets` permission token if `the signer is the asset owner`` denied the operation: The signer does not own the asset specified in the permission token Location: client/src/client.rs:524 ```

The configuration file is not outdated and was previously copied from configs/client_cli/config.json.

{
  "PUBLIC_KEY": "ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0",
  "PRIVATE_KEY": {
    "digest_function": "ed25519",
    "payload": "9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"
  },
  "ACCOUNT_ID": "alice@wonderland",
  "BASIC_AUTH": {
    "web_login": "mad_hatter",
    "password": "ilovetea"
  },
  "TORII_API_URL": "http://127.0.0.1:8080",
  "TORII_TELEMETRY_URL": "http://127.0.0.1:8180",
  "TRANSACTION_TIME_TO_LIVE_MS": 100000,
  "TRANSACTION_STATUS_TIMEOUT_MS": 15000,
  "TRANSACTION_LIMITS": {
    "max_instruction_number": 4096,
    "max_wasm_size_bytes": 4194304
  },
  "ADD_TRANSACTION_NONCE": false
}

Sungod noted that even if steps are completed successfully, some errors appear in Compose logs:

iroha-iroha2-1  | 2023-02-22T09:57:11.296032Z ERROR run: iroha_core::sumeragi::main_loop: The block is rejected as it is not signed by the leader. addr=iroha2:1339 role=ProxyTail leader=iroha3:1340 hash=e74a5d5178e8f1e9f4b0de86e6954939f4b2623709eca14b019903c360413e13
iroha-iroha0-1  | 2023-02-22T09:57:11.314676Z ERROR run: iroha_core::sumeragi::main_loop: The block is rejected as it is not signed by the leader. addr=iroha0:1337 role=ObservingPeer leader=iroha3:1340 hash=e74a5d5178e8f1e9f4b0de86e6954939f4b2623709eca14b019903c360413e13

I was told that such errors sometimes happen in the Sumeragi consensus algorithm by @mversic. The most probable cause is the delayed packet from the previous round that reaches the node after a change. However, it does not affect the function of the Sumeragi consensus algorithm.

As @mversic suggested, the account id in the config file should apply to the mad_hatter@looking_glass instead of alice@wonderland, so I've altered the config by replacing the ACCOUNT_ID:

{
  "PUBLIC_KEY": "ed01207233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0",
  "PRIVATE_KEY": {
    "digest_function": "ed25519",
    "payload": "9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"
  },
  "ACCOUNT_ID": "mad_hatter@looking_glass",
  "BASIC_AUTH": {
    "web_login": "mad_hatter",
    "password": "ilovetea"
  },
  "TORII_API_URL": "http://127.0.0.1:8080",
  "TORII_TELEMETRY_URL": "http://127.0.0.1:8180",
  "TRANSACTION_TIME_TO_LIVE_MS": 100000,
  "TRANSACTION_STATUS_TIMEOUT_MS": 15000,
  "TRANSACTION_LIMITS": {
    "max_instruction_number": 4096,
    "max_wasm_size_bytes": 4194304
  },
  "ADD_TRANSACTION_NONCE": false
}

There lies a problem: we have a public and private key assigned to the mad_hatter@looking_glass account, and I don't know where those are located. Using cargo run --bin kagami -- crypto did not help because some keys are generated beforehand.

I also need clarification about the whole situation with the accounts here.

We have Kagami passwords and access keys at the same time.
We have a pre-defined public key in "Registering an account" section, possibly with a lost private one.
Is Alice an already existing account?
How do we replace public and private keys for registered users?

Your suggestions

We'll have to alter the tutorial right after this is fixed.

Who can help?

@mversic @appetrosyan @outoftardis

outoftardis commented 1 year ago

Is Alice an already existing account?

Yes. And in client config, the ACCOUNT_ID should be an account that already exists (was previously registered).

We have a pre-defined public key in "Registering an account" section, possibly with a lost private one.

Since this is an example, should we just generate a new key pair for mad_hatter and include it in the tutorial?

mversic commented 9 months ago

@6r1d can you move this to the iroha2-docs repo?

hyperledger-iroha / iroha-2-docs