We could override `AbstractBaseUser.clean_fields` to call an empty
`AbstractBaseUser.clean_password` (given the password field is not excluded
from validation) and gracefully handle the possible `ValidationError`:
class AbstractBaseUser(models.Model):
....
def clean_password(self):
pass
def clean_fields(self, exclude=None):
super(AbstractBaseUser, self).clean_fields(exclude=exclude)
if exclude is None or 'password' not in exclude:
try:
self.clean_password()
except ValidationError as e:
raise ValidationError({'password': e.error_list})
I guess we should just implement the `clean_<field_name>` paradigm at the
model level at this point.
Le jeudi 7 août 2014 18:23:52 UTC-4, Tim Graham a écrit :
>
> The custom user idea did seem like a good one to me. I don't think you'd
> have to rewrite much (anything?) if the only change in your custom user is
> to add a validate_password() function. If you'd like code up a proof of
> concept we can take a look. I don't think front-end integration is
> necessary at this point. The "questions" I was referring to are the
> "Problems to be solved" on the ticket. Many of them seem out of scope for
> getting a v1 working, but are things to consider as you do the
> implementation.
>
> On Thursday, August 7, 2014 5:51:30 PM UTC-4, Keith Hackbarth wrote:
>>
>> I actually think Colin's approach seems the best. Have a
>> validate_password function that can be overridden by a custom user model.
>>
>> Tim, if I wanted to move this forward, what would be the next steps? I
>> looked at the trac ticket you mentioned and it looks much more in-depth
>> (full javascript / front-end integrtion). I also didn't see any questions
>> on the ticket. Should I respond to that ticket or create one of my own?
>>
>>
>> On Tuesday, August 5, 2014 10:09:02 AM UTC-7, Keith Hackbarth wrote:
>>>
>>> First of all, apologies in advance if this is not the right place for
>>> this or if this topic has already been brought up. Long time listener,
>>> first time caller.
>>>
>>> I would like to propose having some sort of password validation layer
>>> that can be activated every time a user's password is created or changed.
>>>
>>>
>>> Here's the core of my problem:
>>>
>>> I've worked on a few different Django-based applications. Where
>>> possible, we've tried to leverage the contrib.auth module when it comes to
>>> user management. Eventually, we will fall under some sort of compliance
>>> (SOX, PCI, HIPAA, etc.) and need to enact the security best practices.
>>> These *always* include enforcing password length, complexity, etc..
>>>
>>> My problem is there ends up being a bunch of places were the password
>>> can be changed: our website via emailed password reset, our website via
>>> password change form, the admin console, our REST api for mobile, etc.. I
>>> end up needing to create a bunch of custom overrides forms and functions.
>>> And make sure our other team members know to do the same.
>>>
>>> I've come up with a few solutions that I'd love to share them with the
>>> community. However, the level that they are implemented at make them
>>> difficult to just include in Django as a separate third-party module /
>>> application.
>>>
>>> Anyway, looking through various forums, I see that I'm not the first
>>> person to have this problem. I was wondering what people thought about
>>> having a configurable password validation function that gets called within
>>> auth every time a password is changed?
>>>
>>> In settings.py it could look like this:
>>>
>>> AUTH_PASSWORD_VALIDATION = 'account_mgnt.validators.password'
>>>
>>> by default it would be
>>>
>>> AUTH_PASSWORD_VALIDATION = None
>>>
>>>
>>>
>>>
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Django developers" 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/6856bb71-b37a-4fa4-85f1-8df396131447%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
