mozilla/browserid — pull request #2947 by 6a68 (2013-01-17 03:02:41+00:00)
Title: Issue 2891 email normalization

NOT READY TO BE MERGED YET. JUST LOOKING FOR INPUT.

This is in a bit of a weird state currently.

Initially, I just threw the normalize call inside the address_info wsapi, added unit tests for two of the email normalization bugs to address_info tests, and got them to pass.

After getting that to pass, I looked for a more natural place to globally normalize emails, and decided to expand on what lib/validate is already doing. Since lib/validate just throws on validation error, killing the current request with an error, I thought I'd add a separate sanitize step after validation succeeds. This is barely implemented in the current code.

Is wsapi.js the right place to add sanitization? Is it too implicit, too magical? I think the alternative is to call normalizeEmail inside each wsapi that handles email--a step that could easily be forgotten. I'm cool either way, or open to other suggestions.

Assuming the normalization code is in the right place, I'd next like to return display emails by adding a display_email field to the DB, returning it where user info is returned by the server (IIRC list_emails and address_info wsapi output). If a user has no display_email, just let it be the same as the email field.

To insert un-normalized display_emails into the DB, I think I'd need to add a display_email or raw_email param to the signup endpoints, and add this to the lib/validate set of types. The idea is to validate, but not normalize, display_emails.

Once this is done, I'll ensure all the dialog and site code handles display emails appropriately and add tests.

After that, finally, I'll add unit tests for the bugs caused by assertion case mismatch to be certain we've fixed that bug.

This is taking a while, but it's a great intro bug, and I think I'm catching on--hope to get this fully done tomorrow or Friday. Am I on the right track? Comments welcome.