Your account
HOL-D058Story implementation: In progress

Sign in and manage my session

account · Proposed launch phase 1

Start from Home

Review as Registered user

User story

As a registered user, I want to sign in with my email and password and return safely to my activity so I can use my account without repeating setup.

Draft requirements for review · Updated 2026-10-19

What the app should do

  • After sign-in honor a safe same-account original destination and an explicit eligible choice; otherwise restore an actual saved eligible preference. If no preference was selected, use the magazine Visitor Home while preserving the real account/session. A server default member row is not an explicit user choice.
  • Use one email/password account across Member, combined Professional and named-organization contexts; restore only authorized destinations through D092.
  • Try a demo account uses D091’s controlled local seeded-identity route to establish a genuine provider session; a client role choice never grants authority.
  • Use email as the sign-in username and a password, separate from the public display name. Offer password-manager/autofill support and an accessible show/hide control.
  • Handle valid sign-in, neutral wrong-credentials errors, unverified email, temporarily throttled attempts, cancellation and expired/revoked sessions with clear next steps. Reuse registration, verification and recovery stories instead of creating duplicate accounts.
  • Preserve an allowlisted internal return destination and relevant cart/plan/action context through sign-in; fall back to the correct Home if that destination is unavailable. Signing in does not activate paid membership or grant professional/staff permissions.
  • Sign out and terminate the current session; on return read current account verification, assigned scope, required MFA and paid entitlement from the trusted service. Role/context selection never replaces a genuine local account session.
  • Local dev may implement real authentication against isolated synthetic test accounts. The ordinary dev frontend now requires the separately tested local connected adapter; hosted previews remain unchanged. Never retain typed passwords in browser storage, logs or analytics.
  • Shared Profile & settings navigation is reachable from the same authenticated account across all its contexts. Opening settings preserves selected Home and legitimate auth/join return; registration, sign-out, staff MFA and entitlement remain independent.

What to check in the demo

Follow these steps from the role’s landing page through navigation and feature checks.

Review asStart here: Home

Begin on the free Member Home. For a local example use Sign in → Try a demo account → Alex Morgan → Open account, then choose Member in the account/workspace menu if a remembered workspace opens. This is a genuine local account; no paid access is supplied.

Navigation from sign-in

  1. 01Open the fictional Registered user account through the connected sign-in service. Seeded Home review opens directly. Real HOL staff access and protected actions require an authenticator check.
  2. 02From the role’s Home open the account/workspace menu and choose Sign out when reviewing an existing session.
  3. 03On Visitor Home open the account/workspace menu → Sign in. The feature starts at Email and Password on the actual sign-in form.

Feature checks start here

Sign in and manage my session

Genuine dummy-account sign-in, all twelve scenario Homes, refresh and sign-out are verified in connected staging. Individual password registration, recovery, email change and reauthentication email remain deferred there until Resend is configured. Existing local password/security evidence and remaining expiry/throttle/error acceptance are separate; full story stays In progress.

  1. 04Review sign-in with no choice, explicit Professional/Member choice and a saved valid choice; check account identity, reload and revoked/stale contexts. Existing membership/registration continuations must still return to the original permitted destination.
  2. 05Review Email, Password, Show password, Sign in, Create a free account, Forgot password? and Try a demo account on the actual form.
  3. 06Using your own dedicated local test credentials, test an incorrect password, then sign in successfully. The seeded chooser is an alternative real local session, not proof that password-entry validation passed.
  4. 07For a saved-public-story or membership entry, check the permitted return destination and unchanged account. When a workspace was remembered, use the menu to select the intended context.
  5. 08Reload and use account/workspace menu → Sign out. Confirm protected data/actions require sign-in again. Unverified, throttled, expired and revoked cases need prepared test accounts or controlled session setup; they are not selectable fake outcomes.

Backend work for this feature

Backend development authorized · Dev only

What needs to be supported

  • After sign-in honor a safe same-account original destination and an explicit eligible choice; otherwise restore an actual saved eligible preference. If no preference was selected, use the magazine Visitor Home while preserving the real account/session. A server default member row is not an explicit user choice.
  • Use managed Supabase email/password authentication, not a custom credential table. Keep provider credentials/tokens private; replace the current magic-link-only helper within the isolated dev adapter.
  • Validate and refresh sessions server-side, enforce email verification before protected writes and deny missing/expired/revoked identities. Never accept role-switcher labels, return URLs or client membership flags as authority.
  • Implement safe internal return handling, session rotation/revocation, attempt throttling and neutral auth errors; preserve plan/cart context without persisting a password or bearer token in ordinary app state.
  • Resolve user identity, professional attributes, scoped staff assignment, required MFA and membership entitlement independently. Registration is D085; recovery D086; sign-in email D087; password D101; devices/sessions D102; MFA D088; staff access D103; data persistence D089.

How to verify in dev

  1. Review sign-in with no choice, explicit Professional/Member choice and a saved valid choice; check account identity, reload and revoked/stale contexts. Existing membership/registration continuations must still return to the original permitted destination.
  2. Test distinct verified/unverified free accounts, paid/privileged synthetic fixtures and a signed-out client; verify identity and current-access checks cannot be forged.
  3. Test wrong-password/retry limits, allowed/unsafe return targets, reload, expiry, revocation and sign-out; deny direct protected requests after session loss.

Before this can work

  • Begin on the free Member Home. For a local example use Sign in → Try a demo account → Alex Morgan → Open account, then choose Member in the account/workspace menu if a remembered workspace opens. This is a genuine local account; no paid access is supplied.
  • Use only fictional account fixtures and dummy credentials. No real password, factor secret, card or recipient data in the frontend review.
  • UI2 owns frontend; HOL - Backend owns local schema/auth/API/policy/tests. Hosted migrations, public enrollment, outgoing email/payment and deployment remain outside this authorization.
  • Use your own dedicated local test account with known credentials for password-entry/change checks. The pass-through demo chooser does not reveal or supply the seeded account password.
  • HOL-D057 · HOL-D057

    Reviewed local environment/migrations and isolated synthetic fixtures; hosted promotion remains separate.

Connected stories