Compath Docs

Appearance

IE.4: Supabase Auth Emails ​

Summary ​

Login, sign-up, and current invitation registration emails are sent by Supabase Auth from the frontend, not by the Compath backend email service. The current frontend uses magic-link OTP emails for login and sign-up. Invitation registration uses Supabase signUp first, then falls back to signInWithOtp when the invited account already exists. IE.1 tracks the intended future behavior where guest invitees do not have to sign up before responding.

Role ​

  • Primary: Guest
  • Secondary: Client, Counselor, Admin, Supabase Auth

Entry Point ​

  • Login/sign-up UI: /login
  • Invitation registration: /invitations/:token
  • Frontend calls: supabase.auth.signInWithOtp, supabase.auth.signUp, supabase.auth.signInWithOAuth

Preconditions ​

  • Supabase URL and anon key are configured in frontend environment variables.
  • User enters a valid email address.
  • For invitation registration, the public invitation token must resolve and provide an invited email.

Steps ​

  1. User opens the login/sign-up UI or an invitation landing page.
  2. For normal login or sign-up, user enters an email.
  3. Frontend calls supabase.auth.signInWithOtp with emailRedirectTo.
  4. Supabase sends the magic-link email.
  5. Frontend shows an email-sent confirmation state.
  6. User clicks the email link and returns to the configured redirect URL.
  7. Auth provider initializes the Supabase session and routes the user through app entry/onboarding logic.
  8. For invitation registration, frontend calls supabase.auth.signUp with a generated password and emailRedirectTo set to the current invitation URL.
  9. If Supabase reports an existing identity condition, frontend falls back to signInWithOtp.
  10. User returns to /invitations/:token authenticated and can accept or reject the invitation.

Diagram ​

Edge Cases ​

  • Supabase enumeration protection: Invitation registration uses signUp because signInWithOtp can suppress emails for non-existent users.
  • Existing invited user: Empty identities after signUp triggers a magic-link fallback.
  • OAuth login: Login/sign-up also support OAuth providers, which redirect through Supabase rather than sending Compath emails.
  • Password reset: Route constants exist for forgot/reset password, and README has a Guest password reset placeholder, but current routed frontend flow uses magic links instead of a dedicated password-reset page.
  • Return URL: Magic links redirect to the current invitation URL or the original requested route.

Current Implementation Notes ​

  • Frontend: frontend/src/features/auth/components/login-form.tsx, frontend/src/features/auth/components/sign-up-form.tsx, frontend/src/app/pages/invitation.tsx
  • Auth state: frontend/src/shared/store/auth-store.ts, frontend/src/app/providers/auth-provider.tsx
  • Product gap: invitation registration is current behavior only. The IE.1 client invitation lifecycle should avoid requiring Supabase sign-up before accept/reject.

Screenshot Status ​

  • IE.1 captured the invitation registration prompt and secure-link-sent state; standalone Supabase auth email screenshots are not captured.