A member could not log in. Not a wrong password, not a locked account -- the confirmation email just never showed up. And once auth email stops arriving, a fresh signup is stuck before it even begins. There is no self-service way out of that hole.
So I did the obvious thing. Added a Reset password button on the /admin/members table. Admin clicks it, we email the user a reset link, they set a new password, done. I have built this exact flow a dozen times. I expected twenty minutes of work.
It did not work. And the reason took me a minute to see.
PKCE does not care what the admin wants
My existing /reset-password flow is PKCE-based. When you request a reset, the browser generates a secret verifier and holds onto it. The link that comes back only completes if it lands in the same browser that made the request. That is the whole point -- it stops someone else from hijacking your reset link.
Which is exactly what an admin-initiated reset is. I am, from PKCE's point of view, the attacker. I request the link, but the verifier lives in the user's browser, which never made the request. The link can never complete. To make admin-sends-a-link work, I would have to rebuild the live self-service reset that real users depend on every day. To fix one stuck account, I would risk the path that works for everyone else.
Not worth it. So I stopped trying to send a link at all.
Just set the password
The admin control now sets the password directly through Supabase's admin API -- no email in the loop. Leave the field blank and it generates a crypto-random temp password, shown once, that the admin reads out over WhatsApp. Type a value and it uses that verbatim. And because the same call also confirms the account, it unblocks users who were stuck before their first login, not just people who forgot a password.
No email means it works even when email is exactly the thing that is broken. Which, this whole time, was the real problem.
Because the button is a bandage. The wound is that my auth emails are not reliably landing. The correct fix is not a clever admin escape hatch -- it is configuring Supabase Auth to send through proper SMTP so confirmation and reset mails actually arrive. That is the next job. But today someone was locked out, and a bandage that works beats a proper fix that is still a config screen away.
The lazy fix and the safe fix were the same fix: stop fighting a security feature that was doing its job.
— note to self
The thing I keep relearning: when a well-built system refuses to do what you ask, it is usually right and you are asking the wrong question. I wanted to reuse the reset flow. PKCE said no for a good reason. The answer was a different door, not a bigger hammer.