On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote: > > normalize_email will indeed allow both us...@example.com <javascript:>and > us...@example.com <javascript:> 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. >
How about a more common real world situation -- on mobile devises? They will often "helpfully" assume the first letter of the first word in a field should be uppercase and do so for you. You have to be paying attention and specifically tap the shift key before typing to turn it off, then type your email address. This is an annoyance of mine because native UIs will often recognize that you are typing in an email field and not do this (even giving you a custom keyboard with the @ symbol), but web pages will not. Perhaps on some devices <input type=email/> does the right thing -- but in my experience it isn't consistent (based on general observations only). The point is that the user will inadvertently type u...@example.com on their mobile device after registering with u...@example.com on their desktop/laptop. And they won't understand why they can't log in if it is case sensitive. Given that both addresses will deliver email to the same email account, it seems to me that both should be valid for the same account as an email based username on a sign-in form. Waylan Limberg > 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.comand >> us...@example.com 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>wrote: >> >>> >>> On Thu, Feb 27, 2014 at 8:31 AM, Curtis Maloney < >>> cur...@acommoncreative.com> 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. >>> To post to this group, send email to django-d...@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/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/30f6abcc-d1fc-417d-aa44-aa5b519bdc54%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
