BrowserID.org should preserve case in emails. #1350

Closed
callahad opened this Issue Mar 29, 2012 · 13 comments

Projects

None yet

8 participants

@callahad
Mozilla member

We're currently downcasing email addresses, but doing it too late in the auth cycle. This means that a user can first assert FOO@example.com, but will subsequently assert foo@example.com.

Try it yourself!

  1. Log into myfavoritebeer.org as FOO@example.com. Note the "Yo, FOO@example.com!" text.
  2. Type in your favorite beer and hit enter to save.
  3. Log out of and back into myfavoritebeer.org, choosing the same identity.
  4. Note that it's now "Yo, foo@example.com!", and that your favorite beer appears to be gone!

(It's not really gone; it's just stored under FOO@example.com, which you can't assert again until you sign out of browserid.org.)

So, that sucks, what do we do?

RFC 2821 explicitly states that "the local-part of a mailbox MUST BE treated as case sensitive," but discourages hosts from actually creating case-sensitive mailboxes. It'd probably be best to take a similar approach and preserve the case that the user initially gives us, but allow them to log into browserid.org in a case-insensitive manner.

For a concrete example, say:

  1. A user verifies Foo@example.com with browserid.org.
  2. We store Foo@example.com in a case-preserving manner and assert Foo@example.com to RPs.
  3. The user logs out of browserid.org.
  4. The user attempts to log in to browserid.org as foo@example.com.
  5. We do a case-insensitive lookup, find the Foo@example.com account, authenticate the user against that, and assert Foo@example.com to RPs.

Thus, the user always asserts the same casing, but can log in to browserid.org without worrying about case.

Doesn't that break the RFC?

This deviates from the RFC for the sake of easing a common use case. We're letting users elect to present themselves with whatever casing they want (since it might be important), but assuming that no two people will have email addresses that differ only by case. This lets us automatically correct for typos when a user is logging into browserid.org.

We can further tweak this solution if it becomes problematic down the line.

What else should I look at?

This issue might also be relevant for #1104, #1328, and #1294.

Case sensitivity was brought up on the mailing list.

We also talked about this on IRC.

@lloyd

we should close down the other issues we have around email case and point them here

@ozten ozten was assigned Mar 29, 2012
@graingert

technically you probaly don't want to use email addresses but acct: URIs https://tools.ietf.org/html/draft-saintandre-acct-uri-01 (basically email addresses but can't necessarily receive email eg acct:graingert@eyedee.me exists mailto:graingert@eyedee.me does not

There might be enough time to wrestle them into having a stricter definition than:

acctURI = "acct:" userpart "@" host
userpart = 1*( unreserved / pct-encoded / sub-delims )

@jbonacci

+1 AWESOME!
Added the label...

@graingert

That test case redirects me to /, is that intentional?

@jbonacci

@graingert what do you mean?
Clicking the link above redirects you to "/" (whether or not you are already signed into MozTrap)?
Or the steps redirect you to "/"?

I have not seeing any issues.

@graingert

@jbonacci this: Clicking the link above redirects you to "/" (whether or not you are already signed into MozTrap)?

@jbonacci

@graingert - that is odd behavior, and unexpected... and, I can not duplicate it!
@csuciu and @jrgm can you try to duplicate this incorrect redirect?

@jrgm
Mozilla member

If not logged in, I am challenged, and on completion of that, I get redirected to / and that redirects to /runtests

If already logged in, https://moztrap.mozilla.org/manage/caseversion/3563/ redirects to / and that redirects to /runtests

@jrgm
Mozilla member

This is probably a permissions thing.

@graingert

ah it should be a 403 not a 302 ?

@callahad
Mozilla member

Have these been solved?

@shane-tomlinson
Mozilla member

Closing as we use the initial email address that the user types as the canonical email address. If the user returns and types in the same email address with different casing, the original email address, with the original casing, will be used instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment