-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed #16860 -- Added password validation to django.contrib.auth #4276
Conversation
@@ -534,6 +534,8 @@ | |||
'django.contrib.auth.hashers.CryptPasswordHasher', | |||
] | |||
|
|||
PASSWORD_VALIDATORS = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is part of a contrib application I think this should be named AUTH_PASSWORD_VALIDATORS
.
Didn't actually mean to assign this to Karen, must have misclicked somewhere :) |
I don't know entirely what's going on, but those build failures do not appear to be related to the patch:
Most platforms do seem to succeed. |
That's one of Jenkins occasional hiccups. No need to worry. |
from django.utils.translation import ugettext as _ | ||
|
||
|
||
def get_password_validators(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be cached? The number of times validators are instantiated, and the associated cost with loading in the 1000 most common passwords each time strongly suggests that it should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, actually, definitely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm theoretically reluctant to this being a global module rather than something tied to the User model.
In practice AUTH_USER_MODEL is already a global singleton so this doesn't change the picture.
(Sorry if I brought this up before.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jarshwah Agreed. The cache must be cleared by a setting_changed
receiver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to second @aaugustin's point about this conceptually fitting very well into the custom user models. This does not require yet another setting, so let's not.
On the bigger picture I really would like to prevent settings.py to continue to turn into a file full of dictionaries with dotted Python paths and initialization parameters. Let's use the extension API we've built into the auth app for such a case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get your point, but I'm not entirely seeing what you are proposing. Could you make a short example? As this is a more fundamental design discussion, perhaps this would fit best on the django-developers list.
(I'll defer working/responding on other comments until we've settled this issue, as we need to get this right to have a mergeable patch.)
|
||
Included validators | ||
------------------- | ||
Django includes three validators: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need a .. module::
directive hear, otherwise you inherit the last one which is django.contrib.auth.hashers
.
As @aaugustin mentioned elsewhere, compression the common passwords list sounds like a good idea in combination with customizing its location. How hard would it be to add some autodetection if the file needs to be unzipped or is already a plain-text file? Plain text files are easier to maintain for project specific lists, I think. |
'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator', | ||
}, | ||
{ | ||
'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is NAME in capitals?
For comparison, DATABASES and CACHES use lower-case 'default' and then capitals, LOGGING uses lower-case only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ough, is a new setting really required for this? |
@jezdez, @aaugustin: as both of you have proposed to tie this to the User model, could you write up a short example? I may have some concerns about that design, but I'd rather form an opinion on an example rather than my imagination of what I think your idea might be. Perhaps I'm entirely mistaken. As this is a more fundamental design discussion, perhaps this would fit best on the django-developers list rather than this PR. |
|
||
def get_password_validators(validator_config=None): | ||
validators = [] | ||
if validator_config is None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're going to provide get_default_password_validators
, why not move this into that function and make get_password_validators
entirely settings-independent, with the config arg required?
This is great! Very excited to have this in Django 1.9; I think I'm about to backport it into a 1.8 project I'm working on currently :-) Thanks for working on it! |
Of the comments I just left, the only one I would consider a merge blocker is the vague error message issue. |
Is there a reason why password validation is not performed on UserCreationForm? |
This was merged in 1daae25. |
https://code.djangoproject.com/ticket/16860
Mailing list discussion on: https://groups.google.com/forum/#!topic/django-developers/9GBhgGXmEKs