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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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.
