AdsRole- Top Digital Marketing Company is an emerging website solution provider that helps make your ordinary website look spectacular. The digital market is an ever-growing platform and a pivotal part of every business today. Therefore, it is imperative for any organization venturing into the online marketplace to keep an eye out for the digital changes, and up with the pace. AdsRole helps you stay ahead of the competition. We help your business gain online visibility by advertising your brand in the best possible manner through effective marketing and publicity of your website at an affordable price. As a result, you enjoy higher conversion rates, profits, and revenues. AdsRole helps you reach your destination sooner and with confidence! Whether it’s about getting your website designed and developed, improving its visibility through Search Engine Optimisation (SEO), Social Media and Pay Per Click (PPC), or maintaining the website, we have got you covered. All your website-related concerns starting from the preliminary to later stages can be tackled here.

AdsRole

What is Authorization? Authorization is all about answering the question “Is this user allowed to do a certain operation?”. This is different from Authentication in which we answer the question “Which user is this request coming from?” Both are essential to most applications, and as such, we first go through authentication flows to identify who the user is, and then we go through authorization flows in which we decide if the user has the permissions to do certain operations. What is Roles based access control (RBAC)? RBAC is one of the ways in which Authorization can be implemented. It allows developers to create “groups” of users that can all do the same set of operations. The name of the group is essentially the role of those users. For example, a blogging app may have a role called which allows users (who are associated with that role) to do operations like delete, edit or read all the blogs on the app. The app may have another role called which allows users to read all blogs, but edit or delete only blogs created by them. "admin" "regular-user" In formal notation, the actions that can be taken can be represented as strings like: Read all blogs: "read:all" Delete all blogs: "delete:all" Delete blogs created by self: "delete:self" Edit all blogs: "edit:all" Edit blogs created by self: "edit:self" These are known as permissions. In a grid form, the roles and permissions for our example app will look like this: The permission implies as well. Same
goes for the permission. "edit:all" "edit:self" "delete" Advantages of RBAC : The structure of roles and permissions is very intuitive. It can be understood by new employees fairly quickly. Easy to understand : As the org structure changes, assigning new roles to employees automatically gives them all the right access - there is no extra coding required, and the change can be made via a dashboard in minutes. Easy changes : Using RBAC forces executives to think about and organize access control. This information can then be used by compliance officers during audit. Improving compliance : Due to its ease of use, developers can easily implement the right access control policies in their APIs reducing the chances of data leaks. Decrease risk of data breaches / leakage Disadvantages of RBAC : It can be complex to make exceptions to how a role works. In our example above, if we want to add a rule that users with role cannot edit their own post if they have already made ten edits, it will have to be added in the API logic as an exception. There is no way for the roles / permissions system to express it easily. This causes issues since we have to make sure to encode this rule in all places where we are checking for the permission. Difficult to make exceptions "regular-user" "edit:self" : There could be situations in which a user is assigned two roles that have conflicting information. In our example above, if a user is assigned the role and the , they have and permission. Which one should take precedence? The precedence logic can be coded in the APIs, but that opens up scope for errors. Can cause conflicts in permissions "admin" "regular-user" "edit:self" "edit:all" In fact, developers may forget to define permission precedence alltogether. This can cause unintended side effects in authorization logic. In our example, if we write the API logic like this: // ...
if (permissions.contains("edit:self")) {
    // only allow edit if the blog belongs to the current user
} else if (permissions.contains("edit:all")) {
    // allow edit
}
// ... It may cause issues if a user has the and roles - despite having the role, they will not be able to edit all the blogs cause it will execute into the first statement above. "admin" "regular-user" "admin" if Code Example Let’s continue with our example above and see how we can actually implement it in an app using - an open source authentication / authorization provider. SuperTokens The code snippets below are for a NodeJS backend, but similar logic applies for the other backend SDKs offered by SuperTokens as well. All the code snippets are as per SuperTokens Node SDK version v11.0.1 Step 1) Creating the roles and permissions SuperTokens needs to know about the roles and permissions before they can be assigned to users. For that, we can use the function exposed by the SDK: createNewRoleOrAddPermissions import UserRoles from "supertokens-node/recipe/userroles";

// creating the admin role and adding permissions to it.
await UserRoles.createNewRoleOrAddPermissions("admin", ["read:all", "delete:all", "edit:all"])

// creating the regular-user role and adding permissions to it.
await UserRoles.createNewRoleOrAddPermissions("regular-user", ["read:all", "delete:self", "edit:self"]) Step 2) Assigning roles to users on sign up You can add the code snippet below in your override function for the sign up API import UserRoles from "supertokens-node/recipe/userroles";

// the value of roleToAssign needs to be fetched by you.
// For example, you could check if the user's email is of a certain domain,
// and if it is, then they would be an admin, else not.
if (roleToAssign === "admin") {
    // the userId belongs to the user who just signed up.
    await UserRoles.addRoleToUser(userId, "admin");
} else {
    await UserRoles.addRoleToUser(userId, "regular-user");
} You can even so that accessing them later (on the frontend or backend) is efficient. add the roles and permissions to the user’s session payload Step 3) Guarding APIs based on a user’s role or permissions Once you have completed session verification in your APIs, you can retrieve the user ID of the logged in user and get their roles and permissions using that: import { verifySession } from "supertokens-node/recipe/session/framework/express";
import UserRoles from "supertokens-node/recipe/userroles";

app.delete("/blog", verifySession(), async (req, res) => {
    let blogId = req.body.blogId
    let userId = req.session.getUserId();

    let roles = await UserRoles.getRolesForUser(userId).roles
    // if the user is an admin, we will be ["admin"], else we will get ["regular-user"]

    let permissions = await UserRoles.getPermissionsForRole(roles[0]).permissions
    // if the role is "admin", we get ["read:all", "delete:all", "edit:all"]
    // else we get ["read:all", "delete:self", "edit:self"]

    if (permissions.includes("delete:all")) {
        // allow delete
    } else if (permissions.includes("delete:self")) {
        if (getOwnerOfBlog(blogId) === userId) {
            // allow delete
        } else {
            // return access denied error
        }
    }
}) You can learn more about how to use user roles and permissions feature using SuperTokens via the recipe guides docs on supertokens.com. Alternate libraries Whilst SuperTokens allows you to guard your frontend and backend routes via a mapping of roles and permissions, access control goes beyond that. You may want to: Organize roles in a hierarchy such that a parent role inherits permissions from child roles. Be able to specify permission precedence with the authorization framework as opposed to in your API code. Visualize the roles and permissions relations. Define complicated policies that combine roles and permissions to determine if a user has access to a resource. For these use cases, there are dedicated authorization solutions which you can integrate with your existing authentication provider. Some examples are: Casbin Osohq Permit.io Written by the Folks at SuperTokens — hope you enjoyed! We are always available on our . Join us if you have any questions or need any help. Discord server

Authorization With User Roles (RBAC)

Three example configurations for the new OpenZeppelin access control contract. Access Control in Solidity. The new library from OpenZeppelin makes me happy Photo by from Scott Webb Pexels Restricting access to authorized users is really important in smart contracts. With $1 Billion locked in DeFi applications, you would really hope everyone knows what they are doing. Recently, I collaborated with OpenZeppelin to refactor the access control in their widely used repository. If you have ever coded a smart contract, most likely you have inherited from their code. openzeppelin-contracts In this article, I’m going to give you a walkthrough of how to use the revamped to restrict access to your smart contracts. I’ll do this through three examples. AccessControl.sol But first, let me tell you the story of how we got here. Please feel free to skip the next section if you are not interested in how this contract came to be and only want to learn how to use it. How we got here Getting here for me has been a process that took about a year. I first had the idea for a hierarchical role-based control contract in May 2019. I , along with some references to what OpenZeppelin was doing at the time. published the code in Medium I reused that code for and , becoming convinced that the implementation offered something both unique and powerful. From the lessons learned I wrote showing when to use , and . AllianceBlock Insig a second article Ownable.sol Whitelist.sol RBAC.sol To write that article I needed to research deeply into what OpenZeppelin had been doing in terms of access control. You don’t challenge the most-forked solidity repository without doing your homework. The OpenZeppelin team are really great guys, and shortly after they in the refactor of their access control contracts. Out of that collaboration we created an access control contract that is much more flexible than their previous approach, and much more robust than my previous approach. invited me to participate is available from the repository and I don’t keep a different codebase anymore. AccessControl.sol openzeppelin-contracts As an interesting aside, and as further proof of how important is access control, a version of existed back in 2016. It was Manuel Araoz’s towards what would become . Ownable.sol 9th commit openzeppelin-contracts In solidity years that is like digging dinosaur bones, and proves that access control is one of the very first things you should think about when coding smart contracts. Especially if you intend to code robust ones. Story time over, let’s dive into the code. How does AccessControl.sol work A role in is a struct that contains a set of addresses, representing the accounts bearing that role. All roles are stored in a mapping indexed by a bytes32 identifier, unique for each role. AccessControl.sol Each role also contains the bytes32 identifier of another role, which we call its admin role. There are internal functions to grant and revoke roles, and to set a role as the admin of another. These internal functions have no restrictions and you can use them if you are extending AccessControl.sol, as we will do later in this article. There are also external functions that restrict granting and revoking roles, as well as setting roles as admins of others. These functions can only be called externally by accounts that have been granted the admin role of the role being modified. As an example, imagine that we have two roles, DEFAULT_ADMIN_ROLE and USER_ROLE. DEFAULT_ADMIN_ROLE is the admin role for USER_ROLE. Only accounts that have been granted the DEFAULT_ADMIN_ROLE can grant or revoke USER_ROLE for an account. Likewise, only accounts that have been granted the DEFAULT_ADMIN_ROLE can redefine the admin role for USER_ROLE. A bit of magic worked here by was to define DEFAULT_ADMIN_ROLE as the uninitialized bytes32 variable. That means that all roles, by default, have DEFAULT_ADMIN_ROLE as the admin role. nventuro That’s it, let me show you in more detail with examples. Community replicates the functionality that existed in OpenZeppelin before. This contract Roles.sol There is a single role (DEFAULT_ADMIN_ROLE). Anyone that has that role can grant it to others. In roles can’t be revoked from a different account, but accounts can renounce to a role they hold. Community.sol The address passed on to the constructor is the first account being granted the role. pragma solidity ^ ; ; contract Community is AccessControl { (address root) public {
    _setupRole(DEFAULT_ADMIN_ROLE, root);
  } modifier onlyMember() { (isMember(msg.sender), );
    _;
  } { hasRole(DEFAULT_ADMIN_ROLE, account);
  } {
    grantRole(DEFAULT_ADMIN_ROLE, account);
  } {
    renounceRole(DEFAULT_ADMIN_ROLE, msg.sender);
  }
} 0.6 .0 import "@openzeppelin/contracts/access/AccessControl.sol" /// @dev Implements a single role access control contract. /// @dev Create the community role, with `root` as a member. constructor /// @dev Restricted to members of the community. require "Restricted to members." /// @dev Return `true` if the `account` belongs to the community. ( ) ( ) function isMember address account public virtual view returns bool return /// @dev Add a member of the community. ( ) function addMember address account public virtual onlyMember /// @dev Remove oneself as a member of the community. ( ) function leaveCommunity public virtual Administered implements a traditional setup with administrators and users. This smart contract DEFAULT_ADMIN_ROLE is the admin role of USER (by default). The address passed on to the constructor is the initial administrator. Admins can add other admins. Admins can grant and revoke user permissions to any accounts. The only way for an admin to lose its admin role is to renounce from it. pragma solidity ^ ; ; contract Administered is AccessControl {
  bytes32 public constant USER_ROLE = keccak256( ); (address root)
    public
  {
    _setupRole(DEFAULT_ADMIN_ROLE, root);
    _setRoleAdmin(USER_ROLE, DEFAULT_ADMIN_ROLE);
  } modifier onlyAdmin()
  { (isAdmin(msg.sender), );
    _;
  } modifier onlyUser()
  { (isUser(msg.sender), );
    _;
  } { hasRole(DEFAULT_ADMIN_ROLE, account);
  } { hasRole(USER_ROLE, account);
  } {
    grantRole(USER_ROLE, account);
  } {
    grantRole(DEFAULT_ADMIN_ROLE, account);
  } {
    revokeRole(USER_ROLE, account);
  } {
    renounceRole(DEFAULT_ADMIN_ROLE, msg.sender);
  }
} 0.6 .0 import "@openzeppelin/contracts/access/AccessControl.sol" /**
 * @title Administered
 * @author Alberto Cuesta Canada
 * @notice Implements Admin and User roles.
 */ "USER" /// @dev Add `root` to the admin role as a member. constructor /// @dev Restricted to members of the admin role. require "Restricted to admins." /// @dev Restricted to members of the user role. require "Restricted to users." /// @dev Return `true` if the account belongs to the admin role. ( ) ( ) function isAdmin address account public virtual view returns bool return /// @dev Return `true` if the account belongs to the user role. ( ) ( ) function isUser address account public virtual view returns bool return /// @dev Add an account to the user role. Restricted to admins. ( ) function addUser address account public virtual onlyAdmin /// @dev Add an account to the admin role. Restricted to admins. ( ) function addAdmin address account public virtual onlyAdmin /// @dev Remove an account from the user role. Restricted to admins. ( ) function removeUser address account public virtual onlyAdmin /// @dev Remove oneself from the admin role. ( ) function renounceAdmin public virtual Hierarchy This is the structure implemented in , with a minimal modification to build a hierarchy of roles safely. AccessControl.sol The address passed on to the constructor has the DEFAULT_ADMIN_ROLE, and is by default admin of all roles. I’ll call that address root. Root can grant the DEFAULT_ADMIN_ROLE to any account. Any root account can revoke the DEFAULT_ADMIN_ROLE role from any other account, so better not to grant it in the first place unless you know what you are doing. All roles exist from the beginning, as keys in a mapping. Any role can be granted or revoked by an account in the DEFAULT_ADMIN_ROLE. In each role has an admin role (DEFAULT_ADMIN_ROLE by default). In we allow for any account with that admin role can change the relationship and choose a new admin role. This can be used to build a hierarchy of roles, for example: DEFAULT_ADMIN_ROLE -> USER_ADMIN -> USER. AccessControl.sol Hierarchy.sol contract Hierarchy is AccessControl {
  event AdminRoleSet(bytes32 roleId, bytes32 adminRoleId); (address root) public {
    _setupRole(DEFAULT_ADMIN_ROLE, root);
  } modifier onlyMember(bytes32 roleId) { (hasRole(roleId, msg.sender), );
    _;
  } {
    _setRoleAdmin(roleId, adminRoleId);
  }
} /// @dev Add `root` as a member of the root role. constructor /// @dev Restricted to members of the role passed as a parameter. require "Restricted to members." /// @dev Create a new role with the specified admin role. ( ) ( ) function addRole bytes32 roleId, bytes32 adminRoleId public onlyMember adminRoleId It’s useful to have AccessControl.sol relevant code handy to understand what’s going on. abstract contract AccessControl is Context {
… { (
      hasRole(_roles[role].adminRole, _msgSender()), );
    _grantRole(role, account);
  } { (
      hasRole(_roles[role].adminRole, _msgSender()), );
    _revokeRole(role, account);
  } { (
      account == _msgSender(), );
    _revokeRole(role, account);
  }
  …
} /// @dev Grants `role` to `account`. ( ) function grantRole bytes32 role, address account external virtual require "AccessControl: sender must be an admin to grant" /// @dev Revokes `role` from `account`. ( ) function revokeRole bytes32 role, address account external virtual require "AccessControl: sender must be an admin to revoke" /// @dev Revokes `role` from the calling account. ( ) function renounceRole bytes32 role, address account external virtual require "AccessControl: can only renounce roles for self" Conclusion I’m really happy and really proud of having got to this point. Really proud because contributing code and ideas to is the strongest validation possible as a smart contracts developer. openzeppelin-contracts Really happy because finally the access control contracts that I’ve been using have now gone through a thorough audit and have been refined by masters in their field. I can now use them with complete confidence that they are right. And really proud and happy to contribute to the community. Giving back is the best present. Now it is up to you to continue. Please , , . BUIDL! use these contracts give feedback propose improvements

Using AccessControl.sol [A How-To Guide]

From the simple to the complex, with the code to reuse. Introduction When writing smart contracts . Even if they are intended for a production environment I make them as easy to understand as possible. I write to be reusable, but usually they get rewritten for each specific business case. I tend to take an educational approach contracts In this article I’m going to discuss three approaches to permissioning in solidity smart contracts. These approaches are discussed in increasing order of complexity, which is the order in which you should consider them for your project. I include code that you can reuse for each approach. This article assumes that you are comfortable coding smart contracts in solidity, and using features like inheritance and passing contracts addresses as a parameter. If you are looking for an easier article on smart contract development you can try . this one Simple Approach - Ownable.sol The contract from OpenZeppelin must be one of the most reused contracts out there. In 77 lines it implements: Ownable.sol The logic to assert that someone is an owner of a contract. The logic to restrict function calling to the contract owner for inheriting contracts. The logic to transfer ownership to a different address. When coding smart contracts you will inherit from very often. Let’s see how to use with an example. Imagine that you want to keep a list of addresses in a contract but you want to be the only one that can add more. Think of it like some kind of registry of people that you trust. You could do something like: Ownable Ownable contract Whitelist is Ownable {
   mapping ( bool) members; () public Ownable() {
   } {
       members[_member] = ;
   }
} => address constructor ( ) function addMember address _member public onlyOwner true Inheriting from and calling its constructor on yours ensures that the address deploying your contract is registered as the owner. The modifier makes a function revert if not called by the address registered as owner. Ownable onlyOwner Once you deploy this contract only you or someone that you designate can add new members to the list within. That's it, in a nutshell. There are a couple more functions but you'll get it if you check the . Try to , it is very easy to understand. source code implement something simple with it Despite its usefulness, there will be many times when is not enough. Only one address can be the owner at a given time, only the owner gets to decide who can be the new owner, you can only check if you are the owner, not is someone else is. Ownable Middle Approach - Whitelist.sol keeps a list of addresses which then can be used to restrict functionality or any other purpose. It is very similar in functionality to OpenZeppelin’s , although with some critical differences (check our ). Whitelist.sol Roles.sol README only has three functions: Whitelist.sol ( ) ( ); ( ) ; ( ) ; function isMember address _member public view returns bool function addMember address _member public onlyOwner function removeMember address _member public onlyOwner With this contract you could, for example, keep a list of approved stakeholders who can be the only recipients for token transfers. You could do something like this: pragma solidity ^ ; ; ;
 
 
contract ERC20Whitelisted is ERC20 {
 
   Whitelist whitelist; (address _whitelistAddress) public {
       whitelist = Whitelist(_whitelistAddress);
   } { (whitelist.isMember(account), ); ._transfer(account, amount);
   }
} 0.5 .0 import "@openzeppelin/contracts/token/ERC20/ERC20.sol" import "../access/Whitelist.sol" constructor ( ) function transfer address account, uint256 amount public require "Account not whitelisted." super In the example above, you could also make inherit from both and . There are some trade offs that . ERC20Whitelisted ERC20 Whitelist I would be happy to discuss Simple whitelists can be quite powerful. OpenZeppelin implemented many and variants using them and managed to provide more functionality than most of us will need. At we implemented using only whitelists as well. ERC20 ERC721 TechHQ CementDAO Sometimes, however, whitelists will also fall short. You might need to have more than one owner for a whitelist. Or you might need to manage many overlapping whitelists. For those cases we have a hierarchical role contract. Complex - RBAC.sol We developed aiming to give multi user functionality like you have in modern shared systems. RBAC.sol There are roles that are nothing more than groups of addresses. Group membership can only be modified by members of some administrator role. New roles can be created at runtime. Role membership can be verified. At a low level we identify the roles using a argument chosen by the user. Commonly these are identifiable short strings, but you can also use an encrypted value or an address. bytes32 The roles themselves are a group of member addresses and the identifier of the admin role. Funnily enough we don’t need to store the identifier of the role inside its own struct. struct Role {
    bytes32 adminRoleId;
    mapping ( bool) members;
} => address There are now two methods to add a new role and verify if a role exists: ( ) ( ); ( ) ; function roleExists bytes32 _roleId public view returns bool function addRole bytes32 _roleId, bytes32 _adminRoleId public And the functions for managing members are the same, only that now the relevant role must be specified: ( ) ( ); ( ) ; ( ) ; function isMember address _member, bytes32 _roleId public view returns bool function addMember address _member, bytes32 _roleId public function removeMember address _member, bytes32 _roleId public and will only succeed if the caller belongs to the administrator role of the role that we are adding members to. addMember removeMember will only succeed if the caller belongs to the role that will administer the role being created. addRole These simple rules will allow to create a hierarchy of roles, which can then be used to implement complex multi user platforms with different permissioning levels or areas. Further Learning To dive even deeper into the rabbit hole I suggest starting with . Their codebase and ours is not that different, and you will find there a thorough reasoning for most design decisions even in the cases where we have chosen to go the other way. Their use of for contracts like is a great example of an alternative to . this issue from OpenZeppelin Roles ERC20Mintable Whitelist Another resource for the brave is the . Just a glance to the interface shows that they have decided to go farther than anyone else: AragonOS ACL contract ( ) ( ); function hasPermission address who, address where, bytes32 what, bytes how public view returns bool We use the three levels of access control described in this article for the examples in our own package, so you should also keep an eye there as well. @hq20/contracts Conclusion When it comes to smart contract implementation it is a good idea to implement only the complexity that is required, and no more. In terms of permissioning there are three distinct levels of complexity: Single user Group of users Hierarchy of user groups You can use for systems that are permissioned for a single user. You can use or for systems that require permissioning users in a group. For systems that require a group hierarchy we have successfully used in the past. Ownable.sol @openzeppelin/Roles.sol @hq20/Whitelist.sol @hq20/RBAC.sol You will have your own requirements and will need to take your own decisions on trade offs. Knowing the design decisions behind each implementation will allow you to either use an existing contract or to modify one for your own use. Please make sure of of any feedback. We are developing the package to support the coding of real world blockchain applications. We are aiming for our code to be reused and abused, and would be very happy to know how you do that. letting us know @hq20/contracts

Understanding Ownership and Access Control in Solidity [A Detailed Guide]

You decide who does what with your smart contracts Historically, privacy was almost implicit, because it was hard to find and gather information. But in the digital world we need to have more explicit rules. — Bill Gates Introduction Role Based Access Control is a that are designed to be accessed by hundreds of users. While this need is commonly implemented in enterprise software and operating systems, not much has been done for the Ethereum Blockchain. security need for software systems This article aims to show how we implemented Role Based Access Control in Solidity for the Ethereum Blockchain, and to teach you to build your own. We also have made our code , please feel free to reuse it in any way or form. public When designing a we realised that we needed to determine dynamically who could add information to each node in the graph. From a real world perspective if you own a manufacturing facility you probably want all operators in the assembly line to record with their own account that they have assembled a part. Supply Chain as a Directed Acyclic Graph , which I use as the gold standard in solidity development, have a contract that they use to implement roles such as Minter and Burner in their . Unfortunately these implementations don’t allow to create new roles at runtime, which you need if you want to control access to each separate token using separate roles. OpenZeppelin Roles.sol ERC721.sol contracts This article aims to show how you can build a Role Based Access Control System for the Ethereum Blockchain. I ended just coding a from scratch according to our requirements, before finding an discontinued version of the from which had pretty much the very same methods. In the interest of reusability I refactored my code as much as I could to follow their nomenclature. RBAC contract same idea OpenZeppelin In the following sections I will describe: The design requirements for our access control system; the implementation as a smart contract; the test cases we considered; the gas usage of state changing methods and some finishing thoughts. Let’s dig in. Conceptual Design My idea for an RBAC system was simple. Roles would be identified by a numeric identifier like groups in unix. Roles could be created dynamically with just a description. Each role would store the addresses of users. Each role would have a second role associated, which would be the only one allowed to add or remove users. If you are using the and contracts from you need to be aware that only implements operations that take effect , while operations that happen are implemented in or the contracts, including the data structure to store roles as you create them. Roles.sol RBAC.sol OpenZeppelin Roles.sol inside a role outside the role RBAC.sol access/roles/*Role.sol I took a number of decisions tailored to our use case: In my implementation I include a description string inside the Role struct, with the structs themselves stored in an array. The position of each Role struct in the array is used as an identifier. There is a temptation to use a mapping to store the Roles, but I find it unnecessary here. Each role receives on instantiation the identifier of another role which we designate as its admin role and which cannot be modified after instantiation. This admin role is the only one that can add and remove bearers to this role. For security and consistency reasons you can remove a Bearer from a Role, but there is no method to remove a Role completely from the system. In my implementation I took a number of implementation decisions tailored to our use case. * An earlier version of this article used arrays to store the bearers in each role. That was changed into a mapping as a suggestion from Nico Vergauwen . The code is more efficient and clearer this way, even if auditing is more cumbersome. Implementation pragma solidity ^ ; contract RBAC {
  event RoleCreated(uint256 role);
  event BearerAdded(address account, uint256 role);
  event BearerRemoved(address account, uint256 role);
  uint256 constant NO_ROLE = ; struct Role {
    string description;
    uint256 admin;
    mapping ( bool) bearers;
  } Role[] public roles; () public {
    addRootRole( );
  } {
    uint256 role = addRole(_roleDescription, roles.length);
    roles[role].bearers[msg.sender] = ;
    emit BearerAdded(msg.sender, role);
  } { (_admin <= roles.length, );
    uint256 role = roles.push(
      Role({ : _roleDescription, : _admin
      })
    ) - ;
    emit RoleCreated(role); role;
  } { roles.length - ;
  } { _role < roles.length && roles[_role].bearers[_account];
  } { (
      _role < roles.length, ); (
      hasRole(msg.sender, roles[_role].admin), ); (
      !hasRole(_account, _role), );
    roles[_role].bearers[_account] = ;
    emit BearerAdded(_account, _role);
  } { (
      _role < roles.length, ); (
      hasRole(msg.sender, roles[_role].admin), ); (
      hasRole(_account, _role), ); roles[_role].bearers[_account];
    emit BearerRemoved(_account, _role);
  }
} 0.5 .0 /**
* @title RBAC
* @author Alberto Cuesta Canada
* @notice Implements runtime configurable Role Based Access Control.
*/ 0 /**
   * @notice A role, which will be used to group users.
   * @dev The role id is its position in the roles array.
   * @param description A description for the role.
   * @param admin The only role that can add or remove bearers from
   * this role. To have the role bearers to be also the role admins 
   * you should pass roles.length as the admin role.
   * @param bearers Addresses belonging to this role.
   */ => address /**
   * @notice All roles ever created.
   */ /**
   * @notice The contract constructor, empty as of now.
   */ constructor "NO_ROLE" /**
   * @notice Create a new role that has itself as an admin. 
   * msg.sender is added as a bearer.
   * @param _roleDescription The description of the role created.
   * @return The role id.
   */ ( ) ( ) function addRootRole string memory _roleDescription public returns uint256 true /**
   * @notice Create a new role.
   * @param _roleDescription The description of the role created.
   * @param _admin The role that is allowed to add and remove
   * bearers from the role being created.
   * @return The role id.
   */ ( ) ( ) function addRole string memory _roleDescription, uint256 _admin public returns uint256 require "Admin role doesn't exist." description admin 1 return /**
   * @notice Retrieve the number of roles in the contract.
   * @dev The zero position in the roles array is reserved for
   * NO_ROLE and doesn't count towards this total.
   */ ( ) ( ) function totalRoles public view returns uint256 return 1 /**
   * @notice Verify whether an account is a bearer of a role
   * @param _account The account to verify.
   * @param _role The role to look into.
   * @return Whether the account is a bearer of the role.
   */ ( ) ( ) function hasRole address _account, uint256 _role public view returns bool return /**
   * @notice A method to add a bearer to a role
   * @param _account The account to add as a bearer.
   * @param _role The role to add the bearer to.
   */ ( ) function addBearer address _account, uint256 _role public require "Role doesn't exist." require "User can't add bearers." require "Account is bearer of role." true /**
   * @notice A method to remove a bearer from a role
   * @param _account The account to remove as a bearer.
   * @param _role The role to remove the bearer from.
   */ ( ) function removeBearer address _account, uint256 _role public require "Role doesn't exist." require "User can't remove bearers." require "Account is not bearer of role." delete Testing I like to describe the tests passed when , both to show the edge cases and to provide some confidence as to the reliability of the code. making a contract public : RBAC ✓ creates a role.
✓ hasRole returns false for non existing roles.
✓ hasRole returns false for non existing ✓ msg.sender as ✓ doesn’t msg.sender with admin role.
✓ on non existing roles.
✓ on non authorized users.
✓ the to the role.
✓ a to a role.
✓ removeBearer on non existing roles.
✓ removeBearer on non authorized users.
✓ removeBearer the doesn Contract RBAC addRootRole bearerships. addRootRole adds bearer. addRole add addBearer reverts addBearer reverts addBearer reverts if bearer belongs addBearer adds bearer reverts reverts reverts if bearer 't belong to the role.
✓ removeBearer removes a bearer from a role. In response to previous feedback, I’m now including as well a gas usage report using eth-gas-reporter. Conclusion This article describes an implementation for a Smart Contract Role Based Access Control System, which has the following properties: Allows new roles to be created at runtime. Includes a concept of role administrator, which is allowed to add and remove members to the role. Allows to easily determine all existing roles and their bearers. Role Based Access Control is not necessarily complex to implement, but as this article shows there are a number of trade-offs and design decisions that need to be taken into account, which will be closely related to your users and the actions that they are allowed to perform. While I would be very pleased if you decide to of an RBAC system, I encourage you to look for and consider other options. reuse this implementation For a practical application of this RBAC contract, stay tuned for the next article in our series. Supply Chain

Role Based Access Control for the Ethereum Blockchain

SOLID is five design principles intended to make software designs more understandable, flexible, and maintainable. It helps us to think about the right way to build a software system SOLID principles in Javascript SOLID is just a set of design principles that all coders and developers should follow to achieve a good design in the software they build. None other than proposed it. SOLID principles explain how to arrange our functions and data structures and how they can be interconnected. Robert C Martin The main goal of the SOLID principles is that any software should tolerate change and should be easy to understand. If we desire to build quality software, the SOLID principle is essential to be followed. Most people assume SOLID is only for strongly typed languages or object-oriented languages like JAVA and more. Though Javascript is a loosely typed language, we can easily apply SOLID principles on Javascript code. Let’s see how we can do that in this article. What does SOLID stand for? S — The Single Responsibility Principle Any software module in an organization should have one and only one reason to change. It means that any function should be responsible for doing only one thing. For instance, in react we can relate it to the stateless functional component. Let’s see it with an example. { re = ; isEmailValid = re.test(email); (isEmailValid){
        createUserInDabase(name, email)
     }
} ( ) function createUser name, email let /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i let if In the above example what if the logic for the email changes. The function createUser should have only one reason to change. In our case only if the logic to create User Changes the function should change. So let’s see how we can change that to SRP { re = ; isEmailValid = re.test(req.email); (isEmailValid){
         createUser(req.name, req.email)
      }
} {
      createUserInDabase(name, email)
} ( ) function validateRequest req let /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i let if ( ) function createUser name, email O — The Open-Closed Principle Any software system should be open for extension and closed for change. This means that the software systems should be allowed to change their behavior by adding new code rather than changing the existing code. Let’s see an example for the Open-Closed Principle allowedRoles = [ , ] { (allowedRoles.includes(user.role)){ ; } { }
} let "admin" "owner" ( ) function checkPrivilege user if return true //user has privilege else return false Now, what if the software system introduces a new role called and users with roles should also be granted privilege. So here we have to modify existing code to add guestAdmin to the list. So rather we can do like the below example to make it pass the Open-Closed principle. guestAdmin guestAdmin allowedRoles = [ , ] { (allowedRoles.includes(user.role)){ ; } { }
}
addRoles(role){
  allowedRoles.push(role)
} let "admin" "owner" ( ) function checkPrivilege user if return true //user has privilege else return false So here we don’t have to modify the existing code rather we can extend it to add a new role L — The Liskov Substitution Principle As per the LSP, . In simple words, derived classes must be substitutable for the base class. Let’s see the Liskov Substitution Principle with an example: functions that use references to base classes must be able to use objects of the derived class without knowing it License = { .calculateFee = { }
}
License.prototype.PersonalLicense = { .calculateFee(user)
}
License.prototype.BusinessLicense = { .calculateFee(user) .getUsers = { }
} var ( ) function user this ( ) function //Logic to calculate Fee ( ) function user this ( ) function user this this ( ) function //Logic to get all users in Business The above example is perfectly in LSP because even if we replace the extended function PersonalLicense instead of License function. So to conclude LSP states that: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. I — The Interface Segregation Principle Interface Segregation Principles advises avoiding depending on modules or functions or anything that they don’t use. But we don’t have an interface by default in Javascript. But we all would have faced situations where we want to do so many things on the constructor of a class. Let’s say some settings we have to do in the constructor. The settings we do should be segregated from the other unwanted settings in the constructor. For example: { (user){ .user = user; .initiateUser();
 }
initiateUser(){ .name = .user.name .validateUser()
 }
} user = User({userProperties, validateUser(){}}); class User constructor this this this this this const new Here, validateUser() function will get invoked in initiateUser constructor call even though it’s not needed all the time. Here comes the Interface Segregation Principle. We can bring this into ISP with the below code: { (user){ .user = user; .initiateUser(); .setupOptions = user.options
 }
initiateUser(){ .name = .user.name .setupOptions()
 }
} user = User({userProperties, : {validateUser()}{}}); class User constructor this this this this this this const new options Here, we pass in options and only if we pass in options it will validate the User. So we are segregating the unwanted logic from the contractor. D — The Dependency Inversion Principle Dependency Inversion Principle states that high-level functions should not be dependant on the code that implements low-level functions. This principle tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions. In a statically typed language, like Java, this means that the use, import, and include statements should refer only to source modules containing interfaces, abstract classes. In case of Javascript we can see the below example: axios.get( , { .setState({ : response.value1, : response.value2
 });
}); "/someAddress/someResource" ( ) function response this value1 value2 The above code is not in DIP. Let’s make it in DIP in the below example: requestWithAxios( , setResponseInState); {
 axios.get( , {
 setResponseInState.setValues(response);
 });
} setResponseInState ={ : { .setState({ : response.value1, : response.value2
  })
 }
} "/someAddress/someResource" ( ) function requestWithAxios address, setResponseInState "/someAddress/someResource" ( ) function response var setValues ( ) function response this value1 value2 I hope this gave you a basic understanding of how to apply SOLID principles in Javascript. Applying SOLID principles can make the code cleaner, extensible and easier to understand. Thanks for reading this article. I head Tech at We are excited about building tools for modern leaders to help them put their people at the heart of business success. If you think you benefited from this blog, please share it with your friends and co-workers! In case you have any queries, clarification, or an idea for my next blog, please let me know in the comments! Upshotly.

ADSROLE

adsrole.com

201-500 employees

Since 2017

COMPANY RANKING

ADSROLE

EVERGREEN INDEX #1722

Representing this company? Click here to claim and customize this page!

AdsRole WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

ADSROLE

adsrole.com

201-500 employees

Since 2017

COMPANY RANKING

ADSROLE

EVERGREEN INDEX #1722

RELATED COMPANIESRANK

STORIES ABOUT ADSROLE

Representing this company? Click here to claim and customize this page!

AdsRole WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!