# Authentication Pattern (Humand E2E)

Use UI login once to create storage state, then reuse that state for regular test projects.

## Current backoffice flow

1. `auth-setup` project runs `tests/auth.setup.ts`
2. Script logs in with admin credentials
3. Storage state is saved to `auth/backoffice.auth.json`
4. Main project loads that storage state

## Credentials

- `PLAYWRIGHT_AUTH_USER`
- `PLAYWRIGHT_AUTH_PASSWORD`
- `PLAYWRIGHT_BASE_URL`

Set in `.env.local` (not committed).

## Local execution contract

- Prefer `npm --prefix e2e run setup:auth` over ad-hoc `npx` or `npm exec` commands.
- Run local Playwright commands with `PLAYWRIGHT_BROWSERS_PATH=0` so the browser binaries stay tied to the version installed in `e2e/package.json`.
- If the auth setup stops before opening the browser or fails with a missing executable, run `npm --prefix e2e run install:browsers`.

## Why this approach

- tests are faster than UI login on every case
- auth remains validated by the setup project
- state is explicit and reproducible

## Community selection

Backoffice auth already needs to handle both flows:

- single community: password screen appears directly after submitting the user
- multiple communities: a drawer appears and the setup must pick a real community option before continuing

Prefer semantic drawer scoping over generic `.first()` click strategies, and always wait for the password field after the community is chosen.

## SSO notes

SSO providers (Azure AD, Google) are out of current scope for base auth setup and can be added as dedicated scenarios later.