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 <i...@markusholtermann.eu> 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: > Disable password validation when DEBUG=True -- I don't think we really want > that > Don't have password validation for createsuperuser/changepassword: I > personally don't see the benefit for that in the command anyways. > 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. > 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. > It breaks backwards compatibility with tools like Expect > (https://en.wikipedia.org/wiki/Expect <https://en.wikipedia.org/wiki/Expect> > -- yes, I had to use that in the past) > 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 > <https://code.djangoproject.com/ticket/25089> > Respective PR: https://github.com/django/django/pull/5073 > <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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at http://groups.google.com/group/django-developers > <http://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/9860adf7-b0b3-492d-b8a0-f08c7b85b587%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/9860adf7-b0b3-492d-b8a0-f08c7b85b587%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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 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/EB58FCEF-3B45-4DD5-A802-AB566919E229%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
