normalize_email will indeed allow both u...@example.com and u...@example.com to be different entities. From the user perspective, this is an error. Most probably the user enters some day their email in all upper case because he pressed the CapsLock key, or copy pasted a transcript of his email, etc., the user could not be able to figure out the difference and simply could not log in.
Is preferable to think, in this case, in protecting the user from their own mistake (from our perspective as programmers), and do as Atul Bhouraskar says: transform the email data in a consistent way before insert/update/search to the DB. On Wednesday, February 26, 2014 8:31:40 PM UTC-4:30, Atul Bhouraskar wrote: > > Won't normalize_email will allow two distinct users > us...@example.com<javascript:>and > us...@example.com <javascript:> to be created? Case insensitive searches > will return multiple users for a 'get'. > > Perhaps the closest we can get is to ensure that any user created using > Django functions is saved with a consistent case transformation and then > perform an *exact* search after applying the same transformation to the > input? > > One idea could be to add a 'transform_email' or similar hook that by > default calls normalize_email and ensure that it is applied both to data > that is about to be saved and to search terms. Projects that wish to change > the behaviour can simply override transform_email to perform for example > lowercase conversion if so desired. > > Atul > > > On 27 February 2014 11:43, Russell Keith-Magee > <rus...@keith-magee.com<javascript:> > > wrote: > >> >> On Thu, Feb 27, 2014 at 8:31 AM, Curtis Maloney < >> cur...@acommoncreative.com <javascript:>> wrote: >> >>> Doesn't the UserManager already have a "normalize_email" method which >>> lower-cases the domain and leaves the mailbox name alone? >>> >>> IMHO It's "proper" to leave it this way by default, and probably mention >>> in the docs it's used so if you want to change it, that's the hook. >>> >> >> It does - assuming you use User.objects.create_user() to create all your >> users. However, the UserCreationForm doesn't use this (and hasn't ever used >> this); it also doesn't account for fixtures, or any other path into the >> database that might exist. >> >> So - while normalising case is probably a good idea, and should probably >> be added to the Create/Update User form, the searches will still need to be >> case insensitive. >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to >> django-d...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAJxq84_1%2B_oVDUAeHyXoFGTirsZEgejaY6q4hNK0EZGpqS96Wg%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/123a986f-8133-4af1-99aa-34f6227d467b%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
