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 [email protected]. To post to this group, send email to [email protected]. 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
