9

The _self auth, shown here require_auth( _self ); requires the authority of the owner of the contract, in this case eosio. If we inspect that account with get account we see this owner 1: 1 eosio.prods@active Which means eosio has given his authority to eosio.prods. And if we inspect that account we see this. active 15: 1 argentinaeos@...


5

eosio_assert( has_auth(accounta) || has_auth(accountb), "missing required authority of accounta or accountb"); See: https://eosio.github.io/eosio.cdt/1.5.0/group__action.html#function-hasauth


4

The require_auth() directive asserts that the transaction has been signed by the specified account. In the case of require_auth(_self), the assertion is that the transaction has been signed by the account that deployed the contract. In other words, if you have deployed the contract to the eosio account, then the transaction has to be signed by the eosio ...


3

You can use the require_auth2() function, which can check a custom permission Verifies that name exists in the set of provided auths on a action. Throws if not found Parameters name - name of the account to be verified permission - permission level to be verified The official docs have an article explaining permissions in EOSIO, and ...


3

An example: has_auth(accountname) See: https://eosio.github.io/eosio.cdt/1.5.0/group__action.html#function-hasauth


2

From an answer by Todd Fleming on the EOS Developers Telegram channel: If user A authorizes an action sent to contract B then that does not imply B can send an action to contract C with A's authorization. There are two ways to address this. The bad way: have users authorize B to act on their behalf. The good way: contracts can detect when someone transfers ...


2

The answer is simple. Deploy the Hello example with the contract name gazaomauaaae. Deploy your original contract, again as gazaomauaaae. DONE.


2

If an action is initiated by user account, it will be included in the trx.trx.actions array of a transaction. Follow this idea, we could do: We have a output actions list from your cleos get actions <dApp account name> -j command. We would like to know that, for each action in the list, is it a user action or an inline action. So we should iterate ...


2

C++ API is wrapped differently. inline void require_auth( const permission_level& level ) { internal_use_do_not_use::require_auth2( level.actor.value, level.permission.value ); } // how to use require_auth(permission_level("eosio"_n, "vote"_n));


1

You can search for an iterator with given key from multi_index first. iterator found: already created item, require_auth(user) iterator not found: not created item, require_auth(admin) Permission check can be done in any step of your method. (Even you call require_auth() at the last time of your method, its failure reverts all changes made during that ...


1

The above case works if you do it like the following: void multiauth(name user) { if (user == name("walletxxxxxx") || user == name("walletzzzzzz")) { require_auth(user); } else { require_auth(_self); } } But that's definitely not state of the art to grant permissions for execution of actions to specific accounts on eosio. The ...


1

When a contract sends an inline action, it cannot send with the permission level passed by the caller; it sends with a special eosio.code permission name. In your example, makepokemon can only use makepokemon@eosio.code and not user@active, so user has to explictily give makepokemon permission to transfer tokens if they want to.


1

So the user pushes the action with -p user@active, and now the contract can "steal" those tokens unrightfully? Or am I missing something? No, that can not steal the tokens because you check the authenticity inside the action itself. Then, it does not matter what permission are you sending via command line. Your makepokemon action should check the ...


1

I think, you have an incorrect idea regarding permissions in eos. A permission in itself does not have any authority to do anything, but an account with a certain permission can be used to authorise actions. Now, if that is clear, what you may do for your problem is, in your action (member function's definition), you can check that only accounts with ...


1

For every transaction, we need to have at least one signer to bill the net and cpu. And unless we link the action with alice@active permission, the minimum required authority is active. Try the following command: cleos set action permission alice.cc alice.cc increament alice@active


1

There is a built-in check when deploying a contract to refuse to deploy the contract if it hasn't changed. This can be problematic when you are making changes to the ABI as changes to it don't count as changes to the contract. For debugging purposes, my typical workaround is to have some innocuous statement in the contract (usually a print statement) that ...


1

Change it as follows. cleos -u http://api.eosnewyork.io push action gywaofjugage issue '["issuer", "1.0000 TOKEN", "memo"]' -p issuer I will arrange what you have done step by step. In the first step above, the create action from the eosio.token contract, authorized by the gywaofjugage account, creates 1000000000.0000 TOKEN tokens in the issuer. In the ...


1

In command cleos -u http://api.eosnewyork.io push action gywaofjugage create '[ "issuer", "1000000000.0000 TOKEN", 0, 0, 0]' -p gywaofjugage Can you confirm that "issuer" was actually "gywaofjugage" then? Only the account name specified in place of issuer has authority to mint tokens.


1

You seem to be using -p gywaofjugage as the -p option. Try using -p gywaofjugage@active instead? The -p option is described as "An account and permission level to authorize, as in 'account@permission'" in https://developers.eos.io/eosio-cleos/reference#cleos-push-action


1

This article have a very detailed explanation regarding multisig usage on EOS. https://steemit.com/eos/@genereos/eos-multisig-tutorial


Only top voted, non community-wiki answers of a minimum length are eligible