Permission Control

CloudBase permission control implements fine-grained permission management through a role system, addressing the question of "what resources users can access".

Go to CloudBase Platform/Authentication/Permission Control to view permission control.

Permission Model

CloudBase permission control is based on the Role-Policy model:

User → Role → Resource Permissions + Data Permissions + Operation Permissions

• Role: The carrier of permissions, assigning users to different roles
• Resource Permissions: What resources this role can access (data models, cloud functions, cloud storage, etc.)
• Data Permissions: What data can be accessed (all data, only data created by oneself, data under specific conditions)
• Operation Permissions: What operations can be performed (view, create, modify, delete)

Role System

System Roles

CloudBase provides five built-in system roles to meet common permission scenarios:

Role Type	Description	Typical Use Cases
Administrator	Has all permissions, can manage environments, members, resources	Project managers, technical leads
All Users	Includes all logged-in and non-logged-in users	Public content access control
Organization Members	Users added to the organizational structure	Internal enterprise application access
External Users	Non-anonymous logged-in users except organization members	C-end application users (e.g., e-commerce, social apps)
Anonymous Users	Visitors who are not logged in	Public pages, marketing landing pages

⚠️ Security Warning: The administrator role has the system's highest privileges (delete data, modify configuration, manage members, etc.), please use with caution. It is recommended to create custom roles with limited permissions for daily operations, and only use administrator accounts when necessary.

Custom Roles

When system roles cannot meet business needs, you can create custom roles to achieve more fine-grained permission control.

Creation Steps:

1. Visit CloudBase Platform/Authentication/Permission Control page
2. Click "Create Role"
3. Set role identifier and description (identifier is used for reference in code)
4. Configure resource access permissions for this role

Common Custom Role Examples:

Role Identifier	Role Name	Applicable Scenarios
content_editor	Content Editor	Managing content data like articles, products
data_analyst	Data Analyst	Viewing statistics and analysis reports
finance_admin	Finance Admin	Managing financial data like orders, transactions
customer_support	Customer Support	Handling user feedback and tickets

Multi-Role Permission Merging Rules

When a user has multiple roles, the final permissions are merged according to the following rules:

• Allow Permissions Union: User has the sum of allow permissions from all roles
• Deny Permissions Priority: Deny rules from any role override allow rules from other roles

Example:

User has both: Content Editor + Data Analyst

Role Permissions:
- Content Editor: Allow access to articles table (read, write, modify)
- Data Analyst: Allow access to orders table (read only)

Final Permissions:
- Can read and write all data in articles table
- Can view data in orders table (read only)

Member Management

Add users to roles to implement permission assignment.

Two Ways to Add Members

Method 1: Add Members in Role

1. Visit CloudBase Platform/Authentication/Permission Control page
2. Find the target role, click "Configure Members"
3. Click "Add Members" to batch select users
4. Takes effect immediately after confirmation

Method 2: Manage via Organization Structure

1. Visit CloudBase Platform/Authentication/Organization Structure page
2. Create department and position structure
3. Add users to corresponding organizational nodes
4. Batch associate roles for users

💡 Tip: The organization structure method is suitable for enterprise applications, allowing batch management of user permissions based on departments and positions.

Modify User Permissions

There are two ways to modify user permissions:

Modify Role Permissions

• Adjust resource and data permissions in the role's permission configuration
• All users under this role automatically inherit new permissions
• Suitable for batch adjustment of multiple users' permissions

Adjust User Roles

• Remove users from a role
• Or add users to new roles
• Suitable for permission adjustment of individual users

⚠️ Note: Permission changes may take some time to take effect. It is recommended that users log out and log back in to immediately apply new permissions.

Permission Configuration

Configure specific access permissions for roles, including three dimensions: resource permissions, data permissions, and operation permissions.

Resource Permissions

Resource permissions determine which CloudBase resources a role can access.

Configuration Steps:

1. Click "Configure Permissions" in the role card
2. Select "Add Custom Policy"
3. Select the resource type and specific resources to authorize

Supported Resource Types:

Resource Type	Description	Typical Application Scenarios
Data Model	NoSQL database collections	User data, content management
MySQL Database	Relational database	Complex business data
Cloud Functions	Backend business logic	API calls, data processing
Cloud Storage	File storage	Image, video, document uploads

Data Permissions

Data permissions control what data a role can access, supporting both row-level and column-level dimensions.

Row-Level Permissions (Data Rows)

Control which data rows users can access to achieve data isolation.

Common Configuration Methods:

Permission Type	Description	Applicable Scenarios
All Data	Access all data rows	Administrators, data analysts
Own Data Only	Only access self-created data	Regular users, personal data management
Specific Condition Data	Data meeting specific conditions (e.g., department)	Department managers, regional heads

Configuration Example:

Practical Applications:

• Sales staff can only view customer data they are responsible for
• Department managers can view all data in their department
• Regional managers can view data for their responsible regions

Column-Level Permissions (Data Columns)

Control which fields (columns) users can access to hide sensitive information.

Configuration Options:

• Readable Fields: List of fields users can view
• Hidden Fields: Sensitive fields not visible to users

Configuration Example:

Practical Applications:

• Hide cost and profit fields from sales staff
• Hide user phone numbers and ID numbers from customer service staff
• Hide salary and performance data from regular employees

💡 Tip: Row-level and column-level permissions can be used together to achieve more fine-grained data access control.

Operation Permissions

Configure specific operation permissions for roles on resources.

Basic Operation Types:

Operation Type	English Identifier	Description
View	Read	Read data, query records
Create	Create	Add data, insert records
Modify	Update	Edit data, update records
Delete	Delete	Delete data, remove records

Configuration Notes:

Different resource types support different operation permissions. For specific configuration methods, please refer to the corresponding resource documentation:

• Document Database Permissions - NoSQL database permission configuration
• MySQL Database Permissions - Relational database permission configuration
• Cloud Function Permission Control - Cloud function invocation permission configuration

Typical Application Scenarios

Scenario 1: Personal Blog Website

Requirement Analysis

A personal blog needs to support three roles: visitors browsing, users commenting, and bloggers managing.

Role Planning

Role	Permission Scope	Target Users
Anonymous Users	Browse articles, view comments	All visitors
Registered Users	Browse articles, post comments, like	Registered readers
Administrator	Publish articles, manage comments, site settings	Blog owner

Data Permission Configuration

Article Table (blog_articles):

Role	View Permission	Create Permission	Modify Permission	Delete Permission
Anonymous Users	Published articles	❌	❌	❌
Registered Users	Published articles + drafts	✅	Only own drafts	Only own drafts
Administrator	All articles	✅	✅	✅

Comment Table (comments):

Role	View Permission	Create Permission	Modify Permission	Delete Permission
Anonymous Users	All comments	❌	❌	❌
Registered Users	All comments	✅	Only own comments	Only own comments
Administrator	All comments	✅	✅	✅

Implementation Steps

1. Enable Anonymous Login

Enable "Allow Anonymous Login" in Login Methods Management.

2. Configure Database Permissions

Configure access permissions for corresponding roles in the database collection's permission settings, refer to Document Database Permissions.

3. Frontend Call Anonymous Login

import cloudbase from '@cloudbase/js-sdk';

const app = cloudbase.init({
  env: 'your-env-id'
});

const auth = app.auth();

// Execute anonymous login on page load
auth.signInAnonymously().then(() => {
  console.log('Anonymous login successful');
});

Scenario 2: Enterprise Internal Management System

Requirement Analysis

Enterprise management systems need to distinguish access permissions for different departments and positions to achieve data isolation and fine-grained management.

Role Planning

Create Custom Roles:

1. Visit Permission Control page
2. Click "Create Role" to create the following roles:

Role Identifier	Role Name	Permission Scope
content_editor	Content Editor	Manage content data like articles, products
data_analyst	Data Analyst	View statistics and analysis reports
finance_admin	Finance Admin	Manage financial data like orders, transactions
dept_manager	Department Manager	Manage department data and members

Data Permission Configuration

Row-Level Permission Example

Configure "users can only access data from their own department":

Column-Level Permission Example

Hide sensitive fields (e.g., cost, profit):

Implementation Steps

1. Create Organization Structure

Create department structure in Organization Structure.

2. Configure Role Permissions

Configure resource permissions and data permissions (row-level + column-level) for each role.

3. Assign User Roles

Add users to corresponding departments and associate corresponding roles.

Scenario 3: Collaborative Editing Platform

Requirement Analysis

A multi-person collaborative document editing platform allows users to edit documents created by others, requiring strict permission control.

Role Planning

Role	Permission Scope	Target Users
Regular Users	View all documents, edit own documents	Registered users
Collaborators	View all documents, edit authorized documents	Invited users
Administrator	Full permissions for all documents (view, edit, delete)	Team managers

Implementation Plan

⚠️ Security Warning: Allowing modification of others' data is a high-risk operation and must implement strict permission verification.

Solution 1: Modify Data via Cloud Functions (Recommended)

Cloud functions execute on the server side and can bypass client-side permission restrictions, but strict permission verification must be implemented inside the function:

// Cloud Function: editDocument
const cloudbase = require('@cloudbase/node-sdk');
const app = cloudbase.init();
const db = app.database();

exports.main = async (event, context) => {
  const { documentId, newContent } = event;
  const { userInfo } = context;
  
  // 1. Verify user login status
  if (!userInfo || !userInfo.uid) {
    return { code: 401, message: 'Not logged in' };
  }
  
  // 2. Query document information
  const doc = await db.collection('documents')
    .doc(documentId)
    .get();
  
  if (!doc.data || doc.data.length === 0) {
    return { code: 404, message: 'Document not found' };
  }
  
  const document = doc.data[0];
  
  // 3. Permission verification: Check if author or collaborator
  const isOwner = document._openid === userInfo.openid;
  const isCollaborator = document.collaborators && 
    document.collaborators.includes(userInfo.uid);
  
  if (!isOwner && !isCollaborator) {
    return { code: 403, message: 'No permission to edit this document' };
  }
  
  // 4. Execute update
  const result = await db.collection('documents')
    .doc(documentId)
    .update({
      content: newContent,
      lastEditBy: userInfo.uid,
      lastEditAt: new Date()
    });
  
  return { code: 0, message: 'Update successful', data: result };
};

Solution 2: Configure via Security Rules (Fine-Grained Control)

For scenarios requiring more complex and fine-grained permission control, you can use the security rules feature.

CloudBase Resources Supporting Security Rules:

Resource Type	Security Rules Documentation	Applicable Scenarios
Document Database	Database Security Rules	Document-level, field-level permission control
Cloud Storage	Cloud Storage Security Rules	File upload, download, delete permission control
Cloud Functions	Cloud Function Security Rules	Function invocation permission control

Implementing Collaborative Editing Using Security Rules:

{
  // Read permission: All logged-in users can view documents
  "read": "auth != null",
  
  // Write permission: Author, collaborators, or administrators can edit
  "write": "doc._openid == auth.openid || doc.collaborators.includes(auth.uid) || auth.role == 'admin'"
}

💡 Tip: Security rules take effect at the database layer, allowing complex permission control logic without writing cloud functions.

Security Best Practices

Cautious Use of Administrator Privileges

⚠️ Security Warning: The administrator role has the system's highest privileges (delete data, modify configuration, manage members, etc.). Incorrect operations can lead to serious consequences.

Recommended Practices:

1. Minimize Number of Administrators: Only grant administrator privileges to necessary personnel
2. Create Daily Roles: Create custom roles with limited permissions for daily operations
3. Separate Permissions: Divide roles of different permission levels based on responsibilities
4. Regular Audits: Regularly check the list of administrator accounts and remove unnecessary permissions
5. Enable Two-Factor Authentication: Enable additional security verification for administrator accounts

Principle of Least Privilege

Follow the "principle of least privilege", only granting users the minimum permissions needed to complete their work.

Correct Practices:

✅ Sales staff can only view and edit customer data they are responsible for
✅ Customer service staff can only view ticket information but cannot view users' payment information
✅ Data analysts can only view data (read-only permission), cannot modify or delete

Practices to Avoid:

❌ Sales staff can view all customer data
❌ Customer service staff have full access to user information
❌ Granting regular employees administrator privileges for "convenience"

Sensitive Data Protection

For sensitive data, multi-layer protection is recommended:

1. Column-Level Permissions: Hide sensitive fields (e.g., ID numbers, bank card numbers)
2. Data Masking: Mask sensitive information during display
3. Audit Logs: Record all access and modification operations on sensitive data
4. Regular Audits: Regularly review sensitive data access permission configurations

Permission Change Management

Before Permission Changes:

1. Evaluate impact scope to ensure changes won't affect normal business operations
2. Verify correctness of permission configuration in test environment
3. Notify relevant users of upcoming permission adjustments

After Permission Changes:

1. Verify if permission configuration has taken effect
2. Recommend users log out and log back in to immediately apply new permissions
3. Monitor for permission-related errors or anomalies

FAQ

Q1: User has been granted permissions but still cannot access resources?

Troubleshooting Steps:

1. Check Role Assignment

   • Confirm user has been correctly assigned to target role
   • View user's role list in User Management

2. Check Policy Configuration

   • Confirm policy has been saved and associated with correct role
   • View role's policy configuration in Permission Control

3. Check Permission Effective Time

   • Permission changes may take some time to take effect
   • Recommend users log out and log back in to immediately apply new permissions

4. Check Gateway Policy

   • May be blocked by gateway layer restrictions
   • Check gateway permission policies associated with the user

5. View Specific Error Information

   • Check client or server-side error logs
   • Resolve issues based on error codes

Q2: How are permissions merged when a user has multiple roles?

When a user has multiple roles, permission merging follows these rules:

Permission Merging Rules:

• Allow Permissions Union: User has the sum of allow permissions from all roles
• Deny Permissions Priority: Deny rules from any role override allow rules from other roles

Example:

User has both: Content Editor + Data Analyst

Role Permissions:
- Content Editor: Allow access to articles table (read, write, modify)
- Data Analyst: Allow access to orders table (read only), deny deleting articles table

Final Permissions:
- Can read and write articles table, but cannot delete articles (deny rule priority)
- Can view data in orders table (read only)

Q3: How to implement "users can only view data from their own department"?

Use row-level permissions configuration to achieve data isolation:

Implementation Steps:

1. Add department field in data table to record the department the data belongs to
2. Add department field in user information to record the user's department
3. When configuring data permissions, set row-level permission rule: doc.department == user.department

Reference Configuration:

Q4: What's the difference between security rules and role permissions?

Role Permissions (Role-based Access Control):

• Role-based permission management
• Suitable for enterprise applications, supports organizational structure
• Visual configuration in console
• Suitable for most common scenarios

Security Rules:

• Expression-based document-level permission control
• Supports more complex permission logic (e.g., permission judgment based on data content)
• Requires writing rule expressions
• Suitable for scenarios requiring fine-grained control

Recommended Approach:

• Prioritize using role permissions to meet basic needs
• For complex scenarios, combine security rules for more fine-grained control
• Role permissions and security rules can be used together, final permissions are the intersection of both

Q5: How to manage user permissions in batch?

Method 1: Batch Management via Organization Structure

1. Create department structure in Organization Structure
2. Add users to corresponding departments
3. Uniformly configure roles for departments, all users in the department automatically inherit role permissions

Method 2: Modify Role Permissions

1. Find the role that needs adjustment
2. Modify the permission configuration for this role
3. All users under this role automatically apply new permissions

Method 3: Batch Operations Using HTTP API

For large-scale user permission management, you can use CloudBase HTTP API for batch operations, refer to HTTP API Documentation.

Related Documentation

Authentication Related:

• Authentication Overview - Understand CloudBase authentication system
• Manage Users - User information management and account operations
• Login Methods Management - Configure and enable different login methods
• JS SDK (V2) Authentication - Web-side authentication API
• HTTP API Authentication Interface - HTTP API authentication

Data Permissions Related:

• Document Database Permissions - NoSQL database permission management
• Database Security Rules - Document-level permission control
• MySQL Database Permissions - Relational database permission management

Resource Permissions Related:

• Cloud Function Permission Control - Cloud function invocation permission management
• Cloud Storage Permission Management - File storage permission control