Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Authorizable contract #743

Closed
medvedev1088 opened this issue Feb 15, 2018 · 12 comments
Closed

Add Authorizable contract #743

medvedev1088 opened this issue Feb 15, 2018 · 12 comments
Labels
feature New contracts, functions, or helpers. good first issue Low hanging fruit for new contributors to get involved!

Comments

@medvedev1088
Copy link
Contributor

medvedev1088 commented Feb 15, 2018

🎉 Description

Something like this:

contract Authorizable is Ownable {

    mapping(address => bool) public authorized;

    modifier onlyAuthorized() {
        require(authorized[msg.sender] || owner == msg.sender);
        _;
    }

    function addAuthorized(address _toAdd) onlyOwner public {
        authorized[_toAdd] = true;
    }

    function removeAuthorized(address _toRemove) onlyOwner public {
        authorized[_toRemove] = false;
    }

}
  • [+] 📈 This is a feature request.

Originally discussed here https://ethereum.stackexchange.com/questions/39654/smart-contract-multiple-owners/39657#39657

@eordano eordano added feature New contracts, functions, or helpers. good first issue Low hanging fruit for new contributors to get involved! labels Feb 15, 2018
@medvedev1088
Copy link
Contributor Author

@eordano I've just found contracts/ownership/rbac/RBAC.sol contract that provides similar capabilities to Authorizable. Do you think Authorizable will be useful?

@martriay
Copy link
Contributor

@medvedev1088 why would you prohibit 0x0 to be authorized?

@medvedev1088
Copy link
Contributor Author

@martriay no reason. Forgot to remove it while copying from stackexchange.

@martriay
Copy link
Contributor

martriay commented Feb 15, 2018

I like the idea and I definitely would have it separate from RBAC. I'd call it Whitelist instead, and have it emit events on every add/removal, along with a check to avoid redundant storage writes and event firings. Also, I would add an isWhitelisted(address) public function.

What do you think?

@medvedev1088
Copy link
Contributor Author

medvedev1088 commented Feb 15, 2018

@martriay Sounds good to me. Although not sure about "check to avoid redundant storage writes". The check itself will add 200 gas right? because we need to read from the storage first. In most cases the owner can make this check off-chain instead to prevent redundant storage writes.

What do you think?

@martriay
Copy link
Contributor

martriay commented Feb 15, 2018

As a rule of thumb, I think every contract's logic should be self-contained, without relying on other contracts/users to do things well.

Maliciously or by mistake, multiple calls to whitelist the same address can be made and more than 200gas would be wasted along with redundant events in the blockchain.

@medvedev1088
Copy link
Contributor Author

@martriay do you think I should revert() or just ignore on redundant call?

@martriay
Copy link
Contributor

@medvedev1088 I would make the function return a boolean value indicating if it was successful. This way the contract can be used programmatically by other contracts and react accordingly.

@medvedev1088
Copy link
Contributor Author

medvedev1088 commented Feb 15, 2018

@martriay Ok, btw the compiler will auto-generate a public getter for the whitelist whitelist(address). Do you think we still need isWhitelisted(address)?

@martriay
Copy link
Contributor

Yes, it can be left out.

@medvedev1088
Copy link
Contributor Author

@martriay @eordano Please take a look #746. Any comments are welcome.

@come-maiz
Copy link
Contributor

Already merged. Thank you @medvedev1088 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New contracts, functions, or helpers. good first issue Low hanging fruit for new contributors to get involved!
Projects
None yet
Development

No branches or pull requests

4 participants