The security rule is a more advanced, flexible, and scalable method of permission control based on basic permission control. It consists of identity authentication, authorization, and security rule expressions.
Cloud storage security rules can be used to determine who has read and write permissions for files stored in cloud buckets, and can also be used for verification of metadata contained in files.
Note:
You can configure security rule permissions for cloud storage in the CloudBase (TCB) console.
The TCB console and server side always have read/write permissions to all files. The configuration of security rules is only valid for requests initiated by the client (mini program or Web).
Modify and update the security rules. It takes 1-3 minutes for permissions to take effect. Please wait patiently.
Before publishing, ensure your rules are evaluated to provide your application with the required higher level of security. If you set the rule to public when publishing your applications, it may lead to unexpected or unauthorized access to your stored data.
Basic Permission Control and Cloud Storage Security Rules
Cloud storage provides basic permission control, with a default value of "all users can read; only the creator can read and write". It can be obtained through security rule permission control.
|
All users can read; only the creator and administrator can write. | { "read": true, "write": "resource.openid == auth.openid", "write": "resource.openid == auth.uid" }
|
Only the creator and administrator can read and write. | { "read": "resource.openid == auth.openid", "read": "resource.openid == auth.uid", "write": "resource.openid == auth.openid", "write": "resource.openid == auth.uid" }
|
All users can read; only the administrator can write. | { "read": true, "write": false }
|
Only the administrator can read and write. | { "read": false, "write": false }
|
Identity Verification
Identity verification can be achieved through cloud storage security rules combined with integrated user authentication, and developers can perform precise resource access control based on user identity information.
Example
When a C-end user logs in, the auth variable in the security rule becomes an object containing the user's unique ID (auth.uid) and login method (auth.loginType). Conversely, if the user does not log in, the value of auth is null. Data access control for each user can be performed through the auth rule.
When an authenticated user initiates a request, the system will populate the auth variable using the user's unique ID uid and login method loginType.
Through the auth variable, control file access based on identity using the following commonly used methods:
Public: no judgment on the auth value.
Public only to logged-in users: Check whether the value of auth is null.
User-private: Check whether auth.uid is equal to the resource openid.
Only perform checks for a specific login method, restricting access for anonymous login users by checking whether the value of auth.loginType is ANONYMOUS.
Authorization
Identifying user identity is only part of the security work. After knowing the user's identity, developers need a method to control the access permissions of users to files in cloud storage.
Note:
Cloud storage supports bucket-level authorization rules allowing you to set security rule expressions to restrict read and write operations for all files in the cloud storage space.
Security Rule Expressions
Security rule expressions are described using json, allowing for the execution of read and write operations when certain conditions are met. An example configuration is as follows:
{
"read": boolean | condition expression string,
}
The key of the json configuration indicates the user's operation type, while the value is an expression. When the result of executing the expression is true, the user's operation is allowed; otherwise, the operation is not allowed.
|
| Read files. For example: download. | |
| Upload/Overwrite files or delete files. | |
The context on which rule verification is based is obtained through the auth and resource objects, providing verifiable identity context information (auth.uid) and object ownership (resource.openid).
{
"read": "auth.uid == resource.openid",
"write": "auth != null"
}
Example
Public
Any rule that does not consider auth can be deemed as a public rule, since it ignores the user's identity authentication context. These rules are applicable to scenarios presenting public data (static resource content).
{
"read": "resource.openid != null"
}
Public to Logged-In Users
In some cases, you may want to restrict access so that only logged-in users can access user data. For example, only logged-in users can view discussions in the forum. Since the values of all unauthenticated users' auth variables are null, the following rule can be set:
{
"read": "auth != null"
}
User-Private
auth The most common use case is to provide fine-grained access control for individual user resources, such as uploading private photos. Cloud storage files include file owner information (unique ID of the user), and access rules can be restricted as follows:
{
"read": "auth.uid == resource.openid",
"write": "auth.uid == resource.openid"
}
Practical Case
In a photo application, all logged-in users are able to upload and browse images in the gallery, while unauthorized users should not have access. However, anonymous login users should be allowed to browse images only, with the restriction that they cannot upload images. The following rules can be set for storage to achieve this:
{
"read": "auth != null",
"write": "auth.loginType != 'ANONYMOUS' && auth.openid == resource.openid"
}