[GH-ISSUE #290] Account's email uniqueness not enforced by database #219

New issue

Open

opened 2026-02-25 23:41:39 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 23:41:39 +03:00

Owner

Originally created by @cuu508 on GitHub (Sep 30, 2019).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/290

There's a race condition when creating an user account. It is possible to create two user accounts with the same email address, which causes various problems later.

Either the email column needs a uniqueness constraint, or or the username (which already has uniqueness contraint) needs to be generated from email in a deterministic way.

Originally created by @cuu508 on GitHub (Sep 30, 2019). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/290 There's a race condition when creating an user account. It is possible to create two user accounts with the same email address, which causes various problems later. Either the email column needs a uniqueness constraint, or or the username (which already has uniqueness contraint) needs to be generated from email in a deterministic way.

kerem added the

bug

label

2026-02-25 23:41:39 +03:00

kerem commented

2026-02-25 23:41:39 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 12, 2019):

I had fixed this by deriving username from email (and the username already has an uniqueness constraint, so problem solved...?)

Problem with this is that users can change their email addresses. Consider:

user@example.org creates an account. Account's username is HASH(user@example.com)
later, they change their account's email address to team@example.org. Account's username is still HASH(user@example.org)
they then try to invite user@example.org into the account. This fails with IntegrityError because HASH(user@example.org) is already taken.

@cuu508 commented on GitHub (Oct 12, 2019): I had fixed this by deriving username from email (and the username already has an uniqueness constraint, so problem solved...?) Problem with this is that users can change their email addresses. Consider: * user@example.org creates an account. Account's username is HASH(user@example.com) * later, they change their account's email address to team@example.org. Account's username is still HASH(user@example.org) * they then try to invite user@example.org into the account. This fails with IntegrityError because HASH(user@example.org) is already taken.

kerem commented

2026-02-25 23:41:39 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 12, 2019):

Adding an explicit uniqueness constraint to the email column seems like the cleaner solution. I'm not sure if there is an idiomatic way to do that in Django for the default User model. For time being, on the hosted service, I've just manually added a constraint in the database:

ALTER TABLE auth_user ADD CONSTRAINT unique_emails UNIQUE (email);

@cuu508 commented on GitHub (Oct 12, 2019): Adding an explicit uniqueness constraint to the email column seems like the cleaner solution. I'm not sure if there is an idiomatic way to do that in Django for the default User model. For time being, on the hosted service, I've just manually added a constraint in the database: ALTER TABLE auth_user ADD CONSTRAINT unique_emails UNIQUE (email);

kerem commented

2026-02-25 23:41:39 +03:00

Author

Owner

@immanuelfodor commented on GitHub (Jan 3, 2020):

FYI, you can't add a unique constraint in SQLite, but can create a unique index for the same effect: https://stackoverflow.com/a/15498225

CREATE UNIQUE INDEX unique_email ON auth_user(email);

Added this manually after https://github.com/healthchecks/healthchecks/issues/306#issuecomment-570526115

@immanuelfodor commented on GitHub (Jan 3, 2020): FYI, you can't add a unique constraint in SQLite, but can create a unique index for the same effect: https://stackoverflow.com/a/15498225 ```sql CREATE UNIQUE INDEX unique_email ON auth_user(email); ``` Added this manually after https://github.com/healthchecks/healthchecks/issues/306#issuecomment-570526115