[Django] #16860: Provide hooks for password policy
Django
-----------------------------+----------------------------------------
Reporter: PaulM | Owner: nobody
Type: New feature | Status: new
Milestone: | Component: contrib.auth
Version: 1.3 | Severity: Normal
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+----------------------------------------
While it is possible to change the validation for new passwords by
subclassing the form, I think that Django should provide a more friendly
interface for this. We should have a pluggable password authentication
framework which enforces no rules by default, but comes with several
reasonable example policies which may be enabled.
Problems to be solved include:
* Informing the user of the various password requirements
* Allowing policies to chain together smoothly
* Provide flexibility for complex requirements (some may include their
own models)
* Backwards compatibility
* Javascript validation assistance (someday, maybe?)
* HTML5 support (i.e. the pattern attribute)
--
Ticket URL: <https://code.djangoproject.com/ticket/16860>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Type: New feature | Status: new
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by PaulM:
Old description:
> While it is possible to change the validation for new passwords by
> subclassing the form, I think that Django should provide a more friendly
> interface for this. We should have a pluggable password authentication
> framework which enforces no rules by default, but comes with several
> reasonable example policies which may be enabled.
>
> Problems to be solved include:
>
> * Informing the user of the various password requirements
> * Allowing policies to chain together smoothly
> * Provide flexibility for complex requirements (some may include their
> own models)
> * Backwards compatibility
> * Javascript validation assistance (someday, maybe?)
> * HTML5 support (i.e. the pattern attribute)
While it is possible to change the validation for new passwords by
subclassing the form, I think that Django should provide a more friendly
interface for this. We should have a pluggable password authentication
framework which enforces no rules by default, but comes with several
reasonable example policies which may be enabled.
Problems to be solved include:
* Informing the user of the various password requirements
* Allowing policies to chain together smoothly
* Provide flexibility for complex requirements (some may include their
own models)
* Backwards compatibility
* Javascript validation assistance (someday, maybe?)
* HTML5 support (i.e. the pattern attribute)
* support for adding captchas (maybe)
--
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:1>
Django
Reporter: PaulM | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by collinanderson):
* cc: cmawebsite@… (added)
Comment:
mailing list discussion: https://groups.google.com/d/topic/django-
developers/kec0UF_xc3k/discussion
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:2>
Django
Reporter: PaulM | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Old description:
> While it is possible to change the validation for new passwords by
> subclassing the form, I think that Django should provide a more friendly
> interface for this. We should have a pluggable password authentication
> framework which enforces no rules by default, but comes with several
> reasonable example policies which may be enabled.
>
> Problems to be solved include:
>
> * Informing the user of the various password requirements
> * Allowing policies to chain together smoothly
> * Provide flexibility for complex requirements (some may include their
> own models)
> * Backwards compatibility
> * Javascript validation assistance (someday, maybe?)
> * HTML5 support (i.e. the pattern attribute)
> * Support for various rate-limiting and lockout schemes
> * support for adding captchas (maybe)
New description:
While it is possible to change the validation for new passwords by
subclassing the form, I think that Django should provide a more friendly
interface for this. We should have a pluggable password authentication
framework which enforces no rules by default, but comes with several
reasonable example policies which may be enabled.
Problems to be solved include:
* Informing the user of the various password requirements
* Allowing policies to chain together smoothly
* Provide flexibility for complex requirements (some may include their
own models)
* Backwards compatibility
* Javascript validation assistance (someday, maybe?)
* HTML5 support (i.e. the pattern attribute)
* Prevent using email, username or other user attributes as (part of)
passwords
* Prevent reuse of old passwords
--
Comment (by shaib):
I replaced two requirements that seem to be applicable to login pages
(rate-limiting & lockout, captcha) with ones more applicable to password
setting (use of user attributes, old password reuse).
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:3>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: assigned
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* owner: nobody => erikr
* status: new => assigned
* version: 1.3 => master
Comment:
I've submitted a PR with a demo of a fresh approach on
https://github.com/django/django/pull/4276
The PR is not meant to be mergable.
New mailing list discussion on: https://groups.google.com/forum/#!topic
/django-developers/9GBhgGXmEKs
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:4>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: assigned
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:5>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: assigned
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:6>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: assigned
Component: contrib.auth | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* needs_better_patch: 1 => 0
Comment:
I've updated the PR for the many (good) comments and I believe it's now
ready for merge, after a rebase. Could someone do a final review?
I've spoken to Aymeric about integrating this with the User model instead
of adding a setting, but we concluded that this design is not a
substantial improvement and does introduce a more complex coupling that is
currently not needed. Therefore, we stuck to the basic idea of using a
setting for configuration.
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:7>
Django
Reporter: PaulM | Owner: erikr
Component: contrib.auth | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Erik Romijn <eromijn@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"1daae25bdcd735151de394a5578c22257e3e5dc7" 1daae25]:
{{{
#!CommitTicketReference repository=""
revision="1daae25bdcd735151de394a5578c22257e3e5dc7"
Fixed #16860 -- Added password validation to django.contrib.auth.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:8>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: fixed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"55b3bd84681a87266f6bef72480aaef48a7c295f" 55b3bd8]:
{{{
#!CommitTicketReference repository=""
revision="55b3bd84681a87266f6bef72480aaef48a7c295f"
Refs #16860 -- Minor edits and fixes to password validation.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:9>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: fixed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"09f2cdbe1a43e79e31f5ea509b59d4c87db29832" 09f2cdb]:
{{{
#!CommitTicketReference repository=""
revision="09f2cdbe1a43e79e31f5ea509b59d4c87db29832"
Refs #16860 -- Fixed a resource and deprecation warning in password
validation.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:10>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: fixed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"f5e9d67907510881c7f132d0a80e39f47caea5f6" f5e9d67]:
{{{
#!CommitTicketReference repository=""
revision="f5e9d67907510881c7f132d0a80e39f47caea5f6"
Refs #16860 -- Moved password_changed() logic to AbstractBaseUser.
Thanks Carl Meyer for review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:11>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: fixed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"774c16d16ed67d7cf12bc2b2752768b544bdb363" 774c16d1]:
{{{
#!CommitTicketReference repository=""
revision="774c16d16ed67d7cf12bc2b2752768b544bdb363"
Fixed #25052; refs #16860 -- Added password validation to
UserCreationForm.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:12>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: fixed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"53ccffdb8c8e47a4d4304df453d8c79a9be295ab" 53ccffd]:
{{{
#!CommitTicketReference repository=""
revision="53ccffdb8c8e47a4d4304df453d8c79a9be295ab"
Refs #16860 -- Fixed password help text when there aren't any validators.
This avoids creating an empty list which is invalid HTML 4.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:13>
Django
Reporter: PaulM | Owner: erikr
Type: New feature | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: fixed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"db88e40312dfba8d32203a0990792a4a9840f6a7" db88e40]:
{{{
#!CommitTicketReference repository=""
revision="db88e40312dfba8d32203a0990792a4a9840f6a7"
[1.9.x] Refs #16860 -- Fixed password help text when there aren't any
validators.
This avoids creating an empty list which is invalid HTML 4.
Backport of 53ccffdb8c8e47a4d4304df453d8c79a9be295ab from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/16860#comment:14>