glic3rinu / passlib

Automatically exported from code.google.com/p/passlib
Other
15 stars 3 forks source link

Test run fails #52

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
======================================================================
ERROR: test_unsalted_md5 (passlib.tests.test_ext_django.HashersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/django/contrib/auth/tests/hashers.py", line 88, in test_unsalted_md5
    encoded = make_password('letmein', 'seasalt', 'unsalted_md5')
  File "/daten/src/git/pip/passlib/passlib/ext/django/models.py", line 195, in make_password
    return password_context.encrypt(password, **kwds)
  File "/daten/src/git/pip/passlib/passlib/context.py", line 2506, in encrypt
    return self._get_record(scheme, category).encrypt(secret, **kwds)
  File "/daten/src/git/pip/passlib/passlib/utils/handlers.py", line 552, in encrypt
    self = cls(use_defaults=True, **kwds)
  File "/daten/src/git/pip/passlib/passlib/utils/handlers.py", line 402, in __init__
    super(GenericHandler, self).__init__(**kwds)
TypeError: object.__init__() takes no parameters
-------------------- >> begin captured logging << --------------------
passlib.ext.django.models: DEBUG: preparing to monkeypatch 
'django.contrib.auth' ...
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.models:User.set_password'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.models:User.check_password'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.models:check_password'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.hashers:check_password'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.models:make_password'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.hashers:make_password'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.forms:get_hasher'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.hashers:get_hasher'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.forms:identify_hasher'
passlib.ext.django.models._manager: DEBUG: patching resource: 
'django.contrib.auth.hashers:identify_hasher'
passlib.ext.django.models: DEBUG: ... finished monkeypatching django
passlib.ext.django.models: DEBUG: passlib.ext.django loaded
--------------------- >> end captured logging << ---------------------

Original issue reported on code.google.com by smur...@gmail.com on 16 Jun 2014 at 12:21

GoogleCodeExporter commented 9 years ago
Can you tell me what python, passlib, and django versions you're using?

Original comment by elic@astllc.org on 16 Jun 2014 at 7:50

GoogleCodeExporter commented 9 years ago

Python is 2.7.7. Django version is 1.4.5 but that's not interesting as all it 
does is call make_password() and everything else happens within passlib. 
passlib is 1.6.2; the current git tip has a few more failures which I hven't 
looked into yet.

The culprit, by the way, is the "salt" parameter, which is not consumed by any 
of the functions in the call stack.

IIRC Python recently started to throw a TypeError if you pass any parameters to 
object.__init__(), instead of silently ignoring them.

Original comment by smur...@gmail.com on 17 Jun 2014 at 4:05

GoogleCodeExporter commented 9 years ago
This issue was closed by revision f0b9d8385d96.

Original comment by elic@astllc.org on 25 Jan 2015 at 6:10

GoogleCodeExporter commented 9 years ago
Actually, I'm relying on the object.__init__() behavior (added in py26) to 
catch things like this. And as it turns The Django version is particularly 
interesting (and relevant)... 

I finally tracked this down: the hasher unittests for Django 1.4.0 - 1.4.5 had 
a few weird cases where they would pass a salt into an unsalted hash algorithm, 
which passlib's make_password() adapter wasn't expecting at all.  They fixed 
the tests in 1.4.6, and it's not a case that happens in production, which 
explains why I had trouble reproducing this under any python / django combo -- 
I was only testing the latest 1.4.x release (1.4.18). 

I've changed things a little so it should be passing under 1.4.5 successfully 
now, but let me know if you still test failures!

I've marking this fix the 1.6.3 milestone, but I'm currently trying to wrangle 
a bunch of things together to get 1.7 out the door by the end of 2015 Q1, so it 
might get rolled into that instead. 

- Eli

Original comment by elic@astllc.org on 25 Jan 2015 at 6:17