We store all email addresses in their own table. There are many reasons why this works for us and many why it might not make sense for others. Anyway, what this gives us is the ability to store related email address information in context and, specifically, that’s where our solution comes in using an id field on the email address record. The id is a hash of EmailAddress.address().toLowerCase(). Then when someone tries to log in we hash the input value and lookup fetch via User.emailAddress().id(). Obviously you have to consider collision and other concerns but we’ve been using this approach for close to two decades with great success.
Jon > On Feb 25, 2016, at 5:28 PM, Paul Hoadley <[email protected]> wrote: > > Hi Ted, > > On 26 Feb 2016, at 10:39 am, Theodore Petrosky <[email protected] > <mailto:[email protected]>> wrote: > >> I’ve been following this conversation, quite interesting. But, and this is >> just a question for the conversation. Is there any reason when the user >> registers that the user name (email address) isn’t folded into lowercase and >> stored that way? > > To be honest, that would probably work most of the time, possibly all of the > time. Here’s where I address the theoretical problem with it in the original > post: > >> 2. Although the domain part of an email address is case-insensitive, my >> understanding is that the relevant RFCs suggest that you shouldn’t make >> assumptions about the local part. While everything I’ve read claims that in >> practice it will make no difference, let’s assume that we need to preserve >> the address as entered at sign-up. (It’s fail-safe to do so, whether we >> strictly need to or not.) > > > Domain names are case-insensitive. So if I sign up with ‘[email protected] > <mailto:[email protected]>’ and you store ‘[email protected] > <mailto:[email protected]>’, there’s no problem—when you send me an email, > I will receive it. My understanding is that the relevant RFCs say, in > summary, that you shouldn’t make any assumptions about the local part. So if > I sign up with ‘[email protected] <mailto:[email protected]>’, and you > store ‘[email protected] <mailto:[email protected]>’, you can’t > _assume_ that will be delivered (even though it probably will be). Even if > the RFCs said explicitly that the local part was case-insensitive, you’re > relying on every MDA to implement that correctly. I don’t know of an example > MDA that is case-sensitive on the local part, but that doesn’t mean there > isn’t one. > > So, the fail-safe approach is to store what the user signed up with, and use > that as the literal email address when sending out email. As a nice UX > enhancement, at login time we want to make a case-insensitive comparison > between what the user enters in the textfield and what’s stored in the > database. It’s the latter problem we’re trying to solve here. > > > -- > Paul Hoadley > http://logicsquad.net/ <http://logicsquad.net/> > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/jon%40sitequesttech.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
