Hi David, I agree with your reasoning but I think you're missing an important detail about unicode username support: they have been mistakenly enabled on Python 3 since Django added support for it (1.5-1.6).
If we were to disallow non-ASCII characters silently from Django 1.10 Python 3 developers would be left with the same problem you mentioned about existing users with usernames containing unicode characters. Cheers, Simon Le jeudi 19 mai 2016 14:48:39 UTC-4, David Tan a écrit : > > - I'm afraid this change may result in boilerplate as most custom user >> models will revert to Django's historical (and in my opinion sensible) >> username validation rules. >> > > That's a tough question to estimate. This might be true for most English > monolingual web sites, but not necessarily for the majority of Django > sites. Hopefully we'll get some more user inputs in this thread. > > > Hi, just wanted to give my input on this point, I agree with Aymeric > Augustin here and my vote is to keep usernames as ASCII by default. > > I created a Django ticket > <https://code.djangoproject.com/ticket/26639#ticket> for this, I will > copy my reasoning here: > > A Django user who is trying to save time and get a product out the door > isn't going to focus on finer details such as Unicode usernames, and will > be in for a shock when he finds out a bunch of his users have registered > themselves with Egyptian hieroglyphics. He may be very frustrated, > eventually figuring out that he must subclass the User model and > setusername_validator > = ASCIIUsernameValidator() to get the functionality he expected. And what > is he to do with the existing Unicode users, delete all their accounts? > > Whereas a technologically forward user might be friendlier towards Unicode > usernames, and would be well-informed on these capabilities within Django. > Furthermore, the technologically forward user will be more likely to > already have a custom user model, and won't find it cumbersome to > explicitly enable Unicode usernames. Enabling Unicode usernames isn't > destructive like disabling it would be (no need to figure out what to do > with the existing users offending the validation), so users can simply > start using it immediately. > > On Sunday, April 24, 2016 at 2:58:55 PM UTC-4, Claude Paroz wrote: >> >> Hi Aymeric, >> >> Le samedi 23 avril 2016 14:33:56 UTC+2, Aymeric Augustin a écrit : >>> >>> > https://github.com/django/django/pull/6494 >>> >>> This patch looks pretty good. I have a few questions, not necessarily >>> because I disagree with your proposal, but to make sure we have considered >>> alternatives. Actually I don't think there's exactly one correct solution >>> here; it's more a matter of tradeoffs. >>> >>> You added a username_validator attribute instead of documenting how to >>> override the whole username field. Can you elaborate on this decision? I >>> simplifies the use case targeted by the patch by introducing a one-off API. >>> As a matter of principle I'm a bit skeptical of such special cases. But I >>> understand the convenience. >>> >> >> My preoccupation here was not to force users to create a custom user >> model just to change the username validation, especially as the migration >> system doesn't seem to support yet upgrading from the standard auth User to >> a custom user. I thought that creating a proxy custom user is easier >> migration-wise, as no new table is required. But I may be wrong. >> >> >>> Normalization happens at the form layer. I'm wondering whether it would >>> be safer to do it at the model layer. That would extend the security >>> hardening to cases where users aren't created with a form — for example if >>> they're created through an API or programmatically. >>> >> >> Normalization happens both at the form layer and at the model layer in >> _create_user. You may have missed the _create_user change. >> >> >>> I would keep ASCII usernames as the default because: >>> >>> - this has always been the intent; >>> >> >> Until now! Things are evolving, we see that for example with >> internationalized domain names. I think that most if not all technical >> reasons requiring pure ASCII usernames have vanished nowadays. >> >> >>> - allowing non ASCII usernames may result in interoperability problems >>> with other software e.g. if a Django project is used as SSO server; >>> >> >> These are still not the majority of Django use cases. And even then, I >> think that LDAPv3 for example should support unicode in attributes. Those >> project could still configure the ASCIIUsernameValidator if desired. >> >> >>> - these interoperability issues might escalate into security >>> vulnerabilities — there isn't a straightforward connection but (1) non >>> ASCII data can be used for breaking out of parsing routines (2) I'm >>> paranoid with anything that manipulates authentication credentials; >>> >> >> Sure, the more characters, the more attack surface. As you said before, >> it's a tradeoff. My thinking is that sooner or later, we'll have to cope >> with unicode in usernames. So let's do our most to not open security holes, >> based on some passed issues (BTW I think you forgot you references). >> >> >>> - I'm afraid this change may result in boilerplate as most custom user >>> models will revert to Django's historical (and in my opinion sensible) >>> username validation rules. >>> >> >> That's a tough question to estimate. This might be true for most English >> monolingual web sites, but not necessarily for the majority of Django >> sites. Hopefully we'll get some more user inputs in this thread. >> >> >>> Finally, I would add a test to check that a username containing a >>> zero-width space is rejected, just to make sure we never accidentally make >>> it trivial to create usernames that render identically, which this PR aims >>> at preventing. It will be rejected because it won't match \w. >>> >> >> Sure, good idea. >> >> Globally, I totally understand your opinion, and I agree there is no >> "right" or "wrong" solution. Eventually, this might be a decision to be >> brought to the technical broad. >> >> Claude >> > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/6b9282b2-42ee-47dd-8b12-0bd58e647625%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
