Open jace opened 7 years ago
Possible solution to the second problem with Gravatar, etc: store two normalised emails:
Lowercase normalised version, which has a unique constraint (in UserEmail
only). This is the reference for queries. It could be the existing LOWER(email)
index instead of a distinct column.
Application normalised version in which:
+
suffixes are removed,@googlemail.com
is replaced with @gmail.com
(ref), and@gmail.com
addressesThe application normalised version is used for discovery of a re-used email address, but uniqueness is not enforced, since there are legitimate reasons for users to re-use addresses. It may be used for relevant security checks if, for example, one version is used as a user's email address and another as a organisation's or team's, to warn the user that shared access to the email address may compromise their own account.
In #215 we enforced a lowercase index for email addresses. This is pragmatic as it is extremely unlikely that a given email domain will have the same account with different casings. Most providers prohibit this.
However, email addresses are case sensitive per RFC 5321:
A lower-cased email address may not actually be reachable. We should:
UserEmail
,UserEmailClaim
and other apps like Hasjob and Boxoffice).Rather than a SQL index on
LOWER(email)
, we should have anormalised_email
column on theUserEmail
model and place the unique index on that. By moving normalisation into the app, we handle special cases:@gmail.com
addresses, as Gmail disregards them.+
suffixes as those are the same mailbox (optional).Pending issues:
Does Gmail's period-ignoring behaviour apply to all G Suite domains?(Update: it doesn't)normalised_email
, we're also losing periods ingmail.com
addresses, which is not what Gravatar is expecting.