cometchat-react-v7-production

Ground truth: @cometchat/chat-uikit-react@7. The auth-token / login API is FETCHED from the docs via cometchat-react-v7-core/references/docs-map.md (/ui-kit/react/integration-react + the JS SDK auth pages); the REST auth-token endpoint is {DOCS_BASE}/rest-api/auth-tokens. The React UI Kit docs have no single production-hardening page — this checklist is the pack's own guidance from RULES.md §4 (Credentials) + what the kit ships, labelled as such, not presented as documented. Tracked DOCS GAP.

Companion skills (read first)

• cometchat-react-v7-core — references/setup-credentials.md + references/lifecycle.md cover the dev credential flow this replaces and the init→login→render order.
• cometchat-react-v7-patterns — the per-bundler env prefix + build specifics referenced below.
• cometchat-security — the enterprise auth model this client-side hardening plugs into: wiring your IdP / SSO into the token flow (your IdP → your server → mint the CometChat auth token; CometChat is not an IdP), token expiry/refresh + re-login, RBAC roles + group (SBAC) scopes, and Auth Key vs auth token vs REST API Key. Load it for a security review or any SSO question.

Use this skill when

Moving off the development setup: going live, a security review, or "is this safe to ship."

The one thing that matters

Never ship the Auth Key in the browser bundle.

The Auth Key can mint a session for any user in your app. Every VITE_/NEXT_PUBLIC_/REACT_APP_/PUBLIC_-prefixed value is compiled into JavaScript your users download — so an Auth Key there is public. Anyone can read it, log in as any UID, and read every conversation.

The production login flow

1. Your app authenticates the user (your own auth — CometChat is not an identity provider).
2. Your server calls CometChat's REST API with the REST API Key to mint an auth token for that user's UID ({DOCS_BASE}/rest-api/auth-tokens).
3. The server returns the token to the browser over an authenticated request.
4. The app calls loginWithAuthToken(token).

// the endpoint derives the UID from the SERVER session — never from a query param
const res = await fetch("/api/cometchat-token", { credentials: "include" });
const { authToken } = await res.json();
await CometChatUIKit.loginWithAuthToken(authToken);

Accepting ?uid= (or any client-supplied UID) lets a caller impersonate anyone. The UID must come from the server-side session.

Env prefix — do NOT ship the key

Init reads the Auth Key from the client env in development. Production must set it empty and log in with a token instead. The prefix is bundler-specific (cometchat-react-v7-patterns): Vite VITE_, Next NEXT_PUBLIC_ (.env.local), CRA REACT_APP_, Astro PUBLIC_. App ID and Region are not secrets — they identify the app; the Auth Key is the secret. Grep the built bundle to be certain:

npm run build && grep -rll "<your-auth-key>" dist/ build/ .next/ 2>/dev/null && echo "LEAK" || echo "clean"

Run that in CI — a stray .env or a wrong prefix ships the key silently.

Also before launch

• Users are created server-side, as part of your signup — not from the browser (no createUser with the Auth Key in client code).
• Log out properly: await CometChatUIKit.logout(), then clear derived React state and unregister push tokens (cometchat-react-v7-push).
• HTTPS everywhere — required for calls (getUserMedia) and push.
• Pin the kit to an exact or ~ range so a minor cannot change component behaviour under you.
• Keep CometChatErrorBoundary wrapping the surface so a render error shows a fallback, not a white screen (it is not the initializer — init/login still run first).
• SSR/StrictMode: guard init+login so React 18/19 StrictMode's double-invoke does not race two logins (cometchat-react-v7-patterns); never init during SSR — gate on the client.
• Region must match the dashboard app in every build.
• Enable dashboard extensions/AI on the PRODUCTION app, not just dev.

Pre-launch checklist

• Auth Key absent from the production bundle (grep-verified in CI)
• loginWithAuthToken in production; UID from the server session
• REST API Key server-side only
• Correct env prefix for the bundler; .env gitignored
• HTTPS, valid certificate
• Logout clears session, React state and push tokens
• Kit version pinned; CometChatErrorBoundary in place
• Dashboard extensions/AI enabled for the production app
• Tested against the production app's credentials

Common pitfalls

1. Auth Key in the production bundle — the critical one; wrong env prefix is the usual cause.
2. Token endpoint trusting a client-supplied UID — impersonation.
3. Init/login run during SSR or twice under StrictMode — races and "already logged in" errors.
4. Dashboard configured on the dev app only — features silently missing in production.
5. No logout teardown — the next user inherits the session or the push token.

Verify it works

Production build contains no Auth Key (grep) · login works via token · a tampered UID is rejected by the server · logout fully clears · calls and push work over HTTPS · features enabled on the production app.