Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test run fails #52

Open
GoogleCodeExporter opened this issue May 3, 2015 · 4 comments
Open

Test run fails #52

GoogleCodeExporter opened this issue May 3, 2015 · 4 comments

Comments

@GoogleCodeExporter
Copy link

======================================================================
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 [email protected] on 16 Jun 2014 at 12:21

@GoogleCodeExporter
Copy link
Author

Can you tell me what python, passlib, and django versions you're using?

Original comment by [email protected] on 16 Jun 2014 at 7:50

  • Changed state: Discussing

@GoogleCodeExporter
Copy link
Author


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 [email protected] on 17 Jun 2014 at 4:05

@GoogleCodeExporter
Copy link
Author

This issue was closed by revision f0b9d8385d96.

Original comment by [email protected] on 25 Jan 2015 at 6:10

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 25 Jan 2015 at 6:17

  • Added labels: Milestone-Release1.6.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant