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/3c750af9-68f4-4e6c-88be-ead3fe0d3358%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
