Validation errors are only caught inside form validation. Forms set the password usually in save, not in clean, so I don't think that patch covers it (or at least the relevant forms have to call validate_password in clean too)
On Monday, August 18, 2014 5:31:05 PM UTC+2, Keith Hackbarth wrote: > > Tim, et al., > > I've coded up a proof of concept here. I'd be very interested in your > feedback. > > https://github.com/keithhackbarth/django/commit/c0897dd4b3d49e39246d1e74d636e32862881451 > > Thank you, > > Keith > > On Thursday, August 7, 2014 7:04:40 PM UTC-6, charettes wrote: >> >> 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/741bdb32-bcbb-4942-8f77-0d00ebfffafb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
