cometchat-flutter-v6-production

Ground truth: loginWithAuthToken and logout are catalog-verified against 6.1.0. Token MINTING is a server-side REST call — its exact endpoint is FETCHED from the REST API docs, never guessed. The dev-vs-prod credential rule is RULES.md §4.

Companion skills (read first)

• cometchat-flutter-v6-core — install, credentials, init→login→render, lifecycle.md. This skill ASSUMES it.
• cometchat-flutter-v6-patterns — where config comes from in your build pipeline.
• 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

Hardening before release: "is the Auth Key safe to ship", "set up production auth", "what do I check before shipping".

Prerequisites & install

Core done. No new package.

The one thing that actually matters: the Auth Key must not ship

An Auth Key can log in as ANY user of your app. Everything core writes for development puts it in cometchat-settings.json, which is bundled into the APK/IPA — and a bundle is not a secret. Anyone can extract it.

Development (what core wired): credentials.authKey in the settings asset → CometChatUIKit.login(uid). Fine for building; never for release.