Opened 4 years ago

Closed 3 months ago

Last modified 7 weeks ago

#16860 closed New feature (fixed)

Provide hooks for password policy

Reported by: PaulM Owned by: erikr
Component: contrib.auth Version: master
Severity: Normal Keywords:
Cc: cmawebsite@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by shaib)

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

Change History (12)

comment:1 Changed 4 years ago by PaulM

  • Description modified (diff)

comment:2 Changed 13 months ago by collinanderson

  • Cc cmawebsite@… added

comment:3 Changed 13 months ago by shaib

  • Description modified (diff)

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).

comment:4 Changed 6 months ago by erikr

  • Owner changed from nobody to erikr
  • Status changed from new to assigned
  • Version changed from 1.3 to master

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

comment:5 Changed 5 months ago by erikr

  • Has patch set

comment:6 Changed 5 months ago by timgraham

  • Patch needs improvement set

comment:7 Changed 3 months ago by erikr

  • Patch needs improvement unset

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.

comment:8 Changed 3 months ago by Erik Romijn <eromijn@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 1daae25:

Fixed #16860 -- Added password validation to django.contrib.auth.

comment:9 Changed 3 months ago by Tim Graham <timograham@…>

In 55b3bd8:

Refs #16860 -- Minor edits and fixes to password validation.

comment:10 Changed 3 months ago by Tim Graham <timograham@…>

In 09f2cdb:

Refs #16860 -- Fixed a resource and deprecation warning in password validation.

comment:11 Changed 7 weeks ago by Tim Graham <timograham@…>

In f5e9d67:

Refs #16860 -- Moved password_changed() logic to AbstractBaseUser.

Thanks Carl Meyer for review.

comment:12 Changed 7 weeks ago by Tim Graham <timograham@…>

In 774c16d1:

Fixed #25052; refs #16860 -- Added password validation to UserCreationForm.

Note: See TracTickets for help on using tickets.
Back to Top