Skip to content

feat(verify): adapter (cookie) conformance path — harness adapter app + cookie cases#11

Merged
Bccorb merged 1 commit into
mainfrom
verify-adapter-path
Jun 28, 2026
Merged

feat(verify): adapter (cookie) conformance path — harness adapter app + cookie cases#11
Bccorb merged 1 commit into
mainfrom
verify-adapter-path

Conversation

@Bccorb

@Bccorb Bccorb commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

What

Adds the adapter (cookie) path to the seamless verify conformance harness, proving the real @seamless-auth/express SDK + cookie bridge work end-to-end against the auth API. Complements the API path already on main.

Included

  • Harness adapter app (verify/adapter-app/): a minimal adopter backend that mounts the real @seamless-auth/express with a capture transport + a /__captured readout, so the harness can read OTP/magic-link codes the adapter strips before responding to the browser. Dockerized; replaces the starter-express adapter in the verify compose.
  • adapter Playwright project — an adapterActor (cookie-persisting request context), adapterFlows, and two green cases:
    • register → verify email → login-OTP → seamless-access/refresh cookies → /users/me (200)
    • logout → 204 → session cleared
  • Compose: run the auth API as development (so it publishes the dev JWKS the adapter verifies) and align ISSUER to the adapter's authServerUrl.

Run

# from verify/harness, against a running verify stack
SEAMLESS_VERIFY_ADAPTER=1 npx playwright test --project=adapter

Reproducible now that fells-code/seamless-auth-api#48 (makes LOGIN_METHODS authoritative) is merged — the adapter login-OTP flow needs email_otp enabled via env.

Follow-ups (not in this PR)

  • Wire the adapter project into the default seamless verify run (currently runs --project=api) and add down -v for a deterministic seed.
  • Magic-link via the adapter has a known device-binding 403 on poll (narrowed to a likely user-agent-forwarding difference between request and poll) — under investigation, not yet covered.

Verified

CLI builds clean; both adapter cases pass live against the stack.

…adapter

- NODE_ENV=development so the API publishes its dev JWKS and the adapter/SDKs
  can verify tokens (the JWKS-in-test 500 is tracked separately)
- ISSUER=http://auth-api:5312 so token iss matches the adapter's authServerUrl
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant