groombook/app
Archived
13
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Dev/demo login experience — quick-login and impersonation for demos #60

New Issue
Closed
opened 2026-03-19 03:15:54 +00:00 by ghost · 0 comments
ghost commented 2026-03-19 03:15:54 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Context

When demoing the app or running locally with AUTH_DISABLED=true, we need a smooth way to show different user perspectives without configuring a real OIDC provider.

The current state:

  • AUTH_DISABLED=true bypasses auth entirely with a dummy dev-user JWT subject
  • There's no login page — the app goes straight to content
  • Customer portal has a staff impersonation button/modal (frontend-only demo)
  • No way to quickly switch between customer views or staff roles

Requirements

1. Dev login selector page (when AUTH_DISABLED=true)

When auth is disabled, show a login selector page at /login (or as a landing modal) that lets demo users pick their role:

  • Staff logins: Show available staff members from the database (name, role). Clicking one sets the session to that staff member and redirects to /admin.
  • Customer logins: Show available clients from the database (name, pet count). Clicking one sets the session to that customer and redirects to / (customer portal).
  • Skip login: A clear "Continue as dev user" link that bypasses selection and goes straight in with the default dev-user identity.

2. Persistent session indicator

Once logged in as a specific persona, show a small indicator (e.g. top-right badge or bottom bar) showing who you're acting as, with a "Switch user" link back to the selector.

3. API awareness

The API's auth middleware should accept a X-Dev-User-Id header (or similar) when AUTH_DISABLED=true to let the frontend specify which staff/client record to impersonate. The middleware should look up the staff/client record and inject the appropriate identity into the request context.

Security: This MUST only work when AUTH_DISABLED=true. If auth is enabled, ignore X-Dev-User-Id completely.

4. Customer portal integration

The existing impersonation UI in the customer portal can stay, but the new dev login selector is the primary entry point for demos.

Non-goals

  • Real OIDC login flow (separate issue)
  • Server-side audit trail for impersonation (separate issue)
  • Production impersonation (separate issue)

Acceptance criteria

  • With AUTH_DISABLED=true, visiting the app shows a role/user selector
  • Staff members and clients from DB are listed
  • Selecting a user sets session and redirects to appropriate area
  • Session indicator visible while impersonating
  • "Switch user" returns to selector
  • API middleware respects dev user header when auth disabled
  • Tests pass
## Context When demoing the app or running locally with `AUTH_DISABLED=true`, we need a smooth way to show different user perspectives without configuring a real OIDC provider. The current state: - `AUTH_DISABLED=true` bypasses auth entirely with a dummy `dev-user` JWT subject - There's no login page — the app goes straight to content - Customer portal has a staff impersonation button/modal (frontend-only demo) - No way to quickly switch between customer views or staff roles ## Requirements ### 1. Dev login selector page (when `AUTH_DISABLED=true`) When auth is disabled, show a **login selector page** at `/login` (or as a landing modal) that lets demo users pick their role: - **Staff logins**: Show available staff members from the database (name, role). Clicking one sets the session to that staff member and redirects to `/admin`. - **Customer logins**: Show available clients from the database (name, pet count). Clicking one sets the session to that customer and redirects to `/` (customer portal). - **Skip login**: A clear "Continue as dev user" link that bypasses selection and goes straight in with the default dev-user identity. ### 2. Persistent session indicator Once logged in as a specific persona, show a small indicator (e.g. top-right badge or bottom bar) showing who you're acting as, with a "Switch user" link back to the selector. ### 3. API awareness The API's auth middleware should accept a `X-Dev-User-Id` header (or similar) when `AUTH_DISABLED=true` to let the frontend specify which staff/client record to impersonate. The middleware should look up the staff/client record and inject the appropriate identity into the request context. **Security**: This MUST only work when `AUTH_DISABLED=true`. If auth is enabled, ignore `X-Dev-User-Id` completely. ### 4. Customer portal integration The existing impersonation UI in the customer portal can stay, but the new dev login selector is the primary entry point for demos. ## Non-goals - Real OIDC login flow (separate issue) - Server-side audit trail for impersonation (separate issue) - Production impersonation (separate issue) ## Acceptance criteria - [ ] With `AUTH_DISABLED=true`, visiting the app shows a role/user selector - [ ] Staff members and clients from DB are listed - [ ] Selecting a user sets session and redirects to appropriate area - [ ] Session indicator visible while impersonating - [ ] "Switch user" returns to selector - [ ] API middleware respects dev user header when auth disabled - [ ] Tests pass
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 feature
New feature
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ai-review (AI Review) gb_barkley (Barkley Trimsworth) cpfarhood (Chris Farhood) ci (Continuous Integration [bot]) gb_flea (Flea Flicker) flux (Flux CD) admin (Gitea Admin) gb_lint (Lint Roller) renovate (Mend Renovate) gb_pawla (Pawla Abdul) gb_scrubs (Scrubs McBarkley) gb_shedward (Shedward Scissorhands) gb_dogfather (The Dogfather)
No Assignees
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: groombook/app#60
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?