15

UPDATE: This is the code I used to experiment with all combinations of permissions I could come up with: https://github.com/andresberrios/permissions_test After a lot of experimentation, I finally understand how permissions work in EOSIO! EOS Permission Model - Overview An account can have various permissions (like owner and active), which are represented ...


4

as explained in the message, you need to add 'eosio.code' permission to dice@active cleos set account permission dice active '{"threshold": 1,"keys": [{"key": "EOS7ijWCBmoXBi3CgtK7DJxentZZeTkeUnaSDvyro9dq7Sd1C3dC4","weight": 1}],"accounts": [{"permission":{"actor":"dice","permission":"eosio.code"},"weight":1}]}' owner -p dice


4

Yes, both inline actions and deferred actions are asynchronous. Which seems to be synchronous, so can we not assume synchronous behaviour(result is returned by the function call) for inline actions? No, inline actions are non-blocking: the inline action is queued to be processed after the action is completed, but it is executed in the same transaction. For ...


3

This seems to work for me: $ mkdir -p project/sender $ mkdir project/recipient $ touch project/sender/sender.cpp $ touch project/recipient/recipient.cpp sender.cpp #include<eosiolib/eosio.hpp> #include<string> using std::string; using eosio::contract; using eosio::permission_level; using eosio::action; class sender : contract { public: ...


3

You can get the inline actions in get_actions RPC History API endpoint or inside the details of a transaction using also the RPC API get_transaction. So that's exactly what I'm doing in that eos-node-watcher, I filter all the transactions relevant to my dapp and call get_transaction for them. The thing is that you could just shortcut it by running ...


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

You can call any function of a smart contract from within the smart contract, however only functions labelled as actions can be called from outside of the smart contract. So if you have a function in contract A that needs to call a function from contract B, you would have to do this by sending an action. An inline action means that the action has to be ...


1

The results of both cases are identical, but action_wrapper provides compile-time type check. If you pass invalid parameters, you will fail to build your contract. You don't need to include the header file of the target contract where you send an inline action with the 1st way (Use 'action'), but to declare action_wrapper, you need the header file or declare ...


1

You need to pass partner2 transaction auth in contract action data inorder to execute , not partner1's { "timestamp" :12345567, "author" : "partner2",....} cleos multisig propose testfin '[{"actor": "partner2", "permission": "active"}]' '[{"actor": "partner2", "permission": "active"}]' mltisigmetup meetup '{ "timestamp" :12345567, "author" : "partner2", "...


1

Inline actions are part of the same transaction, but their authorizations are separate. This limits abuse. e.g. if I send a playwith action to a crypto pet, the pet's contract can't unilaterally take my eosio.token tokens.


1

In Dawn 4.0 at least, when A calls B it does so with an authorization that is specific to itself (generally, contract@eosio.code). B can check the authorization.


1

It seems hard to find an example that can answer all your questions. Below is an example of sending an inline action without permission. You can learn a lot by reading this article. https://trybe.one/the-ultimate-end-to-end-eos-dapp-tutorial-part-2/ How about making a reference to each of these examples? How about making examples by referring to this ...


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