Produits Entr'ouvert » Authentic 2

• https://django.readthedocs.org/en/latest/releases/1.6.html
• https://django.readthedocs.org/en/latest/releases/1.7.html

Maybe faster to review the deprecation timeline: https://django.readthedocs.org/en/latest/internals/deprecation.html#deprecation-removed-in-1-6

• BooleanField does not have default=False by default https://django.readthedocs.org/en/latest/releases/1.6.html#booleanfield-no-longer-defaults-to-false
• URL quoting in reverse() https://django.readthedocs.org/en/latest/releases/1.6.html#quoting-in-reverse
• execute_manager() has been removed:

  tests/integration/saml2/idp_manage.py:    execute_manager(settings)
  tests/integration/saml2/sp_manage.py:    execute_manager(settings)

• HttpRequest.raw_post_data was renamed .body

  authentic2/saml/common.py:61:    return request.raw_post_data

• HttReponse.__init__ argument mimetype was renamed content_type

  authentic2/idp/idp_openid/views.py:216:    }, context_instance=RequestContext(request), mimetype=YADIS_CONTENT_TYPE)
  authentic2/idp/saml/saml2_endpoints.py:105:            mimetype='text/xml')
  authentic2/saml/common.py:177:        return HttpResponse(profile.msgBody, mimetype = 'text/xml')
  authentic2/saml/common.py:216:    return HttpResponse(profile.msgBody, mimetype = 'text/xml')
  authentic2/saml/common.py:636:    return HttpResponse(content, mimetype = "text/xml")
  

Transaction management should be reviewed too.

I wanted to evaluate this, so I created a branch of this on Github:
https://github.com/grigi/authentic2

Fisrtly I wanted to get a full test suite running for both Django 1.5 and 1.6, to ensure that these patches don't obviously break something.
Due to the invasive nature of authentic2, I ensured that all tests for Django, 3'rd party apps and authentic2 ran.

Commit: Added tox to run tests for both Djang1.5 and Django1.6
1.5: 3 failures, 12 errors
1.6: 103 errors

0001 & 0002 failed to apply.

Commit: applied 0003-django-1.6-middleware-do-not-store-set-object-in-ses.patch
1.5: 3 failures
1.6: 21 failures, 6 errors

0004 & 0005 failed to apply

Commit: applied 0006-django-1.6-LDAPUser-application-cannot-be-deduced-wi.patch
No change in test results

Experiment
Of the 3 failures in 1.5, 2 are to do with authentic2.backends.ModelBackend, 1 with django-registration
So I Temporarily Changed AUTHENTICATION_BACKENDS to use django.contrib.auth.backends.ModelBackend instead
1.5: 1 failure
1.6: 1 failure, 2 errors
This means there is something not right in authentic2.backends.ModelBackend, is this needed?

You should maybe consider getting rid of django-registration as a dependency, as it doesn't work with Django>1.5.
There is a ticket on the bitbucket page to add support for 1.6, but the maintainer essentially quit maintaining it, and nobody else took ownership.

I made a mistake with my test runner for Django>=1.6 where django-registration test filenames don't conform to the new pattern match, so you have to do a -p init.py for registration ONLY.

There is a package called django-registration2, but it seems to have been forked from django-registration very long ago, and is missing much of the new features :-(

The general consensus on the net is to migrate over to django-allauth, but I haven't evaluated if it uses all the features you use.

Commit: applied 0001-django-1.6-fix-import-path-of-FieldDoesNotExist-exce.patch
1.5: 2 failures
1.6: 21 failures, 6 errors

I cannot apply 0002 manually. It looks like the code got overhauled since.

I cannot apply 0004 cleanly, and the existing is still valid through to Django 1.7. Whereas it will break 1.5 compatibility. So I'm proposing skipping it.

Commit: manually applied 0005-django-1.6-authentication-backends-import-path-must-.patch
1.5: 2 failures
1.6: 4 failures, 2 errors

I applied all the patches here that I could, and it definitely helped 1.6 compatibility and actually helped 1.5 as well.

Could you add a "License: MIT" line to your patchs ? We only accept contributions with a BSD-like license (I should add the policy to the README file).

Just to be clear the License line must be added to the end of your commit message (last line of it_.

Hi

Is there any particular reason that this issue is being held up?

Sorry I lack time to review it currently, I'll try to do it soon.

Thanks for the update :-)

I applied your patches and mine on this branch : http://repos.entrouvert.org/authentic.git/log/?h=wip/5244-django-17-compatibility could you verify it works on your side and the I will merge it. The remaining failure I see with tests from django.contrib.* applications are all related to to assumptions from Django which are wrong, for example that only if CUSTOM_USER_MODEL is set, authentication backend returns non-User models. Authentic2 LDAP backend does that, it returns a proxy-model to the classic User model, which is not an error.

I made a new serie of patches to fully support Django 1.7, would you test them ?

http://repos.entrouvert.org/authentic.git/log/?h=wip/django-1.7-migrations

I will not merge the Django 1.7 migrations until we decide that Django 1.7 is mandatory, as the move for every deployment will be one way and we cannot manage two lines of development. Until this time Django 1.7 support will be experimental.

As for the customizable choices varying at each makemigrations it's a known limitations of the new migration system¹; the only fix will be to move all variable choices in forms and not on models; default choices on models will be empty.

[1]: https://code.djangoproject.com/ticket/22837 and https://code.djangoproject.com/ticket/23581

Ah, ok. that explains that.

Yes, the upgrade to Django 1.7 can be quite disruptive, which is why I originally only tried to get 1.6 to work.

I really only needed Django 1.6 support, because Django 1.5 is now formally not maintained any more, and won't get more security updates, but 1.6 will still for about half a year.

If you can maybe apply some of the fixes from that branch that is not in master yet? The django-registration-redux which we need for Django 1.6 would allow us to do the upgrade a little more incrementally?

e.g. Commits:
#5d006795 #39c63d79 #62c9cab8 #86bd809b #14f969e4
look safe for me to apply?

And some documentation that you may need to "pip uninstall django-registration" on upgrade?