Auth Web Cloudbase

Sibling skills (local only)

Sibling CloudBase skills ship beside this skill. Use local relative paths such as ../auth-tool-cloudbase/SKILL.md.

If a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do not HTTP-fetch remote skill or protocol markdown into the agent context.

Activation Contract

Use this first when

• The task is a CloudBase Web login, registration, session, or user profile flow built with @cloudbase/js-sdk and the auth provider setup has already been checked.

Read before writing code if

• The user needs a login page, auth modal, session handling, or protected Web route. Read auth-tool-cloudbase first to ensure providers are enabled, then return here for frontend integration.

Then also read

• ../auth-tool-cloudbase/SKILL.md for provider setup
• ../web-development/SKILL.md for Web project structure and deployment

Do not start here first when

• The request is a Web auth flow but provider configuration has not been verified yet.
• In that case, activate auth-tool-cloudbase before auth-web-cloudbase.

Do NOT use for

• Mini program auth, native App auth, or server-side auth setup.

Common mistakes / gotchas

• Skipping publishable key and provider checks.

• Replacing built-in Web auth with cloud function login logic.

• Reusing this flow in Flutter, React Native, or native iOS/Android code.

• Creating a detached helper file with auth.signUp / verifyOtp but never wiring it into the existing form handlers, so the actual button clicks still do nothing.

• Using signInWithEmailAndPassword or signUpWithEmailAndPassword for username-style accounts such as admin and editor.

• Keeping the login or register account input as type="email" when the task explicitly says the account identifier is a plain username string.

• Starting implementation before calling queryAppAuth(action="getLoginConfig") and enabling usernamePassword when it is still off.

• Writing auth.signInWithPassword(...) or auth.signUp(...) code without first confirming the provider is enabled via MCP. Before writing any sign-in or sign-up code in the browser, call queryAppAuth(action="listProviders") to verify the target provider (e.g. email, phone, usernamePassword) has On: "TRUE". For email-based sign-up (auth.signUp({ email, password })), additionally confirm SMTP is configured — otherwise the provider may throw "provider email not found" or similar errors. For username/password login, use auth.signInWithPassword({ username, password }); registration is best done through the management API (manageAppAuth(action="createUser")) or by confirming email provider readiness first.

• Treating auth.getUser() or deprecated auth.getLoginState() as proof of real login. When the SDK is initialized with accessKey, the deprecated getLoginState() may still return an object with a valid uid even without any login — causing route guards that check !!loginState or !!uid to incorrectly pass. That misleading uid is not a gateway-authenticated session. Use auth.getSession() instead: it returns data.session === undefined when no real login has occurred. Only !!data.session from getSession() is a reliable authentication check.

• Assuming publishable accessKey alone is enough for NoSQL CRUD. NoSQL app.database() get / add / update / watch requires a gateway-authenticated session: use a real login (password / OTP / OAuth). Anonymous login is a demo-only escape hatch for explicitly-public, non-user data — it is disabled by default, denied AI model permissions, and must never stand in for real auth in user-scoped apps. Skipping any login yields gateway 401. checkLogin() / getSession() alone do not create a usable write session.

• Copying old CloudBase auth snippets from training data. Do not use auth.getLoginState(), auth.hasLoginState(), auth.getCurrentUser(), or auth.toDefaultLoginPage() as the default Web flow. Use the Web SDK v3 auth methods in this file and provider readiness from auth-tool-cloudbase.

• Calling a standalone auth.verifyOtp({ token }) for OTP login. CloudBase Web SDK v3 returns verifyOtp as a callback on the signInWithOtp / signUp result: send the code first, keep the returned data, then call data.verifyOtp({ token }). A standalone auth.verifyOtp({ token }) without messageId fails with "messageId is required" — seeing that error means the callback form was skipped. See references/extended-guide.md for the full send → save callback → verify flow.

  Note: anonymous login is disabled by default for new environments and inactive existing environments. Do not enable it to work around permission errors — enable via auth-tool-cloudbase only when the app explicitly serves public non-user data (e.g. NoSQL read-only demos). Always use auth.getSession() for auth guards.

Overview

Prerequisites: CloudBase environment ID (env) Prerequisites: CloudBase environment Region (region)

Core Capabilities

Use Case: Web frontend projects using @cloudbase/js-sdk@latest for user authentication
Key Benefits: Supabase-compatible Auth API — all methods return { data, error }, supports phone, email, anonymous (disabled by default), username/password, OAuth, and third-party login methods

📌 Supabase API Compatibility: CloudBase Web SDK v3 auth module is designed with Supabase-like API ergonomics. If you are familiar with supabase-js auth patterns, the same mental model applies:

• All methods return Promise<{ data, error }> — always check error first
• signInWithPassword, signInWithOtp, signUp, signOut, getSession, getUser follow the same naming as Supabase
• onAuthStateChange(callback) provides reactive auth state observation (events: INITIAL_SESSION, SIGNED_IN, SIGNED_OUT, TOKEN_REFRESHED, USER_UPDATED, PASSWORD_RECOVERY, BIND_IDENTITY)
• Session management via getSession() / refreshSession() / setSession() mirrors Supabase patterns

Key differences from Supabase:

• OTP verification: Supabase uses a standalone auth.verifyOtp({ phone, token, type }) call; CloudBase returns verifyOtp as a callback on data — call data.verifyOtp({ token }) from the signInWithOtp / signUp result
• accessKey replaces Supabase's anonKey; environment uses env + region instead of Supabase's url
• signInWithIdToken for direct third-party token login (similar to Supabase's same-named method)

Use npm installation for modern Web projects. In React, Vue, Vite, and other bundler-based apps, install and import @cloudbase/js-sdk from the project dependencies instead of using a CDN script.

Prerequisites

• Automatically use auth-tool-cloudbase to check app-side auth readiness via queryAppAuth / manageAppAuth, then get the publishable key and configure login methods.
• Publishable key readiness (do not skip): call queryAppAuth(action="getPublishableKey"). If it is empty, call manageAppAuth(action="ensurePublishableKey") first — new environments may not have one provisioned, and skipping this step leaves the frontend without a data-plane credential, surfacing later as gateway auth failures instead of an obvious missing-key error.
• Persist the key, don't hoard it in conversation: after retrieval, write the publishable key to .env.local as VITE_PUBLISHABLE_KEY (create the file if missing) and read it in client code via import.meta.env.VITE_PUBLISHABLE_KEY. Never hardcode the key into source files, and never ask the user to fetch it from the console — fall back to the console link below only if both MCP calls fail.
• If auth-tool-cloudbase failed, let user go to https://tcb.cloud.tencent.com/dev?envId={env}#/env/apikey to get publishable key and https://tcb.cloud.tencent.com/dev?envId={env}#/identity/login-manage to set up login methods