Production readiness for CometChat — server-side token auth, user management CRUD, environment hardening, and security checklist. Replaces dev-mode authKey with server-side tokens.
Instalação
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Production readiness for CometChat — server-side token auth, user management CRUD, environment hardening, and security checklist. Replaces dev-mode authKey with server-side tokens.
{"author":"CometChat","version":"3.0.0","tags":"cometchat production auth token security user-management rest-api"}
Purpose
This skill teaches Claude how to harden a CometChat integration for production. It covers two critical areas:
Token-based authentication — replacing client-side authKey with server-side token generation
User management — server-side CRUD for CometChat users (create on signup, update on profile change, delete on account deletion)
The cometchat-core skill's provider pattern supports both dev mode (login(uid)) and production mode (loginWithAuthToken(token)). This skill provides the server-side half: the token endpoint and user management endpoints.
1. Why production auth matters
In development mode, CometChatUIKit.login(uid) uses the authKey configured via UIKitSettingsBuilder.setAuthKey(). This key is embedded in your client-side JavaScript bundle. Anyone can open browser DevTools, find the auth key, and use it to log in as ANY user in your CometChat app. They can read private messages, send messages as other users, and access every conversation.
Production deployments MUST use server-side token generation. The auth key stays on your server. Clients receive short-lived tokens scoped to a single user. If a token leaks, the blast radius is one user session, not your entire app.
2. The token auth pattern
The production auth flow has four steps:
Client authenticates with YOUR auth system. The user logs into your app using your existing login flow (email/password, OAuth, magic link, etc.). This step has nothing to do with CometChat.
Your server calls the CometChat REST API. After verifying the user's identity, your server makes a POST request to CometChat's token endpoint using the REST API key (a server-only secret). CometChat returns an auth token for that specific user.
Client receives the token. Your server sends the auth token back to the client in the API response.
Client calls CometChatUIKit.loginWithAuthToken(token). The CometChat SDK uses the token to establish a session. The auth key NEVER touches the browser.
Receives a user UID (from the authenticated session, NOT from the request body in production)
Validates that the caller is authenticated
POSTs to https://{APP_ID}.api-{REGION}.cometchat.io/v3/users/{uid}/auth_tokens
Returns the auth token to the client
The CometChat REST API requires two headers:
appId — your CometChat app ID
apiKey — a REST API Key (NOT the Auth Key used in dev mode)
Auth Key vs REST API Key — these are different keys:
Key type
Where to find
Purpose
Security
Auth Key
Dashboard → Your App → API & Auth Keys → "Auth Keys" table
Client-side SDK: CometChatUIKit.login(uid) in dev mode
Exposed in browser. Dev only.
REST API Key
Dashboard → Your App → API & Auth Keys → "Rest API Keys" table
Server-to-server: token generation, user CRUD, message send
Server only. Never expose to client.
The .env should have both for production:
# Client-side (prefixed for the framework)
VITE_COMETCHAT_APP_ID=your_app_id
VITE_COMETCHAT_REGION=us
# Server-side (no prefix — never exposed to the client)
COMETCHAT_APP_ID=your_app_id
COMETCHAT_REGION=us
COMETCHAT_REST_API_KEY=your_rest_api_key
If the user only has an Auth Key, tell them to create a REST API Key in the dashboard: API & Auth Keys → Rest API Keys → Add Key.
Next.js App Router
app/api/cometchat-token/route.ts
import { NextRequest, NextResponse } from"next/server";
constAPP_ID = process.env.COMETCHAT_APP_ID!;
constREGION = process.env.COMETCHAT_REGION!;
constREST_API_KEY = process.env.COMETCHAT_REST_API_KEY!;
exportasyncfunctionPOST(request: NextRequest) {
// TODO: Replace this with your real auth check.// Example with NextAuth: const session = await getServerSession(authOptions);// Example with Clerk: const { userId } = auth();// If not authenticated, return 401.const body = await request.json();
const uid = body.uidasstring;
if (!uid || typeof uid !== "string") {
returnNextResponse.json({ error: "Missing uid" }, { status: 400 });
}
// In production, derive UID from the authenticated session, not from// the request body. The body approach is shown here as a starting point.// Example: const uid = session.user.id;const response = awaitfetch(
`https://${APP_ID}.api-${REGION}.cometchat.io/v3/users/${encodeURIComponent(uid)}/auth_tokens`,
{
method: "POST",
headers: {
"Content-Type": "application/json",
appId: APP_ID,
apiKey: REST_API_KEY,
},
body: JSON.stringify({}),
}
);
if (!response.ok) {
const error = await response.text();
console.error("CometChat token error:", error);
returnNextResponse.json(
{ error: "Failed to generate auth token" },
{ status: response.status }
);
}
const data = await response.json();
returnNextResponse.json({ authToken: data.data.authToken });
}
functionChatWrapper() {
// Get the authenticated user's ID from your auth systemconst { user } = useAuth(); // Your auth hook (NextAuth, Clerk, Supabase, etc.)const { token, error, loading } = useCometChatToken(user?.id ?? null);
if (!user) return<LoginPage />;
if (loading) return<div>Connecting to chat...</div>;
if (error) return<div>Chat connection failed: {error}</div>;
return (
<CometChatProviderappId={import.meta.env.VITE_COMETCHAT_APP_ID}region={import.meta.env.VITE_COMETCHAT_REGION}authToken={token!}uid={user.id}
><ChatPage /></CometChatProvider>
);
}
Key changes:
Removed authKey prop entirely
Added authToken prop with the token from your server
uid comes from your auth system, not a hardcoded test user
The provider only renders after the token is fetched
Step 3 — Handle token refresh on 401
CometChat auth tokens expire. When a token expires, SDK calls will fail. Handle this in your provider:
// In your CometChatProvider or a wrapper:import { CometChat } from"@cometchat/chat-sdk-javascript";
// Listen for auth errorsCometChat.addConnectionListener(
"auth-refresh-listener",
newCometChat.ConnectionListener({
onDisconnected: () => {
console.log("CometChat disconnected — token may have expired");
// Re-fetch token from your endpoint and call loginWithAuthToken again
},
})
);
A simpler approach: if any CometChat operation returns a 401 or auth error, re-fetch the token and call CometChatUIKit.loginWithAuthToken(newToken).
Guard refresh calls with the same concurrency pattern. If two components both see a 401 at the same time, two loginWithAuthToken calls race and the SDK throws "Please wait until the previous login request ends." Route token refresh through the same ensureLoggedIn(uid, authToken) helper defined in cometchat-core's provider pattern — the module-level loginInFlight promise dedupes concurrent refreshes automatically.
Concrete refresh handler — pair the helper from cometchat-core with the connection listener and a token-refetch path:
import { CometChat } from"@cometchat/chat-sdk-javascript";
import { CometChatUIKit } from"@cometchat/chat-uikit-react";
// Module-level — shared across every refresh attempt.// Identical shape to the one in cometchat-core § 2.letrefreshInFlight: Promise<unknown> | null = null;
asyncfunctionrefreshSession(uid: string): Promise<void> {
if (refreshInFlight) {
// Another component already triggered a refresh — wait for it,// don't fire a second loginWithAuthToken.await refreshInFlight;
return;
}
refreshInFlight = (async () => {
// 1. Fetch a fresh token from your server endpoint.// Your existing useCometChatToken hook (Step 1) calls /api/cometchat-token.// Extract that fetch into a helper so the refresh path can reuse it.const res = awaitfetch("/api/cometchat-token", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ uid }),
});
if (!res.ok) thrownewError(`Token refresh failed: ${res.status}`);
const { token } = (await res.json()) as { token: string };
// 2. Re-authenticate with the new token. SDK swaps the in-memory// session — no full reload needed.awaitCometChatUIKit.loginWithAuthToken(token);
})();
try {
await refreshInFlight;
} finally {
refreshInFlight = null;
}
}
// Wire it into the connection listener so a disconnect triggers refresh.CometChat.addConnectionListener(
"auth-refresh-listener",
newCometChat.ConnectionListener({
onDisconnected: () => {
const uid = CometChatUIKit.getLoggedInUser()?.getUid();
if (uid) {
refreshSession(uid).catch((e) => {
console.error("CometChat refresh failed; user may need to re-login", e);
});
}
},
}),
);
refreshInFlight mirrors loginInFlight from cometchat-core § 2 — same dedup pattern, separate promise so the initial-login and refresh paths don't accidentally serialize against each other. If the same component renders in StrictMode AND a 401 arrives during the second mount, the listener and the provider effect can both touch the SDK without colliding.
5. User management patterns
In production, you need to keep CometChat users in sync with your app's users. CometChat users are managed via the REST API using the REST API key (server-only).
Create user — on signup
When a user signs up for your app, create a corresponding CometChat user.
// Supabase Edge Function or webhook handler// Supabase fires webhooks on auth events via Database Webhooks// pointing at the auth.users table.// In a Next.js API route triggered by Supabase webhook:exportasyncfunctionPOST(req: Request) {
const { type, record } = await req.json();
if (type === "INSERT") {
awaitcreateCometChatUser(
record.id,
record.raw_user_meta_data?.full_name ?? record.email ?? "User",
record.raw_user_meta_data?.avatar_url
);
} elseif (type === "UPDATE") {
awaitupdateCometChatUser(record.id, {
name: record.raw_user_meta_data?.full_name,
avatar: record.raw_user_meta_data?.avatar_url,
});
} elseif (type === "DELETE") {
awaitdeleteCometChatUser(record.id);
}
returnnewResponse("OK");
}
Firebase Auth:
// Firebase Cloud Function triggered by auth eventsimport * as functions from"firebase-functions";
exportconst onUserCreated = functions.auth.user().onCreate(async (user) => {
awaitcreateCometChatUser(
user.uid,
user.displayName ?? user.email ?? "User",
user.photoURL ?? undefined
);
});
exportconst onUserDeleted = functions.auth.user().onDelete(async (user) => {
awaitdeleteCometChatUser(user.uid);
});
// For profile updates, call updateCometChatUser from your// profile update endpoint — Firebase Auth doesn't fire a// Cloud Function on profile changes.
6. Environment variables
Production environment variables
Variable
Where
Description
COMETCHAT_APP_ID
Server + Client
Your app ID. Client-side copies use the framework prefix (NEXT_PUBLIC_, VITE_, PUBLIC_).
COMETCHAT_REGION
Server + Client
Region code: us, eu, in. Client-side copies use the framework prefix.
COMETCHAT_REST_API_KEY
SERVER ONLY
The REST API key from your CometChat dashboard. Used for token generation and user management.
COMETCHAT_AUTH_KEY
REMOVE in production
The auth key used in dev mode. Remove it from .env in production.
Critical: REST API key must be server-only
The REST API key grants full access to your CometChat app: creating users, generating tokens, deleting messages, managing groups. It MUST stay on the server.
NEVER prefix it with:
NEXT_PUBLIC_ (Next.js)
VITE_ (Vite / React Router)
PUBLIC_ (Astro)
REACT_APP_ (Create React App)
Any of these prefixes will bundle the key into your client-side JavaScript, exposing it to every visitor.
Example .env file (production)
# Client-side (with framework prefix)
NEXT_PUBLIC_COMETCHAT_APP_ID=your-app-id
NEXT_PUBLIC_COMETCHAT_REGION=us
# Server-side ONLY (no prefix)
COMETCHAT_APP_ID=your-app-id
COMETCHAT_REGION=us
COMETCHAT_REST_API_KEY=your-rest-api-key
# REMOVED — do not include in production:# NEXT_PUBLIC_COMETCHAT_AUTH_KEY=...
Copy the REST API Key (it is different from the Auth Key)
7. Security checklist
Before deploying to production, verify every item:
Auth key removed from client-side env vars. No NEXT_PUBLIC_COMETCHAT_AUTH_KEY, VITE_COMETCHAT_AUTH_KEY, or PUBLIC_COMETCHAT_AUTH_KEY in your .env file.
REST API key is server-only. The COMETCHAT_REST_API_KEY variable has NO framework prefix (NEXT_PUBLIC_, VITE_, PUBLIC_, REACT_APP_).
Token endpoint validates the caller's identity. The /api/cometchat-token endpoint checks that the request comes from an authenticated user (session cookie, JWT, etc.) before issuing a token. The example code includes TODO comments where you add this check.
UID comes from the session, not the request. In production, the token endpoint should derive the user's UID from the authenticated session, not from the request body. This prevents users from requesting tokens for other users.
CORS configured. If the token endpoint runs on a different origin than the frontend (e.g., Express on port 3001, Vite on port 5173), configure CORS to allow only your frontend origin.
Rate limiting on the token endpoint. Add rate limiting to prevent abuse. Most frameworks have middleware for this (e.g., express-rate-limit, Next.js middleware, Astro middleware).
User management endpoints are authenticated. The create/update/delete user endpoints must verify that the caller has permission to perform the operation (admin role, webhook signature, etc.).
UIKitSettingsBuilder does NOT call .setAuthKey(). In production, remove the setAuthKey() call entirely. The builder should only have setAppId() and setRegion().
8. Rate limits and retry
CometChat's REST API enforces per-app rate limits on the token and user-management endpoints. When limits are exceeded, the API returns HTTP 429 with a Retry-After header (in seconds). Your server code should handle this gracefully — without retry logic, a burst of simultaneous logins on app startup can fail silently.
What to retry, and what not to
Retry these:
429 Too Many Requests — rate limit hit, back off and retry
400 Bad Request — malformed payload, retry will fail identically
401 Unauthorized / 403 Forbidden — wrong API key or missing permissions, retry can't help
404 Not Found — wrong endpoint or user/group doesn't exist
Exponential backoff pattern
The minimum useful retry is exponential backoff with a cap and full jitter. The pattern below works in any Node.js / Edge runtime (Next.js API routes, Astro endpoints, Hono, Express):
Log the URL path, status, attempt number, and Retry-After — never the UID (user identifier), the API key, or the auth token.
Circuit breaker (for high-traffic endpoints)
If you're behind a load balancer with many parallel requests, a simple backoff isn't enough — every process independently retries, amplifying the pressure. For those setups, add a circuit breaker (e.g. opossum for Node.js) around fetchWithRetry so repeated failures stop traffic to CometChat for a cooldown window instead of continuing to hammer it.
Don't prematurely add a circuit breaker — it's only worth it once you have production metrics showing sustained 429s under normal load.
9. CLI complement
The CLI has production-auth and add-user-mgmt commands that can scaffold the token endpoint and user management routes for supported frameworks:
Not supported: React/Vite (no built-in server). For React/Vite projects, use the Express or Hono patterns in Section 3 of this skill.
The CLI templates are a starting point. This skill's patterns are more complete (they cover more frameworks, show auth provider integration, and include the security checklist). Use the CLI for scaffolding, then refer to this skill for the full picture.
10. Common mistakes
Using the Auth Key instead of the REST API Key on the server. The Auth Key (setAuthKey()) is for client-side dev mode. The REST API Key is for server-side API calls. They are different keys with different permissions.
Exposing the REST API Key to the client. Adding NEXT_PUBLIC_ or VITE_ prefix to the REST API Key variable bundles it into the client. This is worse than exposing the Auth Key because the REST API Key can create and delete users.
Not validating the caller before issuing tokens. If your token endpoint accepts any UID without checking the caller's identity, anyone can request tokens for any user. Always validate the session first.
Forgetting to create CometChat users. If you use token auth but never create the CometChat user via the REST API, loginWithAuthToken will fail with "User not found." Always create the CometChat user when the app user signs up.
Hardcoding UIDs in production. The example code uses "cometchat-uid-1" as a placeholder. In production, the UID must come from your authentication system.