Hey Aymeric, I think I'd prefer "downgrade the message to a warning and proceed" for DEBUG=True and list all validation errors, much like for forms. Sticking to the current implementation for DEBUG=False is fine with me. For example:
$ python manage.py createsuperuser Username (leave blank to use 'markus'): Email address: ******** Password: Password (again): The passwords do not match. Password: Password (again): You used a password that doesn't fulfill all validation requirements: - This password is too short. It must contain at least 8 characters. - The password is too similar to the email address. Superuser successfully created Cheers, /Markus On Saturday, September 5, 2015 at 5:14:16 PM UTC+10, Aymeric Augustin wrote: > > Hello, > > Indeed, this will be annoying for development. > > I don’t find the “admins don’t need rules, they know what they’re doing” > argument compelling. The cobbler children’s go barefoot… Besides, if admins > know the rules, having validation enabled won’t hurt :-) > > I’m in favor of implementing an escape hatch when DEBUG = True: > > - either downgrade the message to a warning and proceed > - or ask the user if they want to proceed with the invalid password > (--no-input would skip this step and proceed silently) > > -- > Aymeric. > > > > On 5 sept. 2015, at 01:56, Markus Holtermann <in...@markusholtermann.eu > <javascript:>> wrote: > > Hey, > > while I like the idea of having the validation in all places to not forget > one that might be user facing, I was surprised by the fact that the > validation also happens in dev environments when you create the superuser > (this whole mail applies to the changepassword command, too): > > $ python manage.py createsuperuser > Username (leave blank to use 'markus'): > Email address: ******** > Password: > Password (again): > This password is too short. It must contain at least 8 characters. > Password: > Password (again): > The password is too similar to the email address. > Password: > > > This is a bit annoying for me, given that I normally use "markus" or > "admin" as username and password for the superuser and u1:u1, as > username:password combination for additional users. > > There are a few solutions to that behavior I'd like to see revisited for > 1.9: > > 1. Disable password validation when DEBUG=True -- I don't think we > really want that > 2. Don't have password validation for createsuperuser/changepassword: > I personally don't see the benefit for that in the command anyways. > 1. In production environments I would expect the admins having > access to the management command to know their regulations (after all, > they > need to configure them) and to know what good passwords are. > 2. As somebody who is able to run the "createsuperuser" command I > figure I can also run "shell", giving me unlimited access to the > password > field of users, allowing me to set a password that doesn't match the > requirements. > 3. It breaks backwards compatibility with tools like Expect ( > https://en.wikipedia.org/wiki/Expect -- yes, I had to use that in > the past) > 3. Disable validation when passing --no-validate or > --no-validate-password to createsuperuser, though this is still backwards > incompatible and a lot to type -- I'd better of with having a valid > password -- or the other way around, passing --validate / > --validate-password, but this feels pointless > > My preference is definitely (2), though I'm sorry for not bringing this up > earlier when the issue was created. > > The original issue: https://code.djangoproject.com/ticket/25089 > Respective PR: https://github.com/django/django/pull/5073 > > Cheers, > > /Markus > > On Thursday, July 9, 2015 at 6:13:18 PM UTC+10, Alex Becker wrote: >> >> Hi Erik, >> >> I've written such a patch, which also fixes an html escape bug and adds >> validation to the auth management commands. >> The pull request is here <https://github.com/django/django/pull/4969>. >> >> Sincerely, >> >> Alex >> >> On Friday, June 26, 2015 at 3:19:30 AM UTC-5, Erik Romijn wrote: >>> >>> Hi Alex, Carl, >>> >>> On 22 Jun 2015, at 02:43, Carl Meyer <ca...@oddbird.net> wrote: >>> > On 06/21/2015 06:17 PM, Alex Becker wrote: >>> >> With the PR merged, password validation applies to the SetPasswordForm >>> >>> >> and the password changing forms, but not to the UserCreationForm or to >>> >>> >> the creation of superusers. Is there a reason not to apply validation >>> to >>> >> these as well? >>> > >>> > Certainly makes sense to me to add validation to both of these. I >>> missed >>> > it in review. Erik, is there a reason you didn't, or was it just an >>> > oversight? >>> >>> No reason at all. I hadn’t even realised there was such a form. It seems >>> >>> sensible to add it (along with a test), but I don’t have time to make the >>> >>> patch currently. >>> >>> Erik >> >> > > > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/470bba48-2695-405e-bdf4-88b66373a323%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
