Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Daniel Stanton
Following the end of https://code.djangoproject.com/ticket/2273 over a year ago, could this be reconsidered please?

By using username__iexact when checking for uniqueness for new usernames, this wouldn't affect any usernames that already exist, and it's then up to the administrators to decide if they want all users to conform to this and take advantage of knowing all usernames are unique when ignoring case, or if it makes no difference to them - either way, it becomes their legacy, not Django's.

As far as adding a feature flag for this, is that really required? I can't imagine any use case where not using iexact would be the preferred option. Would it be helpful to ask the community?

I'm certainly not an experienced developer, so it'd really be great to understand the reasons against. Thanks!

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/725c6664-ba1b-409a-a723-03e36e94e2e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Tim Graham-2
I can't think of a reason not to make the suggested change. It seems like an odd requirement if a site *requires* allowing new usernames to be case-sensitive.

On Saturday, August 29, 2015 at 12:27:39 PM UTC-4, Daniel Stanton wrote:
Following the end of<a href="https://code.djangoproject.com/ticket/2273" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F2273\46sa\75D\46sntz\0751\46usg\75AFQjCNFBJNguamM9dqbmMHg7RMn9q0tQFg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F2273\46sa\75D\46sntz\0751\46usg\75AFQjCNFBJNguamM9dqbmMHg7RMn9q0tQFg&#39;;return true;"> https://code.djangoproject.com/ticket/2273 over a year ago, could this be reconsidered please?

By using username__iexact when checking for uniqueness for new usernames, this wouldn't affect any usernames that already exist, and it's then up to the administrators to decide if they want all users to conform to this and take advantage of knowing all usernames are unique when ignoring case, or if it makes no difference to them - either way, it becomes their legacy, not Django's.

As far as adding a feature flag for this, is that really required? I can't imagine any use case where not using iexact would be the preferred option. Would it be helpful to ask the community?

I'm certainly not an experienced developer, so it'd really be great to understand the reasons against. Thanks!

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/32abe340-de1f-4ae0-8b98-f1df2448d22d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Florian Apolloner


On Saturday, August 29, 2015 at 7:08:45 PM UTC+2, Tim Graham wrote:
I can't think of a reason not to make the suggested change. It seems like an odd requirement if a site *requires* allowing new usernames to be case-sensitive.

Which is? Following the ticket I do not see any clear consenus at all. Imo Registration apps should handle that, which is not something Django ships with. I am -0 on changing the admin to disallow such users.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/84a05bde-f49e-4f6f-8b54-b04083041e15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

James Bennett
On Sat, Aug 29, 2015 at 1:54 PM, Florian Apolloner <[hidden email]> wrote:
Which is? Following the ticket I do not see any clear consenus at all. Imo Registration apps should handle that, which is not something Django ships with. I am -0 on changing the admin to disallow such users.

For what it's worth, django-registration uses an 'iexact' lookup to check for duplicate usernames during signup. Treating case variations as the same username seems to be the standard on most sites I've used.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CAL13Cg9%2BqPcvJR7uvuM%2BNt2HKWkn0itpisNnoams7Qd-zdRO%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Tim Graham-2
The suggested change is to not allow a new user if there's a username__iexact match.

On Saturday, August 29, 2015 at 2:56:14 PM UTC-4, James Bennett wrote:
On Sat, Aug 29, 2015 at 1:54 PM, Florian Apolloner <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="HSlmA1T4EAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">f.apo...@...> wrote:
Which is? Following the ticket I do not see any clear consenus at all. Imo Registration apps should handle that, which is not something Django ships with. I am -0 on changing the admin to disallow such users.

For what it's worth, django-registration uses an 'iexact' lookup to check for duplicate usernames during signup. Treating case variations as the same username seems to be the standard on most sites I've used.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/acbbb18a-45f1-4147-bbd4-cb7e4bd1b3ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

James Bennett
Yeah, that was why I pointed out django-registration already does this. Last time I looked at user-signup apps, it seemed that was the common practice, and also non-Django-powered sites I've used tend to do this. Allowing variations in case to be different users raises a lot of problems of potential impersonation.

On Sat, Aug 29, 2015 at 2:59 PM, Tim Graham <[hidden email]> wrote:
The suggested change is to not allow a new user if there's a username__iexact match.

On Saturday, August 29, 2015 at 2:56:14 PM UTC-4, James Bennett wrote:
On Sat, Aug 29, 2015 at 1:54 PM, Florian Apolloner <[hidden email]> wrote:
Which is? Following the ticket I do not see any clear consenus at all. Imo Registration apps should handle that, which is not something Django ships with. I am -0 on changing the admin to disallow such users.

For what it's worth, django-registration uses an 'iexact' lookup to check for duplicate usernames during signup. Treating case variations as the same username seems to be the standard on most sites I've used.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/acbbb18a-45f1-4147-bbd4-cb7e4bd1b3ab%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CAL13Cg--p4T8dNmfoG6a0i71Ri0XW-jvZUU-%3DUzUS4gM8%3DU2bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Florian Apolloner
In reply to this post by Tim Graham-2


On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
The suggested change is to not allow a new user if there's a username__iexact match.

Yes, but as change to what? To the admin interface? this will only cover admin usage. To a full_clean of the user model [This is often not used anyways]? I am somewhat against that…

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Collin Anderson-2
I propose adding a check on UserCreationForm (used by the admin). The current implementation relies on the model fields unique=True check which is case-sensitive (except on mysql).

Whenever I've made a login form, I've always used or made a copy of or at least studied UserCreationForm. I think if we had a nice walk through of how to create your own form which included the iexact hint, I think that would also help solve this problem.

On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner <[hidden email]> wrote:


On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
The suggested change is to not allow a new user if there's a username__iexact match.

Yes, but as change to what? To the admin interface? this will only cover admin usage. To a full_clean of the user model [This is often not used anyways]? I am somewhat against that…

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CAFO84S6yF4dyY8ZiLwDu5D_0ffT6Qe%3D1NoRMwD1GccsNtPc4qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Reid Ransom
Is it reasonable to consider changing the default for usernames to be case-insensitive in 2.0?

On Sunday, August 30, 2015 at 12:11:35 PM UTC-4, Collin Anderson wrote:
I propose adding a check on UserCreationForm (used by the admin). The current implementation relies on the model fields unique=True check which is case-sensitive (except on mysql).

Whenever I've made a login form, I've always used or made a copy of or at least studied UserCreationForm. I think if we had a nice walk through of how to create your own form which included the iexact hint, I think that would also help solve this problem.

On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Ww3kQew9EQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">f.apo...@...> wrote:


On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
The suggested change is to not allow a new user if there's a username__iexact match.

Yes, but as change to what? To the admin interface? this will only cover admin usage. To a full_clean of the user model [This is often not used anyways]? I am somewhat against that…

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="Ww3kQew9EQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="Ww3kQew9EQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="http://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;http://groups.google.com/group/django-developers&#39;;return true;">http://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com?utm_medium\75email\46utm_source\75footer&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com?utm_medium\75email\46utm_source\75footer&#39;;return true;">https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/8f02e173-d385-4d96-9dda-1fd6801f97f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Simon Charette
Hi Reid,

2.0 is not planned to be a special release in regard to backward compatibility.

Since this is a backward incompatible change (what should be done with
duplicate usernames, etc.) I doubt it's going to happen.

Simon

Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
Is it reasonable to consider changing the default for usernames to be case-insensitive in 2.0?

On Sunday, August 30, 2015 at 12:11:35 PM UTC-4, Collin Anderson wrote:
I propose adding a check on UserCreationForm (used by the admin). The current implementation relies on the model fields unique=True check which is case-sensitive (except on mysql).

Whenever I've made a login form, I've always used or made a copy of or at least studied UserCreationForm. I think if we had a nice walk through of how to create your own form which included the iexact hint, I think that would also help solve this problem.

On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner <[hidden email]> wrote:


On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
The suggested change is to not allow a new user if there's a username__iexact match.

Yes, but as change to what? To the admin interface? this will only cover admin usage. To a full_clean of the user model [This is often not used anyways]? I am somewhat against that…

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 [hidden email].
Visit this group at <a href="http://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;http://groups.google.com/group/django-developers&#39;;return true;">http://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com?utm_medium\75email\46utm_source\75footer&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com?utm_medium\75email\46utm_source\75footer&#39;;return true;">https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/a7c3add7-d13d-4b5c-af73-ac74cbc1c6a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

mtnpaul-2
Perhaps I'm missing something, but this would not change current users, only the creation of new users. It seems that logins would still be case sensitive. It would just prevent new users from being created that would match in a case insensitive manner with an existing user. For example existing users:

SomeUser and someuser could still use the site in the same manner as the login process would still be case sensitive. But a new user could not signup with a username of someUser.   



On Wed, Oct 21, 2015 at 1:59 PM, charettes <[hidden email]> wrote:
Hi Reid,

2.0 is not planned to be a special release in regard to backward compatibility.

Since this is a backward incompatible change (what should be done with
duplicate usernames, etc.) I doubt it's going to happen.

Simon

Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
Is it reasonable to consider changing the default for usernames to be case-insensitive in 2.0?

On Sunday, August 30, 2015 at 12:11:35 PM UTC-4, Collin Anderson wrote:
I propose adding a check on UserCreationForm (used by the admin). The current implementation relies on the model fields unique=True check which is case-sensitive (except on mysql).

Whenever I've made a login form, I've always used or made a copy of or at least studied UserCreationForm. I think if we had a nice walk through of how to create your own form which included the iexact hint, I think that would also help solve this problem.

On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner <[hidden email]> wrote:


On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
The suggested change is to not allow a new user if there's a username__iexact match.

Yes, but as change to what? To the admin interface? this will only cover admin usage. To a full_clean of the user model [This is often not used anyways]? I am somewhat against that…

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/650405a3-c860-4d84-be94-5b6a6c779aa2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/a7c3add7-d13d-4b5c-af73-ac74cbc1c6a0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CAD4jHOLL_PqyERHO4ypx-j%3Dp8K%3Dz1vZc8jBo1roZh_LL2zHWag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Shai Berger
Hi,

On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> Perhaps I'm missing something, but this would not change current users,
> only the creation of new users. It seems that logins would still be case
> sensitive.

Not the way Reid presented it:

> > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> >> Is it reasonable to consider changing the default for usernames to be
> >> case-insensitive in 2.0?

I think, though, it would be easy enough for us to provide a new, case-
insensitive base class for users, and change the recommendations in our
documentation to tell users to inherit that rather than the current
AbstractBaseUser and AbstractUser. We could also write a simple management
command to validate lower-case uniquness and turn all usernames to lowercase,
as preparation for changing the login and registration logic.

These could all be done outside of core, and perhaps they should be -- the
only point I see for including them in core is the risk that, as a developer,
if core doesn't make you think about it from the get-go, by the time you
decide to make the change you may be stuck with conflicting (lower-case equal)
usernames in your database. But frankly, I would guess that this problem does
not really occur very often; that for most sites, if they decide to switch to
case-insensitive usernames, there would be no problem.

Regretfully, we can't just switch Django to do that, because of the few sites
who will have a problem, and no clear upgrade path.

Shai.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Reid Ransom
Yesterday, I noticed a couple users had created multiple accounts with
different capitalization.  One person had 4 accounts.  I've also gotten
a lot of complaints from users that were having trouble logging in.  My
response was generally "Use the forgot password link." but now I'm 
realizing that they probably had difficulty remembering their username
capitalization they used during registration or didn't know the
capitalization our staff used to create their account.

I was already working with a custom user model and all my
conflicting usernames were for the same people so this wasn't too hard
to fix.  Still I would expect Django to want devs to start with case-
insensitive for the reasons already cited in this thread but also since
it's much easier to switch to case-sensitive later if that's what you
really want.

Shai- Could an upgrade path for what you proposed be to change the
AUTH_USER_MODEL setting?


On Wednesday, October 21, 2015 at 5:39:47 PM UTC-4, Shai Berger wrote:
Hi,

On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> Perhaps I'm missing something, but this would not change current users,
> only the creation of new users. It seems that logins would still be case
> sensitive.

Not the way Reid presented it:

> > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> >> Is it reasonable to consider changing the default for usernames to be
> >> case-insensitive in 2.0?

I think, though, it would be easy enough for us to provide a new, case-
insensitive base class for users, and change the recommendations in our
documentation to tell users to inherit that rather than the current
AbstractBaseUser and AbstractUser. We could also write a simple management
command to validate lower-case uniquness and turn all usernames to lowercase,
as preparation for changing the login and registration logic.

These could all be done outside of core, and perhaps they should be -- the
only point I see for including them in core is the risk that, as a developer,
if core doesn't make you think about it from the get-go, by the time you
decide to make the change you may be stuck with conflicting (lower-case equal)
usernames in your database. But frankly, I would guess that this problem does
not really occur very often; that for most sites, if they decide to switch to
case-insensitive usernames, there would be no problem.

Regretfully, we can't just switch Django to do that, because of the few sites
who will have a problem, and no clear upgrade path.

Shai.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/4d33cc01-84bd-49b8-8d90-3770a2766921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

mtnpaul-2
In reply to this post by Shai Berger
Yeah, I was referring to the post by Daniel at the start of the thread, not Reid's comment.

I would be -1 on changing the check of usernames at login to case-insensitive. But I would be +1 with preventing the creation of new usernames which would match existing usernames in a case-insensitive manner.

On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger <[hidden email]> wrote:
Hi,

On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> Perhaps I'm missing something, but this would not change current users,
> only the creation of new users. It seems that logins would still be case
> sensitive.

Not the way Reid presented it:

> > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> >> Is it reasonable to consider changing the default for usernames to be
> >> case-insensitive in 2.0?

I think, though, it would be easy enough for us to provide a new, case-
insensitive base class for users, and change the recommendations in our
documentation to tell users to inherit that rather than the current
AbstractBaseUser and AbstractUser. We could also write a simple management
command to validate lower-case uniquness and turn all usernames to lowercase,
as preparation for changing the login and registration logic.

These could all be done outside of core, and perhaps they should be -- the
only point I see for including them in core is the risk that, as a developer,
if core doesn't make you think about it from the get-go, by the time you
decide to make the change you may be stuck with conflicting (lower-case equal)
usernames in your database. But frankly, I would guess that this problem does
not really occur very often; that for most sites, if they decide to switch to
case-insensitive usernames, there would be no problem.

Regretfully, we can't just switch Django to do that, because of the few sites
who will have a problem, and no clear upgrade path.

Shai.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/CAD4jHOKk3p6kh7sRrUp4G6JxCA-CpeV7bhuABE0PwSUBW8EO-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

bliyanage
> -1 on changing the check of usernames at login to case-insensitive
> +1 with preventing the creation of new usernames

Ditto

On Thursday, October 22, 2015 at 9:33:02 AM UTC-7, mtnpaul wrote:
Yeah, I was referring to the post by Daniel at the start of the thread, not Reid's comment.

I would be -1 on changing the check of usernames at login to case-insensitive. But I would be +1 with preventing the creation of new usernames which would match existing usernames in a case-insensitive manner.

On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="LJSJ_d9IDQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">sh...@...> wrote:
Hi,

On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> Perhaps I'm missing something, but this would not change current users,
> only the creation of new users. It seems that logins would still be case
> sensitive.

Not the way Reid presented it:

> > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> >> Is it reasonable to consider changing the default for usernames to be
> >> case-insensitive in 2.0?

I think, though, it would be easy enough for us to provide a new, case-
insensitive base class for users, and change the recommendations in our
documentation to tell users to inherit that rather than the current
AbstractBaseUser and AbstractUser. We could also write a simple management
command to validate lower-case uniquness and turn all usernames to lowercase,
as preparation for changing the login and registration logic.

These could all be done outside of core, and perhaps they should be -- the
only point I see for including them in core is the risk that, as a developer,
if core doesn't make you think about it from the get-go, by the time you
decide to make the change you may be stuck with conflicting (lower-case equal)
usernames in your database. But frankly, I would guess that this problem does
not really occur very often; that for most sites, if they decide to switch to
case-insensitive usernames, there would be no problem.

Regretfully, we can't just switch Django to do that, because of the few sites
who will have a problem, and no clear upgrade path.

Shai.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/9b0d5977-e42e-4e66-a348-e422bf2d252b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Collin Anderson-2
I also agree. And to be clear, we're talking about UserCreationForm, right? Or where specifically would we implement this? (What part of Django do you use that doesn't check this?)

On Monday, October 26, 2015 at 2:04:24 PM UTC-4, [hidden email] wrote:
> -1 on changing the check of usernames at login to case-insensitive
> +1 with preventing the creation of new usernames

Ditto

On Thursday, October 22, 2015 at 9:33:02 AM UTC-7, mtnpaul wrote:
Yeah, I was referring to the post by Daniel at the start of the thread, not Reid's comment.

I would be -1 on changing the check of usernames at login to case-insensitive. But I would be +1 with preventing the creation of new usernames which would match existing usernames in a case-insensitive manner.

On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger <[hidden email]> wrote:
Hi,

On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> Perhaps I'm missing something, but this would not change current users,
> only the creation of new users. It seems that logins would still be case
> sensitive.

Not the way Reid presented it:

> > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> >> Is it reasonable to consider changing the default for usernames to be
> >> case-insensitive in 2.0?

I think, though, it would be easy enough for us to provide a new, case-
insensitive base class for users, and change the recommendations in our
documentation to tell users to inherit that rather than the current
AbstractBaseUser and AbstractUser. We could also write a simple management
command to validate lower-case uniquness and turn all usernames to lowercase,
as preparation for changing the login and registration logic.

These could all be done outside of core, and perhaps they should be -- the
only point I see for including them in core is the risk that, as a developer,
if core doesn't make you think about it from the get-go, by the time you
decide to make the change you may be stuck with conflicting (lower-case equal)
usernames in your database. But frankly, I would guess that this problem does
not really occur very often; that for most sites, if they decide to switch to
case-insensitive usernames, there would be no problem.

Regretfully, we can't just switch Django to do that, because of the few sites
who will have a problem, and no clear upgrade path.

Shai.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/7215cbeb-a296-47a6-b1b1-ca04a7a16af2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Tim Graham-2
I created https://code.djangoproject.com/ticket/25617 - Disallow usernames that differ only in case in UserCreationForm.

Please voice any concerns on that ticket.

On Monday, October 26, 2015 at 2:24:27 PM UTC-4, Collin Anderson wrote:
I also agree. And to be clear, we're talking about UserCreationForm, right? Or where specifically would we implement this? (What part of Django do you use that doesn't check this?)

On Monday, October 26, 2015 at 2:04:24 PM UTC-4, [hidden email] wrote:
> -1 on changing the check of usernames at login to case-insensitive
> +1 with preventing the creation of new usernames

Ditto

On Thursday, October 22, 2015 at 9:33:02 AM UTC-7, mtnpaul wrote:
Yeah, I was referring to the post by Daniel at the start of the thread, not Reid's comment.

I would be -1 on changing the check of usernames at login to case-insensitive. But I would be +1 with preventing the creation of new usernames which would match existing usernames in a case-insensitive manner.

On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger <[hidden email]> wrote:
Hi,

On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> Perhaps I'm missing something, but this would not change current users,
> only the creation of new users. It seems that logins would still be case
> sensitive.

Not the way Reid presented it:

> > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> >> Is it reasonable to consider changing the default for usernames to be
> >> case-insensitive in 2.0?

I think, though, it would be easy enough for us to provide a new, case-
insensitive base class for users, and change the recommendations in our
documentation to tell users to inherit that rather than the current
AbstractBaseUser and AbstractUser. We could also write a simple management
command to validate lower-case uniquness and turn all usernames to lowercase,
as preparation for changing the login and registration logic.

These could all be done outside of core, and perhaps they should be -- the
only point I see for including them in core is the risk that, as a developer,
if core doesn't make you think about it from the get-go, by the time you
decide to make the change you may be stuck with conflicting (lower-case equal)
usernames in your database. But frankly, I would guess that this problem does
not really occur very often; that for most sites, if they decide to switch to
case-insensitive usernames, there would be no problem.

Regretfully, we can't just switch Django to do that, because of the few sites
who will have a problem, and no clear upgrade path.

Shai.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/6f58a275-f4a5-471a-8cb5-69db618cc055%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Info-Screen
In reply to this post by Daniel Stanton
Wouldn't it be possible to implement case-insensitive usernames without loosing backwards compatibility, by checking the username iexact and only if there are multiple possibilities fall back to the old case-sensitive variant?

So something like this:

diff --git a/django/contrib/auth/base_user.py b/django/contrib/auth/base_user.py
index 34dd6ac2f2..748db8bf89 100644
--- a/django/contrib/auth/base_user.py
+++ b/django/contrib/auth/base_user.py
@@ -4,6 +4,7 @@ not in INSTALLED_APPS.
 """
 import unicodedata
 
+from django.core.exceptions import MultipleObjectsReturned
 from django.contrib.auth import password_validation
 from django.contrib.auth.hashers import (
     check_password, is_password_usable, make_password,
@@ -41,7 +42,14 @@ class BaseUserManager(models.Manager):
         return get_random_string(length, allowed_chars)
 
     def get_by_natural_key(self, username):
-        return self.get(**{self.model.USERNAME_FIELD: username})
+        username_field = self.model.USERNAME_FIELD
+
+        # Try case-insensitive match of username.
+        # If there are multiple possiblities fallback to case-sensitive lookup
+        try:
+            return self.get(**{username_field + '__iexac': username})
+        except MultipleObjectsReturned:
+            return self.get(**{username_field: username})
 
 
 class AbstractBaseUser(models.Model):

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Tobias McNulty
I'm surprised that (as far as I can see) this idea hasn't been discussed in the ~11 year (!) history of this ticket. It was alluded to ~3 years go by mkhalil28, but was missing the backwards-compatible 'except' bit and didn't get any follow-up discussion. To me this seems like an appropriate corresponding change to #25617.

If I'm thinking through this correctly, this would provide, for all intents and purposes:
  • case-insensitive usernames for all new sites (and new users on existing sites)
  • indefinite backwards compatibility for sites that already have "duplicate" usernames in the database, when case is ignored
  • no feature flag that needs to be maintained
  • the added benefit of allowing sites that really want case-sensitive usernames to disable this behavior, if needed (by never adding unique=True to the username field)
If a change like this has been considered already, I am curious to know why it was rejected.

I am not suggesting (yet) that we re-open #2273, but I think this would at least be worth exploring further: What would a minimum-impact change for case-insensitive usernames look like, both in terms of code and documentation changes? #25617 + this change seem like a good start, but more work will certainly be required to get this into a state that's ready for formal review. I probably won't have time to do that myself in the near future, but I would be happy to serve as a reviewer.

Tobias


Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com


On Sun, Apr 16, 2017 at 5:47 PM, Info-Screen <[hidden email]> wrote:
Wouldn't it be possible to implement case-insensitive usernames without loosing backwards compatibility, by checking the username iexact and only if there are multiple possibilities fall back to the old case-sensitive variant?

So something like this:

diff --git a/django/contrib/auth/base_user.py b/django/contrib/auth/base_user.py
index 34dd6ac2f2..748db8bf89 100644
--- a/django/contrib/auth/base_user.py
+++ b/django/contrib/auth/base_user.py
@@ -4,6 +4,7 @@ not in INSTALLED_APPS.
 """
 import unicodedata
 
+from django.core.exceptions import MultipleObjectsReturned
 from django.contrib.auth import password_validation
 from django.contrib.auth.hashers import (
     check_password, is_password_usable, make_password,
@@ -41,7 +42,14 @@ class BaseUserManager(models.Manager):
         return get_random_string(length, allowed_chars)
 
     def get_by_natural_key(self, username):
-        return self.get(**{self.model.USERNAME_FIELD: username})
+        username_field = self.model.USERNAME_FIELD
+
+        # Try case-insensitive match of username.
+        # If there are multiple possiblities fallback to case-sensitive lookup
+        try:
+            return self.get(**{username_field + '__iexac': username})
+        except MultipleObjectsReturned:
+            return self.get(**{username_field: username})
 
 
 class AbstractBaseUser(models.Model):

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKQaa4RX31yJqOapRvehH8GBPObybJmLCJ44JqT0OZpqFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

Info-Screen
I might be able to try to implement this. I'm new to django, but let's try

On Monday, April 17, 2017 at 4:13:23 PM UTC+2, Tobias McNulty wrote:
I'm surprised that (as far as I can see) this idea hasn't been discussed in the ~11 year (!) history of this ticket. It was <a href="https://code.djangoproject.com/ticket/2273#comment:12" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F2273%23comment%3A12\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEHiJwUe8Ciqu3hu100MFY-ViEsaA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F2273%23comment%3A12\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEHiJwUe8Ciqu3hu100MFY-ViEsaA&#39;;return true;">alluded to ~3 years go by mkhalil28, but was missing the backwards-compatible 'except' bit and didn't get any follow-up discussion. To me this seems like an appropriate corresponding change to <a href="https://code.djangoproject.com/ticket/25617" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25617\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOMcYMHueC-BTszOmOKpe2CgPXjg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25617\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOMcYMHueC-BTszOmOKpe2CgPXjg&#39;;return true;">#25617.

If I'm thinking through this correctly, this would provide, for all intents and purposes:
  • case-insensitive usernames for all new sites (and new users on existing sites)
  • indefinite backwards compatibility for sites that already have "duplicate" usernames in the database, when case is ignored
  • no feature flag that needs to be maintained
  • the added benefit of allowing sites that really want case-sensitive usernames to disable this behavior, if needed (by never adding unique=True to the username field)
If a change like this has been considered already, I am curious to know why it was rejected.

I am not suggesting (yet) that we re-open #2273, but I think this would at least be worth exploring further: What would a minimum-impact change for case-insensitive usernames look like, both in terms of code and documentation changes? #25617 + this change seem like a good start, but more work will certainly be required to get this into a state that's ready for formal review. I probably won't have time to do that myself in the near future, but I would be happy to serve as a reviewer.

Tobias


Tobias McNulty
Chief Executive Officer

<a href="javascript:" style="color:rgb(108,122,120);text-decoration:none" target="_blank" gdf-obfuscated-mailto="QxeY5iROBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">tob...@...
<a href="http://www.caktusgroup.com/" style="color:rgb(108,122,120);text-decoration:none" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.caktusgroup.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6RpHdHUA5QLae7099-vwv2NLrvg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.caktusgroup.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6RpHdHUA5QLae7099-vwv2NLrvg&#39;;return true;">www.caktusgroup.com


On Sun, Apr 16, 2017 at 5:47 PM, Info-Screen <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="QxeY5iROBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">info-...@...> wrote:
Wouldn't it be possible to implement case-insensitive usernames without loosing backwards compatibility, by checking the username iexact and only if there are multiple possibilities fall back to the old case-sensitive variant?

So something like this:

diff --git a/django/contrib/auth/base_user.py b/django/contrib/auth/base_user.py
index 34dd6ac2f2..748db8bf89 100644
--- a/django/contrib/auth/base_user.py
+++ b/django/contrib/auth/base_user.py
@@ -4,6 +4,7 @@ not in INSTALLED_APPS.
 """
 import unicodedata
 
+from django.core.exceptions import MultipleObjectsReturned
 from django.contrib.auth import password_validation
 from django.contrib.auth.hashers import (
     check_password, is_password_usable, make_password,
@@ -41,7 +42,14 @@ class BaseUserManager(models.Manager):
         return get_random_string(length, allowed_chars)
 
     def get_by_natural_key(self, username):
-        return self.get(**{self.model.USERNAME_FIELD: username})
+        username_field = self.model.USERNAME_FIELD
+
+        # Try case-insensitive match of username.
+        # If there are multiple possiblities fallback to case-sensitive lookup
+        try:
+            return self.get(**{username_field + '__iexac': username})
+        except MultipleObjectsReturned:
+            return self.get(**{username_field: username})
 
 
 class AbstractBaseUser(models.Model):

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="QxeY5iROBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="QxeY5iROBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e9615283-7a07-49d9-9fae-e3e0c4d23619%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
12