On Wed, Apr 20, 2016 at 03:02:06PM +0200, Erik Cederstrand wrote: > Do you want passwords to be case-insensitive? If so, you can > subclass AuthenticationForm and override clean_password(), and > set_password() on your user model, and put any transformations of > the raw password there.
A more robust way to implement this would be to write a custom password hasher, as described in the docs: https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#writing-your-own-hasher That way, you wouldn't risk missing any code paths where you'd forget to make the password transformation manually, and it would allow you to use the built-in views and forms instead of having to roll your own. That being said, making passwords case-insensitive sounds like a bad idea, and you should only ever do that if you know really well what you are doing. > If you want to enforce certain password rules (length, must contain > numbers and special chars, etc) then override > AuthenticationForm.clean_password() and raise ValidationError() for > your rules. Again, Django already provides a more robust mechanism for that, which has been introduced in version 1.9: https://docs.djangoproject.com/en/1.9/topics/auth/passwords/#module-django.contrib.auth.password_validation Cheers, Michal -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20160420132016.GE1129%40koniiiik.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
