Multi-User Dashboards + Google Auth

Every assumption a single-user system makes, discovered the hard way

The dashboard worked fine for one person — credentials hardcoded in the source, one active session at a time, the researcher’s home IP baked directly into session validation. Then a second person needed access, and sharing the password wasn’t a shortcut, it was a countdown: one session would terminate the other, the IP binding would reject the second person’s network, or a password change would lock someone out with no recovery path short of a code change and a redeploy.

This book documents the full rebuild of a private research dashboard’s auth system — a Voice Lab tool for audio and voice synthesis work — from single-user to real multi-user access, then through Google Sign-In integration, with Claude as design partner at every phase. It stays in the middle case most auth tutorials skip: not “share one password” and not “full registration with roles and permissions,” but a small, known user base that still needs isolated sessions, managed credentials, and more than one way in.

Every session in the book is real, including where Claude was wrong. The multi-user session lifetime extension introduced a session directory issue Claude didn’t flag until the second pass. The Google OAuth callback handler went through three iterations before the token verification approach was solid. The method documented here is not “use Claude and everything works” — it’s use Claude as the first draft and the first reviewer, and verify everything before it touches a production system.

From one hardcoded login to two identity paths, one session model

• The foundation — What the single-user auth system assumed, and why every one of those assumptions became load-bearing the moment a second user appeared.
• The multi-user rebuild — Moving from hardcoded credentials to bcrypt-hashed, per-user records, with Claude asked directly what breaks when a second user is added.
• Login and redirect defense — A login page hardened against the redirect-based attacks a single-user system never had to consider.
• Logout and session revocation — Making a logout actually end a session, and revoking access without waiting for expiry.
• Dynamic guest accounts — Managing occasional-access accounts outside source code, so granting access doesn’t require a deploy.
• Protecting endpoints — Consistent authorization checks across every route, not just the login page.
• Adding Google Sign-In — A second identity path with JWT verification that lands users in the same session structure as the bcrypt path, so the rest of the system never needs to know how someone authenticated.
• Roles without a database — Access levels for a small, known user base without standing up a roles table.
• Per-user state — Keeping each user’s dashboard state isolated on shared infrastructure.
• The admin dashboard — Managing users and sessions from inside the tool itself.
• The audit trail — Reconstructing who did what, after the fact.

A preview

The naive solution — share the password — broke immediately on inspection. Not technically, in the sense that it wouldn’t have worked. It would have worked fine for a few weeks, until one of several things happened.

Developers building private tools that need real access control

This book is for developers with an existing single-user PHP tool that now needs more than one person to access it, on ordinary shared hosting rather than a VPS or managed identity service. It assumes basic PHP and an existing auth system to start from. By the end you have a documented path from hardcoded single-user credentials to isolated multi-user sessions with a Google Sign-In option, plus the specific shared-hosting constraints — session directory limits, no persistent background processes, no Redis — addressed directly rather than assumed away.

A longer excerpt is available to newsletter subscribers.

Buy Ebook on Amazon