Guidelines
- Introduction
- Installation
- Quick Start
Guides
- Introductions
- Build local test node
- Smart Contract - ABI Files
- Smart Contract——JS Contract
- Deploy Contracts
- Test Contract
- Develop DApp Client
Smart Contracts
- Contract Introduction
- ABI File
- Database
- Account Authority
- Call In-contract
- Notification
System Contracts
- Resources
- Account
- Permission
Token Contracts
- Transfer
- Token
- Token Exchange
- Contract Sub-Wallet
Node Guide
- Node Introduction
- Add to nodes network
- Node Data Persistence
Access Guide
- FO 接入安全指南
Account Authority
As with all system designs, we also need to validate the rights of accounts in the development of smart contracts. Several functions are provided in the action module to meet our requirements.
Verify the existence of an account
Before verifying account permissions, we can confirm the validity of the account. The is_account
function of the action module can be used to easily implement this.
1 | exports.hi = account => { |
Verify Account Authorization
Just as the traditional system needs to check the user’s login status, the authorization of user accounts can also be checked in the development of smart contracts. We can use the has_auth
function to check whether action
requires authorization for specified account.
1 | exports.hi = account => { |
Verify account permissions
If is only verification of account authorization, the require_auth
function in the action module can achieve a similar effect as has_auth
. But the two are different.
- If
Has_auth
verification sees theres no specific account authorization verification, it returns a Boolean value offalse
. Whenrequire_auth
fails to add a specified account, an exception is thrown and the contract is withdrawn after execution is interrupted. The require_auth
function checks not only whether the account is authorized, but also whether the account provides the corresponding permissions.
FIBOS accounts have two privileges: owner
、active
。
owner
Super privileges, represents the owner of the account, because the owner of this privilege can be used to operate other privilege configurations, which are not commonly used in transactions (transfer, contract action, etc.).active
Common business authority, such as: transfer, voting, etc.
In the following code example, if the client invokes the contract method hi
, the contract throws an exception and interrupts execution without providing authorization for the account corresponding to the passed parameter account
.
1 | exports.hi = account => { |
In the following code example, require_auth
requires active
permissions of account
corresponding accounts. Otherwise, an exception will be thrown and execution will be interrupted.
1 | exports.hi = account => { |
Of course, in addition to the default two privileges, developers can also add custom privileges to the account, and then validate them in the contract.