Migrating to the Unified Identity System

This is the one breaking change that touches both an existing CMS deployment and any website built on it. It is listed under Breaking in the CMS changelog. Read this before running pnpm run update on a deployment that has sign-ups or Commerce customers.

What changed

1. One identity system. Website and application users are ordinary Better Auth accounts with role none and no CMS access. New accounts default to none. Before this change, a public sign-up defaulted to Editor.
2. Commerce customers are core users. The separate customer login, session and token tables are gone. Each customer is now a user with role none. Commerce keeps only Commerce-specific data (a phone number) in a profile keyed by that user’s id.
3. The Owner is hidden from other users: not in the Users list or audit log, and 404 for anyone else who looks up or changes them.
4. Removed storefront routes. /api/plugins/commerce/public/v1/customer-auth/* and the separate customer password route no longer exist, and neither does the COMMERCE_CUSTOMER_AUTH_RATE_LIMITER binding.

What the update does to your data

pnpm run update applies a migration that, for each existing Commerce customer:

• creates a core user with the same id (so every existing cart, order and address still points at them) and role none, and carries over their existing password hash, so their password keeps working;
• if the customer’s email already belonged to a core user, links their carts, orders and addresses to that existing user instead. No second account is created and no credential is changed;
• drops old customer sessions and tokens, so every customer signs in once more.

Existing CMS users keep their roles.

Before you update

1. Back up D1: wrangler d1 export your-cms-db --remote --output backup.sql. See Backups.
2. Check that email is configured. Customers must now verify their email before their first sign-in, so a deployment with no email provider leaves them unable to sign in until you configure one.
3. If your team relied on self sign-up to give people editor access, plan to grant roles by hand afterwards.

Update the CMS

pnpm run update

After you update

• Review roles. In Users, confirm every staff member has the role you expect. Anyone who signed up on your site after this change is none until an Owner or Admin sets a role. Add user still creates an Editor.

• Customers sign in again with their existing password, verifying their email if they have not.

• Update your frontend. In an Astro site, update the integration so it uses the current client and proxy:

  npx @kenresoft-cms/create astro --update

  Any hand-written calls must move to the core routes:

  Everything that used /customer-auth/*, and the separate customer password route, now uses the core routes:

  Action	Route
  Register	POST /api/v1/auth/sign-up/email
  Sign in and out	POST /api/v1/auth/sign-in/email, POST /api/v1/auth/sign-out
  Verify email, resend the link	GET /api/v1/auth/verify-email, POST /api/v1/auth/send-verification-email
  Reset a password	POST /api/v1/public/password-reset/request, …/confirm
  Change a password	POST /api/v1/auth/change-password

  cms.commerce.customerAuth in @kenresoft-cms/astro calls the core routes for you. register() no longer signs the customer in: it sends a verification email, so send people to a “check your email” page. Pass callbackUrl so the verification link returns to your site, and make sure that origin is in CORS_ORIGINS.

• Guest carts still merge. A guest cart merges into the customer’s cart the first time they make a cart or checkout request while signed in.

See Commerce and Authentication.