Re: [Django] #21837: auth.User Email - non-RFC spec normalization

[Django]

#21837: auth.User Email - non-RFC spec normalization
-+-
 Reporter:  ross@…   |Owner:
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  authentication,  | Triage Stage:  Accepted
  email, filter, get, error  |  Needs documentation:  0
  nlsprint14 |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by mjtamlyn):

 As an aside, we have to be very careful encouraging case insensitive
 lookups due to index usage. On postgres you can make an index for this,
 but not in Django (for now). I'm unsure about other DBS.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.3cefa82984041c5cb87b5baef289d89c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21837: auth.User Email - non-RFC spec normalization

[Django]

#21837: auth.User Email - non-RFC spec normalization
-+-
 Reporter:  ross@…   |Owner:
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  authentication,  | Triage Stage:  Accepted
  email, filter, get, error  |  Needs documentation:  0
  nlsprint14 |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by erikr):

 * owner:  erikr =>
 * status:  assigned => new


Comment:

 Well, in the mean time this has been discussed on the side in
 https://groups.google.com/forum/#!msg/django-developers/7feYlp9HqKs -
 there's some RFC references in there too.

 Technically, the correct behaviour is to keep the case of the user part
 intact, and ignore case in the domain part. This is what `normalize_email`
 helps, by explicitly lowercasing the domain part. However, this is not
 consistently applied in e.g. UserCreateForm. With custom user models, the
 default behaviour for the username field (which could be an email address,
 but may not be) is to match case sensitive, without first applying
 normalize_email.

 There are two approaches:
 * The technically correct: when doing lookups on email addresses, either
 in Django or in third party apps, the value should always first be passed
 through `normalize_email`. The subsequent query should then be case
 sensitive. If a custom user model would use email as username, they could
 override `get_by_natural_key` to include normalizing. The downside is that
 if users accidentally enter an uppercase character, due to helpful auto-
 capitalisation for example, they have to use that on future entries too.
 * The more pragmatic: always match case insensitive on email addresses.
 This still needs a custom `get_by_natural_key` for custom user models,
 unless we make all username fields of any kind case insensitive by
 default. This is the current choice in the password reset view in
 django.contrib.auth. This means we can drop normalize_email. This has a
 very minor backwards compatibility issue if someone has a database with
 users where their email address only differs by case.

 I do think our current inconsistencies should be resolved, but have no
 strong preference to either approach. I'm a bit more inclined to option 2.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.8f2c396740b5d8217c891f75be19233b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21837: auth.User Email - non-RFC spec normalization

[Django]

#21837: auth.User Email - non-RFC spec normalization
-+-
 Reporter:  ross@…   |Owner:  erikr
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  authentication,  | Triage Stage:  Accepted
  email, filter, get, error  |  Needs documentation:  0
  nlsprint14 |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Erik, did you have a plan for this?

 I'm wondering why we bother with normalize_email. Can't we simply drop it?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.1d7dd5b385d4569a63b1511addc2ca63%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21837: auth.User Email - non-RFC spec normalization

[Django]

#21837: auth.User Email - non-RFC spec normalization
-+-
 Reporter:  ross@…   |Owner:  erikr
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  authentication,  | Triage Stage:
  email, filter, get, error  |  Unreviewed
  nlsprint14 |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by erikr):

 * status:  new => assigned
 * cc: eromijn@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => erikr
 * keywords:  authentication, email, filter, get, error => authentication,
 email, filter, get, error nlsprint14
 * needs_docs:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.c00fd4b93d1901015f5aa99e1a241fd3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21837: auth.User Email - non-RFC spec normalization

[Django]

#21837: auth.User Email - non-RFC spec normalization
-+-
 Reporter:  ross@…   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:   |Version:  1.6
  contrib.auth   |   Keywords:  authentication, email, filter, get,
 Severity:  Normal   |  error
 Triage Stage:   |  Has patch:  0
  Unreviewed |  UI/UX:  0
Easy pickings:  0|
-+-
 when a user signs up with mon...@baddomain.com

 auth.User.object.normalize_email() saves the email as mon...@baddomain.com
 to conform with RFC.

 But future lookups will return None due to  BadDomain.com != baddomain.com
 where the user continually enters mon...@baddomain.com because thats what
 in their muscle/chrome memory.

 1. normalize_email is applied at the orm level, but should (also?) be
 applied at the Field level to help with this problem.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/058.f33b8563a446f62978cab38c90996f04%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.