EOSIO / eos

An open source smart contract platform
https://developers.eos.io/manuals/eos
MIT License
11.28k stars 3.6k forks source link

provided keys in error message is wrong #9794

Open n13 opened 3 years ago

n13 commented 3 years ago

I received an error message about missing permissions [1]

Subsequent invocations of the same action caused ever-changing "provided keys" - the provided key, according to nodeos, was always a different one.

As it turns out nodeos merely takes a guess at the "provided keys" but can't accurately determine them. This should be reflected in the error message. It should either omit the message about provided keys or say "either you provided key [key] or something else went wrong with the signing of this transaction"

Steps to reproduce: 1 - Make any transaction on a local chain using the wrong chain ID

Expected result: Accurate error message example

"Either you provided keys [keys] or something else went wrong with the signing of this transaction"

Alternatively - omit provided keys, since eosio cannot accurately determine provided keys from the signature.

Actual result: Misleading error message

Reference (this is what is happening): https://github.com/EOSIO/eosjs/issues/518#issuecomment-472176189

[1]

{
   "code":500,
   "message":"Internal Service Error",
   "error":{
      "code":3090003,
      "name":"unsatisfied_authorization",
      "what":"Provided keys, permissions, and delays do not satisfy declared authorizations",
      "details":[
         {
            "message":"transaction declares authority '{\"actor\":\"owner\",\"permission\":\"active\"}', but does not have signatures for it under a provided delay of 0 ms, provided permissions [], 
provided keys [\"EOS6b4ZQkcMuHmLdTmWERUL1PikWvX9LMzgcfF9of1nZAjt9PoJow\"],  <==== Wrong, I never provided this key
and a delay max limit of 3888000000 ms",
            "file":"authorization_manager.cpp",
            "line_number":532,
            "method":"check_authorization"
         }
      ]
   }
}
rusty-block-one commented 3 years ago

Thanks to @tbfleming and @heifner for their assistance and recommendations for the solution to this issue. @heifner for pointing out that removing the information from the message was the incorrect approach and @tbfleming for recommending a preferred solution. The solution was to change the message from stating these are provided keys to stating these are recovered keys. It clarifies what is being reported.