[HIGH] fix(auth): use auth_user_id instead of id when querying users table in backup-pin#78
Merged
ralyodio merged 1 commit intoJun 11, 2026
Conversation
…n backup-pin
authenticateUser() returns the Supabase Auth user object whose .id is the UUID
from auth.users (the Supabase Auth internal table). The application's public
'users' table has its own primary key 'id' and links to Auth via 'auth_user_id'.
The original code queried .eq('id', user.id) which compared the Auth UUID against
the internal PK — a different UUID — so no row was ever matched.
Result of the bug:
- GET /api/auth/backup-pin always returned { hasPin: false } for every user
because .single() got PGRST116 (no rows found) and the code treated missing
row as 'no PIN set'.
- POST /api/auth/backup-pin silently succeeded (UPDATE matched 0 rows) but the
PIN hash was never persisted, leaving the backup PIN feature entirely broken.
Fix: replace both .eq('id', user.id) calls with .eq('auth_user_id', user.id).
Severity: HIGH — backup PIN feature completely non-functional
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
authenticateUser()returns the Supabase Auth user object whose.idis the UUID fromauth.users(the Supabase Auth internal table). The application's publicuserstable has its own primary keyidand links to Auth viaauth_user_id.The original code queried
.eq('id', user.id)which compared the Auth UUID against the internal PK — a different UUID — so no row was ever matched.Result of the bug:
GET /api/auth/backup-pinalways returned{ hasPin: false }for every user because.single()got PGRST116 (no rows found) and the code treated missing row as 'no PIN set'.POST /api/auth/backup-pinsilently succeeded (UPDATE matched 0 rows) but the PIN hash was never persisted, leaving the backup PIN feature entirely broken.Fix: replace both
.eq('id', user.id)calls with.eq('auth_user_id', user.id).Severity: HIGH — backup PIN feature completely non-functional