Re: #20824 - Email-based auth contrib module; some help required
On Thu, 2014-02-27 at 20:11 -0800, schinckel wrote: > But there's the rub. Whilst for _most_ email servers, this will indeed > send mail to the same account, there's nowhere that says this _must_ > happen. I agree. Reading RFC 822, it says The domain-dependent string is uninterpreted, except by the final sub-domain; the rest of the mail service merely transmits it as a literal string. and The local-part of an addr-spec in a mailbox specification (i.e., the host's name for the mailbox) is understood to be whatever the receiving mail protocol server allows. So normalize_email() already does the right thing by normalising the domain part, and leaving the local part alone. It is my understanding that normalising the local part (by e.g. lowercasing) is never the right thing. There are three possible situations: 1. Receiving MTA does not care about case: Users can enter whatever form they like, and expect to receive their mail. No problem with normalisation in Django, although it might be good to preserve the user's preferred form. User@... and user@... are actually the same address on the MTA, so enforcing uniqueness with iexact lookup is no problem, and acutally necessary to catch all variants the user might enter on login. 2. Receiving MTA does care about case: Django must preserve case in local part if we care about such users receiving email from us. We can trust the users of such a MTA to enter the right case. Enforcing uniqueness across case is not necessary, but not a problem either unless... 3. ... there are actually distinct accounts with User@... and user@... (and USER@... etc.) on that MTA, and more than one such user tries to register with a Django app. There is no way to support all three, and I think case 1. is by far the most common, followed by 2., and I am willing to bet that 3. does not happen in the wild. My preferred solution would be to leave normalize_email() as is, and to enforce case insensitive uniqueness by whatever means Django and/or the DBMS offers. Kind regards, Til -- 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/1393580930.9673.20.camel%40mother.subnetz.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: #20824 - Email-based auth contrib module; some help required
On Thu, 2014-02-27 at 08:43 +0800, Russell Keith-Magee wrote: > 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. Would it be possible to additionally guard in the save() method of the email User class against duplication by checking with "not filter(email__iexact=...).exists()"? The documentation could also explain how to manually add a constraint at the database level where this is supported. (The current kickstarter project for improved PostgreSQL support seems likely to add expression indexes to Django proper one day.) > 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. While there is no way to enforce this, it could at least be added to the documentation that get_by_natural_key() should be used for email based users, or filter(email__iexact=...). Kind regards, Til -- 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/1393581918.9673.31.camel%40mother.subnetz.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: #20824 - Email-based auth contrib module; some help required
The following may be a viable solution for the case-insensitive fields. (email, username, alias ... etc.) Look at lines: 23, 66 and 159. https://gist.github.com/un33k/9273782 Val On Fri, Feb 28, 2014 at 5:05 AM, Tilman Koschnick wrote: > On Thu, 2014-02-27 at 08:43 +0800, Russell Keith-Magee wrote: > > > 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. > > Would it be possible to additionally guard in the save() method of the > email User class against duplication by checking with "not > filter(email__iexact=...).exists()"? > > The documentation could also explain how to manually add a constraint at > the database level where this is supported. (The current kickstarter > project for improved PostgreSQL support seems likely to add expression > indexes to Django proper one day.) > > > 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. > > While there is no way to enforce this, it could at least be added to the > documentation that get_by_natural_key() should be used for email based > users, or filter(email__iexact=...). > > Kind regards, Til > > -- > 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/1393581918.9673.31.camel%40mother.subnetz.org > . > 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/CADy_H8G7ygPY%2BgT71C910Me_MnO67A%2BgaocpgGxUUoO%2BY7exNg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
1.6 reverse() escapes unreserved chars in path components
Django's django.core.urlresolvers.reverse() seems to have changed its
behavior in 1.6. It now runs the arguments through quote(), without
specifying the safe characters for path components. As a result:
on 1.4.10:
In [2]: reverse('test', args=['foo:bar'])
Out[2]: '/foo:bar'
but on 1.6.2:
In [2]: reverse('test', args=['foo:bar'])
Out[2]: '/foo%3Abar'
It would seem to me that this is a regression, as ":@-._~!$&'()*+,;=" are
all allowed unescaped in path segments AFAIK.
Cheers,
Erik
--
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/064ba557-a722-484f-93bf-423048b51b14%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
