$npx -y skills add TencentCloudBase/cloudbase-skills --skill auth-webCloudBase Web Authentication Quick Guide for frontend integration after auth-tool has already been checked. Provides concise and practical Web authentication solutions with multiple login methods and complete user management.
| 1 | ## Standalone Install Note |
| 2 | |
| 3 | If this environment only installed the current skill, start from the CloudBase main entry and use the published `cloudbase/references/...` paths for sibling skills. |
| 4 | |
| 5 | - CloudBase main entry: `https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/SKILL.md` |
| 6 | - Current skill raw source: `https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/auth-web/SKILL.md` |
| 7 | |
| 8 | Keep local `references/...` paths for files that ship with the current skill directory. When this file points to a sibling skill such as `auth-tool` or `web-development`, use the standalone fallback URL shown next to that reference. |
| 9 | |
| 10 | ## Activation Contract |
| 11 | |
| 12 | ### Use this first when |
| 13 | |
| 14 | - 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. |
| 15 | |
| 16 | ### Read before writing code if |
| 17 | |
| 18 | - The user needs a login page, auth modal, session handling, or protected Web route. Read `auth-tool` first to ensure providers are enabled, then return here for frontend integration. |
| 19 | |
| 20 | ### Then also read |
| 21 | |
| 22 | - `../auth-tool/SKILL.md` (standalone fallback: `https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/auth-tool/SKILL.md`) for provider setup |
| 23 | - `../web-development/SKILL.md` (standalone fallback: `https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/web-development/SKILL.md`) for Web project structure and deployment |
| 24 | |
| 25 | ### Do not start here first when |
| 26 | |
| 27 | - The request is a Web auth flow but provider configuration has not been verified yet. |
| 28 | - In that case, activate `auth-tool-cloudbase` before `auth-web-cloudbase`. |
| 29 | |
| 30 | ### Do NOT use for |
| 31 | |
| 32 | - Mini program auth, native App auth, or server-side auth setup. |
| 33 | |
| 34 | ### Common mistakes / gotchas |
| 35 | |
| 36 | - Skipping publishable key and provider checks. |
| 37 | - Replacing built-in Web auth with cloud function login logic. |
| 38 | - Reusing this flow in Flutter, React Native, or native iOS/Android code. |
| 39 | - 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. |
| 40 | - Using `signInWithEmailAndPassword` or `signUpWithEmailAndPassword` for username-style accounts such as `admin` and `editor`. |
| 41 | - Keeping the login or register account input as `type="email"` when the task explicitly says the account identifier is a plain username string. |
| 42 | - Starting implementation before calling `queryAppAuth(action="getLoginConfig")` and enabling `usernamePassword` when it is still off. |
| 43 | - **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. |
| 44 | - **Treating `auth.getUser()` or deprecated `auth.getLoginState()` as proof of real login.** When the SDK is initialized with `accessKey`, the deprecated `getLoginState()` returns an object with a valid `uid` even without any login — causing route guards that check `!!loginState` or `!!uid` to incorrectly pass. The fix is to 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. |
| 45 | - **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`. |
| 46 | |
| 47 | Note: anonymous login is now **disabled by default** for new environments and inactive existing environments. Always use `auth.getSession()` for auth guards. |
| 48 | |
| 49 | ## Overview |
| 50 | |
| 51 | **Prerequisites**: CloudBase environment ID (`env`) |
| 52 | **Prerequisites**: CloudBase environment Region (`region`) |
| 53 | |
| 54 | --- |
| 55 | |
| 56 | ## Core Capabilities |
| 57 | |
| 58 | **Use Case**: Web frontend projects using `@cloudbase/js-sdk@latest` for user authentication |
| 59 | **Key Benefits**: **Supabase-compatible Auth API** — all methods return `{ data, error }`, supports ph |