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 <[email protected]> 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 [email protected].
To post to this group, send email to [email protected].
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/9860adf7-b0b3-492d-b8a0-f08c7b85b587%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
