Login Page

Login Page

Component File: src/features/auth/components/LoginPage.tsx Route: /login Access Level: Public (unauthenticated) Last Updated: April 18, 2026 Status: ✅ Production Ready

Overview

The Login Page is the shared entry point for:

• staff email/password sign-in
• donor and volunteer passwordless portal login
• password reset handoff
• MFA challenge handoff after staff password login

Modes

Staff Login

• Email + password via supabase.auth.signInWithPassword()
• Used for fund_user / parent_org / internal users
• Supports forgot-password flow and MFA challenge follow-up
• Always establishes full-app mode. Staff password login explicitly clears portal intent, persists portalMode = null, and logout/signed-out handling resets stale portal navigation state back to /.

Portal Login

• Email-only flow for donors and volunteers
• Before sending OTP, the page calls check_portal_account_exists(...) so public clients can verify portal eligibility without direct anonymous reads against volunteers / donors
• OTP send uses supabase.auth.signInWithOtp() with shouldCreateUser: false
• OTP send marks the session as portal-initiated before redirecting so auth completion can resolve donor vs volunteer portal mode from the loaded profile
• Accepted tradeoff: this public RPC can reveal whether an email has an active donor and/or volunteer account. We keep it for the shared portal UX, and treat abuse mitigation as an operational control rather than a frontend behavior change.

OTP Sent / Verify

• The email-link path returns to the app root and carries a short-lived portal-login intent so auth completion can resolve donor vs volunteer portal mode from the loaded profile
• The 6-digit code path uses verifyOtp() and then applies donor vs volunteer portal mode from the loaded profile
• Portal mode is determined at login entry time. Same-tab refresh preserves that choice via session intent; cached portal mode from other tabs/sessions is treated as stale and ignored for staff rehydration.

Portal Login Notes

• Staff-issued volunteer login links still use send-volunteer-magic-link and go directly to ?tool=volunteer-portal
• Public /login portal sends are generic and can resolve to donor or volunteer after profile load
• Staff users who also have donor/volunteer access may still use Portal Login intentionally; that path should open the portal, while normal password login should not
• Portal login should never auto-create new auth users from the public login page
• Portal abuse controls should focus on rate limiting, provider throttling, and monitoring repeated anonymous eligibility checks. If abuse becomes material, move the pre-check behind an edge-controlled endpoint or add CAPTCHA.

Error Handling

| Scenario | User-facing behavior |

|-------|---------|

| Invalid staff credentials | Friendly invalid-credentials message |

| Portal email not found | "No account found for this email..." |

| OTP rate limit / Supabase throttling | Wait-and-retry message |

| Portal eligibility check failed | Retry/contact-org message |

| MFA required | Switches into MFA challenge mode |

Related Documentation

• AUTHENTICATION.md - Auth system overview
• 14-SET-PASSWORD-PAGE.md - Password reset
• ../people/04-VOLUNTEER-PORTAL.md - Volunteer portal behavior

Synced from IFMmvp-Frontend documentation: pages/components/13-LOGIN-PAGE.md