fix(signup): the verification link carries the address - #46
Merged
Merged
Conversation
resend_verification can resolve an account from an email, a LIVE token, or a signup_data row keyed by a session that no longer exists (create_account stopped establishing one). But every failure that lands the user on the "Verification failed" screen is a failure of the token: consumed by an earlier click or by a mail scanner prefetching the URL, or superseded, since drumate_set_verification_token_v2 DELETEs the previous row whenever a newer link is minted. So the recovery path's only usable credential was guaranteed dead exactly when recovery was needed, and Resend answered no_pending_signup forever. Measured on stage: of 44 outstanding tokens, 15 no longer joined to a drumate and 10 more pointed at accounts with no unverified_email staged, so 25 could not be resent at all. signup_data held one row in total. Putting the address next to the token gives that screen something that survives the token. It lives in the fragment, so it never reaches a server, an access log or a Referer -- the same reach as the far more sensitive token beside it, in a mailbox that already knows its own address -- and it grants no new access: resend_verification already accepts an arbitrary address and still refuses any account whose unverified_email is not already staged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
Claude encountered an error after 0s —— View job I'll analyze this and get back to you. |
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
1 participant
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.
resend_verification can resolve an account from an email, a LIVE token, or a signup_data row keyed by a session that no longer exists (create_account stopped establishing one). But every failure that lands the user on the "Verification failed" screen is a failure of the token: consumed by an earlier click or by a mail scanner prefetching the URL, or superseded, since drumate_set_verification_token_v2 DELETEs the previous row whenever a newer link is minted. So the recovery path's only usable credential was guaranteed dead exactly when recovery was needed, and Resend answered no_pending_signup forever.
Measured on stage: of 44 outstanding tokens, 15 no longer joined to a drumate and 10 more pointed at accounts with no unverified_email staged, so 25 could not be resent at all. signup_data held one row in total.
Putting the address next to the token gives that screen something that survives the token. It lives in the fragment, so it never reaches a server, an access log or a Referer -- the same reach as the far more sensitive token beside it, in a mailbox that already knows its own address -- and it grants no new access: resend_verification already accepts an arbitrary address and still refuses any account whose unverified_email is not already staged.