Skip to main content

Not logged in

CloudBase allows clients to access CloudBase resources without logging in. Developers can use security rules to restrict access to resources for unauthenticated users.

Activation Process​

Step 1: Enabling Unauthenticated Access​

Log in to the CloudBase console, and under Login Authorization, toggle the Unauthenticated Access option on or off.

Enable Unauthenticated Access

Step 2: Adding Security Domains (Optional)​

Log in to the CloudBase platform, and on the Security Sources page, add the domain to the list under Security Domains; otherwise, it will be identified as an unauthorized source.

Usage Process​

Step 1: Configure Custom Security Rules to Allow Unauthenticated Access​

You need to use custom security rules to allow resource access in unauthenticated mode.

Note

For security reasons, under the four basic permission settings, unauthenticated access is not allowed.

For example, you can set the cloud database permissions as follows:

{
    "read": "doc._openid==auth.openid || auth == null"
}

On the basis of the original private read condition doc._openid==auth.openid, it allows all unauthenticated users to read resources. For details, see Writing Security Rules.

Step 2: Initializing the SDK to Initiate a Call​

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

const app = cloudbase.init({
  env: 'xxxx-yyy';
});

After the SDK is initialized, you can initiate calls to cloud development resources.

Note
  1. tcb-js-sdk version 1.9.0 (inclusive) and later supports accessing resources in unauthenticated mode, while earlier versions must access resources within a valid login period;
  2. Data written in unauthenticated mode (cloud database, cloud storage) will become ownerless data, meaning it won't automatically contain corresponding identity identification fields.

Frequently Asked Questions​

  • What is the difference between anonymous login and not being logged in?

    From the perspective of end users:

    • Anonymous login and not being logged in have no difference in initial usage experience; neither requires registration.
    • In unauthenticated scenarios, private data cannot be generated; data is shared among all unauthenticated users, and individual users lack unique identifiers;
    • Compared with anonymous login, not being logged in cannot be converted to registered login, and data generated during unauthenticated sessions cannot be automatically transferred to registered user accounts.

    From the perspective of application developers:

    • The anonymous user generated by CloudBase anonymous login is essentially a valid user with a unique user ID, enabling the creation of private Cloud Database and Cloud Storage data, as well as the formulation of personalized access policies in conjunction with Security Rules;
    • Unauthenticated mode is purely for access without a login state; accesses under this mode will not be included in user tracking statistics.
    • Unauthenticated users cannot access any CloudBase services or resources under default permissions; access to required resources must be granted through security rules. Additionally, since the uniqueness of unauthenticated users cannot be determined, private data and personalized policies cannot be created within the developer's own service system.

  • Permission error occurs when accessing resources despite unauthenticated access being enabled

    Since unauthenticated access is a low-security, public access method, the system requires both enabling the unauthenticated access switch and explicitly granting access through security rules to ensure the security of developers' cloud resources. Only when both conditions are met can cloud resources be accessed in unauthenticated mode—these two steps are independent yet indispensable.