On Tue, Feb 2, 2016 at 10:35 AM, charettes <charett...@gmail.com> wrote: >> That hasher, being the fastest non-plaintext hasher around, is quite >> useful >> when running tests: it allows login checks to be performed much faster. > > This argument came up a couple of time in the past and from what I remember > the Django test suite itself spends a significant amount of time hashing > passwords. > > I understand that we want to avoid shipping a plaintext password hasher in > `django.contrib.auth.hashers` for the sake of not exposing a footgun-API but > what if we shipped one in the `django.contrib.auth.test` package instead? > > We could document its use for testing purposes only and would make the > complete deprecation of unsafe hashers easier.
For testing, Django provides force_login(). This method skips password hashing and logs a user in for a test. For tests that want a logged in user and do not care about how the password was verified, this seems like a good choice. Assuming this was used throughout, would this be sufficient for handling this performance concern? Tests that verify the password hasher will need to run the hash algorithm regardless. https://docs.djangoproject.com/en/1.9/topics/testing/tools/#django.test.Client.force_login -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b5%3DnqrD2GOTTg4hjT4KxRUFGGT0tZZHCYypdggH-0ePqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
