#36711: Make createsuperuser in non-interactive mode observe
AUTH_PASSWORD_VALIDATORS
------------------------------+--------------------------------------
Reporter: stan shaw | Owner: stan shaw
Type: New feature | Status: closed
Component: contrib.auth | Version: 5.2
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Changes (by Jacob Walls):
* resolution: => wontfix
* status: assigned => closed
* summary:
createsuperuser in non-interactive mode bypasses
AUTH_PASSWORD_VALIDATORS
=>
Make createsuperuser in non-interactive mode observe
AUTH_PASSWORD_VALIDATORS
* type: Bug => New feature
Comment:
Password validation in `createsuperuser` was discussed at length on the
old mailing list:
https://groups.google.com/g/django-developers/c/9GBhgGXmEKs/m/r_-7uRIuAgAJ
I grant that there's an inconsistency here given that the other variables
are cleaned:
{{{
DJANGO_SUPERUSER_EMAIL=garbage ./manage.py createsuperuser --no-input
--username jane
}}}
{{{
CommandError: Enter a valid email address.
}}}
... but I don't think validating this password takes account of the fact
that `createsuperuser` is a convenience for an administrator who's tasked
with choosing a secure password and can set it themselves in a shell, as
opposed to setting a password policy for users.
This would be a breaking change, see the
[https://github.com/search?q=DJANGO_SUPERUSER_PASSWORD&type=code&p=1
overwhelming usage] of this feature to set dummy passwords for
development.
Requiring dummy development passwords to be strong could even nudge users
into a false sense of security, by encouraging reuse of a password
committed to version control in production because it "looks secure", as
mentioned [https://groups.google.com/g/django-developers/c/9GBhgGXmEKs/m
/r_-7uRIuAgAJ here].
I'll close as wontfix according to our triage process, but feel free to
pursue this further on the Django forum to see what others think.
----
I'd be open to a PR logging a warning (as `Refs #36711 --`), in the spirit
of Carl's advice that led to the interactive prompt to bypass validation
from #28571:
> So it's good to remind them of the validation fail, but there's no
reason to make their life difficult.
--
Ticket URL: <https://code.djangoproject.com/ticket/36711#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019a73db2801-dcf75b8f-d16e-4c9d-8bea-2014a51f72c2-000000%40eu-central-1.amazonses.com.
