# BeyondHere account setup

This site uses Supabase Auth for email-and-password accounts. Set the following Sites runtime values before account flows can work:

- `SUPABASE_URL` — the project URL, for example `https://your-project.supabase.co`
- `SUPABASE_PUBLISHABLE_KEY` — the project publishable (or legacy anon) key; never use a `service_role` key here

The eight requested demo users and their portfolio data are provisioned separately. The deployment environment must never receive the administration key.

1. Apply `scripts/demo-accounts-schema.sql` to the intended BeyondHere Supabase project.
2. Locally set `SUPABASE_URL` and `SUPABASE_SERVICE_ROLE_KEY` for that project.
3. Optionally set `DEMO_CREDENTIAL_OUTPUT` to an absolute path outside this repository.
4. Run `npm run provision:demo-accounts`.

Run `npm run check:demo-data` at any time to validate all eight requested balances and profits without connecting to Supabase or creating accounts.

The script confirms emails without sending messages, generates independent random temporary passwords, preserves existing users and portfolio rows, and writes credentials to `~/.beyondhere/demo-credentials.json` by default. It refuses to write credentials inside the repository. Use `npm run provision:demo-accounts -- --reset-existing` only when an explicit password reset is intended.

In Supabase Auth settings:

1. Enable Email/password sign-in and **Confirm email**.
2. Set the Site URL to the published BeyondHere URL.
3. Add these redirect URLs: `/auth/verify` and `/reset-password` on the published domain.
4. Configure production SMTP before launch; the default sender is rate-limited and intended for evaluation.
5. Set rate limits and bot protection appropriate to the launch audience.

The provider owns password hashing, email verification, reset-email delivery, session issuance, and rate limits. The Site stores its short-lived access and refresh tokens only in Secure, HttpOnly, SameSite cookies; no authentication token is placed in localStorage.