Summary
Sparki’s authentication was split across two systems and two databases. This session unified it to a single system (BetterAuth), cleaned leftover data from the old approach, and documented a security exposure that needs manual follow-up.What changed
One auth system instead of two
Sparki had been running BetterAuth (handling Google and GitHub login for 4 real users) alongside a legacy system called Auth-Shield. The migration to Auth-Shield was abandoned — BetterAuth is now the confirmed, sole auth provider. The open migration PR was closed.Database cleaned up
The production database (Neon) had duplicate tables from the old setup: three legacy tables holding expired sessions and unused password accounts. These were audited and removed. No active user data was lost — all current logins are via Google or GitHub OAuth. The Go backend’s database schema was also corrected. It had been built assuming a different ID format (UUIDs) than what BetterAuth actually generates (random text strings). This mismatch would have caused failures when the backend tried to look up users. Now aligned.A dangerous database migration was rewritten
An existing migration script would have deleted the entire user table and everything connected to it. It was rewritten to safely modify columns in place instead of dropping and recreating them.Secrets exposed in git history
Four credentials were found committed to the repository history: a GitHub access token, an OAuth secret, a deployment token, and a session signing key. A step-by-step rotation runbook was created with instructions for each credential. This requires manual action — someone needs to rotate these credentials in GitHub, Vercel, and the app’s environment variables. The Google OAuth secret was confirmed NOT exposed (never committed).Action items
| Action | Owner | Priority | Status |
|---|---|---|---|
| Rotate 4 exposed secrets per runbook | Ops | Critical | Pending |
| Consider git history scrub (BFG/filter-repo) | Ops | High | Pending |
| Enable GitHub secret scanning on repo | Ops | Medium | Pending |
| Connect email/password login UI | Dev | Low | Backlog |
Business impact
- User-facing risk: None immediate. OAuth login continues to work. The exposed secrets are a background risk until rotated.
- Operational clarity: Auth is now one system, one database. No more confusion about which system handles login.
- Technical debt reduced: Legacy tables removed, schema aligned, destructive migration neutralised.