Authorization

Advanced AccessRules

The Authorization section of this documentation repeatedly uses the rule!(…) macro to define an “access rule” - most often, a simple one (i.e. “require the caller to hold a certain resource”). H

Assign Component Roles

The conditions for proving if a caller has a role is defined by an AccessRule. During component instantiation each role defined for the blueprint will be assigned an AccessRule. Each AccessRule de

Assign Component Royalty Roles

Components may optionally include Component Royalties. If so, a set of component royalty roles will be defined for that component:

Assign Function AccessRules

To specify the access rules for each function use the enablefunctionauth! macro at the top of your blueprint code.

Assign Metadata Roles

Every component has Metadata and a set of Metadata Roles:

Assign Roles To Methods

Methods, unlike functions, use roles to further structure how AccessRules are assigned.

Assign Roles To Resources

There are a fixed selection of roles for resources. These roles belong to each of their behaviours. You can find out more about these behaviours, their associated roles and how to assign them in Reso

Authorization

Authorization is the process of giving a caller the ability to call a method or function. Traditional blockchains often use the caller's address for this purpose (like msg.sender in Solidity) and re

Call a Protected Method/Function

To call a protected method or function, you must show proof that you can pass some AccessRule. For protected methods, this AccessRule can be any access rule assigned to a role which has permission to

Using Proofs

Proofs give us a way to tell if a resource exists in a Vault or Bucket without having to remove it. A Proof can be created from a resource and used instead, which allows us to know if an actor possess