The first accounts in this project's history have no password. Several things that were true stop being true, and a check written a month ago finally becomes reachable.
One route for setting and changing
A customer who signed up with Google cannot supply a value that was never set, so asking for one is a dead end. What authorises the change is the session they already hold, which authorises every other setting on the account page.
One route rather than two, because two would be two places to get the guard wrong and the one that gets forgotten is whichever is not exercised by hand. The branch reads the stored hash, never anything the caller sends, so a request cannot talk its way into the first-password case by omitting a field. There is a test for exactly that.
Changing the email address is refused instead
The asymmetry is the point. Setting a first password changes a credential the customer already controls. Changing the address changes where recovery goes — whoever holds the new one can reset the password and own the account outright.
That is why this route has always demanded more than a live session, and dropping the demand for the accounts that cannot meet it would remove the protection from exactly the ones that need it. The message names the way out rather than claiming a password was wrong when there is none.
Login is untouched, deliberately
Answering "this account has no password" to a submitted address would turn the login form into an oracle for which customers use Google. It keeps the single refusal, and the account page is where a signed-in customer learns what they have.
Two tests pin it, including the one where both the supplied password and the stored hash are empty — the combination most tempting to call a match, and the one that would let anyone sign in as any Google-only customer.
The lockout guard finally runs
DELETE /me/passkeys/:id has refused to remove a customer's only way in since #40, written against the condition rather than the schema, and unreachable ever since because password_hash was NOT NULL.
Three tests exercise it now: refused when it is the only way in, allowed when a second passkey remains, allowed once a password has been set.
Two things about password reset, checked rather than assumed
Both turn out to be right as they stand.
A customer who never had a password can still reset one, which is what somebody reaching for "forgot password" was asking for. And a reset still removes every passkey per #42, because nothing on that path identifies who asked.
What it does not do is sever the Google identity, and that asymmetry is deliberate. A passkey is a credential this shop issued and can revoke; a Google identity is one Google holds. Cutting it would leave the customer unable to use the button they signed up with, for no gain — whoever completed the reset controls the mailbox either way.
What the account page is told
has_password, and nothing more. Whether, never what.
The panel is titled for what it does for this customer, the current-password field is absent rather than disabled, and the confirmation says they can now sign in with it as well as with Google. A test asserts the hash never appears in the payload.
Also
Deletion needed no change, because it never asked for a password. That corrects what #332 recorded, and there is now a test so it stays true.
Testing
Twenty-two new integration tests in a suite of their own.
Verified locally: backend tsc clean for src and tests, 590 unit tests pass, lint at the seven warnings that predate this branch; frontend tsc, lint and build clean. The integration suite needs a database this machine has no Docker for.
Closes #344. Phase 5 of six under #332.
The first accounts in this project's history have no password. Several things that were true stop being true, and a check written a month ago finally becomes reachable.
## One route for setting and changing
A customer who signed up with Google cannot supply a value that was never set, so asking for one is a dead end. What authorises the change is the session they already hold, which authorises every other setting on the account page.
One route rather than two, because two would be two places to get the guard wrong and the one that gets forgotten is whichever is not exercised by hand. **The branch reads the stored hash, never anything the caller sends**, so a request cannot talk its way into the first-password case by omitting a field. There is a test for exactly that.
## Changing the email address is refused instead
The asymmetry is the point. Setting a first password changes a credential the customer already controls. Changing the address changes *where recovery goes* — whoever holds the new one can reset the password and own the account outright.
That is why this route has always demanded more than a live session, and dropping the demand for the accounts that cannot meet it would remove the protection from exactly the ones that need it. The message names the way out rather than claiming a password was wrong when there is none.
## Login is untouched, deliberately
Answering "this account has no password" to a submitted address would turn the login form into an oracle for which customers use Google. It keeps the single refusal, and the account page is where a signed-in customer learns what they have.
Two tests pin it, including the one where both the supplied password and the stored hash are empty — the combination most tempting to call a match, and the one that would let anyone sign in as any Google-only customer.
## The lockout guard finally runs
`DELETE /me/passkeys/:id` has refused to remove a customer's only way in since #40, written against the condition rather than the schema, and unreachable ever since because `password_hash` was `NOT NULL`.
Three tests exercise it now: refused when it is the only way in, allowed when a second passkey remains, allowed once a password has been set.
## Two things about password reset, checked rather than assumed
Both turn out to be right as they stand.
A customer who never had a password can still reset one, which is what somebody reaching for "forgot password" was asking for. And a reset still removes every passkey per #42, because nothing on that path identifies who asked.
What it does **not** do is sever the Google identity, and that asymmetry is deliberate. A passkey is a credential this shop issued and can revoke; a Google identity is one Google holds. Cutting it would leave the customer unable to use the button they signed up with, for no gain — whoever completed the reset controls the mailbox either way.
## What the account page is told
`has_password`, and nothing more. Whether, never what.
The panel is titled for what it does for this customer, the current-password field is absent rather than disabled, and the confirmation says they can now sign in with it as well as with Google. A test asserts the hash never appears in the payload.
## Also
Deletion needed no change, because it never asked for a password. That corrects what #332 recorded, and there is now a test so it stays true.
## Testing
Twenty-two new integration tests in a suite of their own.
Verified locally: backend `tsc` clean for src and tests, 590 unit tests pass, lint at the seven warnings that predate this branch; frontend `tsc`, lint and build clean. The integration suite needs a database this machine has no Docker for.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The first accounts in this project's history have no password. Several things that were true stop being true, and one check written a month ago finally becomes reachable.
Setting a first password and changing an existing one stay one route. A customer who signed up with Google cannot supply a value that was never set, so asking for one is a dead end; what authorises the change is the session they are already holding, which is what authorises every other setting on the account page. Two routes would be two places to get the guard wrong, and the one that would be forgotten is whichever is not on the path exercised by hand. The branch reads the stored hash rather than anything the caller sends, so a request cannot talk its way into the first-password case by omitting a field — there is a test for exactly that.
Changing the email address is refused instead, and the asymmetry is the point. Setting a first password changes a credential the customer already controls. Changing the address changes where recovery goes, and whoever holds the new one can reset the password and own the account outright. That is why the route has always demanded more than a live session, and dropping the demand for the accounts that cannot meet it would remove the protection from exactly the ones that need it. The message says the real thing and names the way out, rather than claiming a password was wrong when there is none.
Login is left exactly as it was. Answering "this account has no password" to a submitted address would turn the form into an oracle for which customers use Google, so it keeps the single refusal and the account page is where a signed-in customer learns what they have. Two tests pin that, including the one where both the supplied password and the stored hash are empty — the combination most tempting to call a match, and the one that would let anyone sign in as any Google-only customer.
Deletion needed nothing, because it never asked for a password. That corrects what #332 recorded, and there is now a test so it stays true.
The passkey lockout guard runs for the first time. It was written in #40 against the condition rather than the schema and has been unreachable ever since, because password_hash was NOT NULL. Three tests exercise it now: refused when it is the only way in, allowed when a second passkey remains, allowed once a password has been set.
Two things about password reset were worth checking rather than assuming, and both turn out to be right as they stand. A customer who never had a password can still reset one, which is what somebody reaching for "forgot password" was asking for. And a reset still removes every passkey, per #42, because nothing about that path identifies who asked. What it does not do is sever the Google identity, and that asymmetry is deliberate: a passkey is a credential this shop issued and can revoke, while a Google identity is one Google holds, and cutting it would leave the customer unable to use the button they signed up with for no gain — whoever completed the reset controls the mailbox either way.
The account page is told whether a password exists, and nothing more. Offering to change a password to somebody who has never had one is a dead end; saying nothing leaves them unable to see a credential they are entitled to manage. So the panel is titled for what it does for this customer, the current-password field is absent rather than disabled, and the confirmation says they can now sign in with it as well as with Google.
Verified: backend tsc clean for src and tests, 590 unit tests pass, lint at the seven warnings that predate this branch, frontend tsc, lint and build clean. The integration suite needs a database this machine has no Docker for.
Closes#344
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #344. Phase 5 of six under #332.
The first accounts in this project's history have no password. Several things that were true stop being true, and a check written a month ago finally becomes reachable.
One route for setting and changing
A customer who signed up with Google cannot supply a value that was never set, so asking for one is a dead end. What authorises the change is the session they already hold, which authorises every other setting on the account page.
One route rather than two, because two would be two places to get the guard wrong and the one that gets forgotten is whichever is not exercised by hand. The branch reads the stored hash, never anything the caller sends, so a request cannot talk its way into the first-password case by omitting a field. There is a test for exactly that.
Changing the email address is refused instead
The asymmetry is the point. Setting a first password changes a credential the customer already controls. Changing the address changes where recovery goes — whoever holds the new one can reset the password and own the account outright.
That is why this route has always demanded more than a live session, and dropping the demand for the accounts that cannot meet it would remove the protection from exactly the ones that need it. The message names the way out rather than claiming a password was wrong when there is none.
Login is untouched, deliberately
Answering "this account has no password" to a submitted address would turn the login form into an oracle for which customers use Google. It keeps the single refusal, and the account page is where a signed-in customer learns what they have.
Two tests pin it, including the one where both the supplied password and the stored hash are empty — the combination most tempting to call a match, and the one that would let anyone sign in as any Google-only customer.
The lockout guard finally runs
DELETE /me/passkeys/:idhas refused to remove a customer's only way in since #40, written against the condition rather than the schema, and unreachable ever since becausepassword_hashwasNOT NULL.Three tests exercise it now: refused when it is the only way in, allowed when a second passkey remains, allowed once a password has been set.
Two things about password reset, checked rather than assumed
Both turn out to be right as they stand.
A customer who never had a password can still reset one, which is what somebody reaching for "forgot password" was asking for. And a reset still removes every passkey per #42, because nothing on that path identifies who asked.
What it does not do is sever the Google identity, and that asymmetry is deliberate. A passkey is a credential this shop issued and can revoke; a Google identity is one Google holds. Cutting it would leave the customer unable to use the button they signed up with, for no gain — whoever completed the reset controls the mailbox either way.
What the account page is told
has_password, and nothing more. Whether, never what.The panel is titled for what it does for this customer, the current-password field is absent rather than disabled, and the confirmation says they can now sign in with it as well as with Google. A test asserts the hash never appears in the payload.
Also
Deletion needed no change, because it never asked for a password. That corrects what #332 recorded, and there is now a test so it stays true.
Testing
Twenty-two new integration tests in a suite of their own.
Verified locally: backend
tscclean for src and tests, 590 unit tests pass, lint at the seven warnings that predate this branch; frontendtsc, lint and build clean. The integration suite needs a database this machine has no Docker for.🤖 Generated with Claude Code