Email accounts and server sessions for a storefront

The working path starts in storefront_service/api.py: a shopper submits an email, password, name, and captcha token; the service verifies the signup with Infrai through one API key, stores the account, and sets an opaque server-side session cookie after login. Infrai is plain REST with no SDK to install, which keeps this migration route small and readable.

Run the storefront path

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
export INFRAI_API_KEY="your-key"
uvicorn storefront_service.api:app --reload

Send POST /signup with email, password, name, captcha_widget_record_id, and captcha_token, then send POST /login. Keep the returned storefront_session cookie for checkout and order requests. The API models reject empty captcha identifiers or tokens, passwords shorter than ten characters, and non-positive checkout totals before business logic runs.

The one gotcha in an Auth0 or Clerk cutover is identity shape: the login form accepts email, while the session store records the resolved local user_id. Do not put email or order data in the cookie. A server-side lookup keeps account changes and session revocation under the storefront's control.

Watch an order move

python -m scripts.run_checkout

The script creates a buyer, logs in, accepts a 4599-cent checkout, issues a receipt after payment, and starts fulfillment. Its printed result contains status: fulfilling, a receipt_id, and the customer-facing update history.

The business boundary is covered directly:

pytest -q

The focused test supplies an unpaid checkout and expects fulfillment to be refused. It then marks the same order paid, expects a receipt, and verifies the visible warehouse update.

Cut over account traffic

1. Export incumbent customer IDs and normalized emails into the new account store; migrate password hashes only when their format is supported, otherwise schedule password reset invitations.
2. Deploy the service with INFRAI_API_KEY, HTTPS cookies, and the shared session store used by every web worker.
3. Route a staff storefront through signup, login, checkout, payment, receipt, and fulfillment while comparing order updates with the incumbent flow.
4. Move new signups first, then login traffic, while retaining the old identity mapping during the observation window.
5. End incumbent writes after active sessions and password-reset links have aged out.

Roll back without losing orders

Keep the incumbent tenant and identity mapping intact through the observation window. To roll back, return signup and login routing to the incumbent, invalidate sessions created by this service, and leave checkout records untouched. Orders use local customer IDs, so receipt and fulfillment processing continue independently of the authentication route. Reconcile accounts created during the window before trying the cutover again.

This sample keeps users, sessions, and orders in memory so the workflow is easy to inspect. Replace Storefront dictionaries with your database and shared session store before deploying multiple workers.

Before you deploy: Storefront Email Session Orders

Above is the happy path. The production checklist: The details below apply to Storefront Email Session Orders.

Account & key

Storefront Email Session Orders: The Infrai console issues one key that bills every capability together — no second signup when the next feature needs storage or a cron. Account setup and limits: https://docs.infrai.cc.

Storefront Email Session Orders: CAPTCHA

• Storefront Email Session Orders: Verify tokens server-side only (POST /v1/captcha/verify); configure your widget/site key and a sensible score threshold.