-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello everyone,
Sorry for the delay in this one, but I've been very busy last week and had some problems with my email.
As I mentioned last time, I've been comparing some OpenID implementations for Django, and have tried to come up with a short pros/cons list to help with deciding which implementation to use.
==============================================================================
(1) django-openid-auth (
https://launchpad.net/django-openid-auth):
+ Integrates with the default Django auth modules
+ Supports configuring a single central server
+ Receives user information with Simple Registration
+ Supports the teams extension
+ Upstream is pretty active
+ Supports requiring second factor (PAPE)
- - Is officially still Beta
- - A lot of different branches exist, with a branch per fix
- - Bugs in the bug tracker do not seem to be responded to very well
(2) django-openid-auth (
http://code.google.com/p/django-openid-auth/):
- - Has its own completely custom authentication system, so will require rewrite of a lot
- - Is about completely dead (first and last changes in 2007), so not further considered
(3) django-authopenid (
https://bitbucket.org/benoitc/django-authopenid/wiki/Home):
+ Uses the default django authentication system
+ Supports simple registration and attribute exchange
+ Has fixes to work with the latest django release
+ Uses templates
+ Uses python-openid, so is easy to add more OpenID extensions
- - Bug reports seems not responded to very well
- - Does not support binding to a central OpenID provider
- - Officially still beta
(4) django-socialregistration (
https://github.com/flashingpumpkin/django-socialregistration):
+ Supports multiple login services (OpenID, Facebook, Github, Linkedin, ...)
+ Is easily extendable to other services
- - Uses custom integration (not the default authentication system)
- - Does not seem to respond well to pull requests or issues
- - As a result: currently has 149 forks with all different patches applied
(5) django-openid-consumer (
http://code.google.com/p/django-openid-consumer/):
- - Specifically aimed to be used for things like blog comments, and not aiming to provide normal authentication for Django. Not further considered
(6) django-openid (
https://github.com/simonw/django-openid):
- - Last change about 3 years ago
- - Not compatible with Django 1.3+. Not further considered
(7) django-socialauth (
https://github.com/agiliq/Django-Socialauth):
+ Supports multiple login services (OpenID, Facebook, Twitter, ...)
- - Last upstream change about 11 months ago
- - Does not respond well on pull requests and issues
- - As a result: currently has 115 forks with all different patches applied
- - Not easily extendable (service list is hardcoded)
- - Does not support configuring a single central OpenID server
(8) django-social-auth (
https://github.com/omab/django-social-auth):
+ Seems very active upstream community
+ Responds well to issues and pull requests
+ Supports a lot of login services (OpenID, Twitter, Google, Facebook, Github, BrowserID, ...)
+ Easy to add new services
+ Supports configuring a single central OpenID server
+ Uses python-openid for OpenID, so is easily extendable
+ Is well-documented
+ Uses the default Django authentication system
+ Receives user information with Simple Registration
- - Does not support requiring second factor (PAPE)
- - Has a lot of different forks
==============================================================================
I have also tried implementing (1) and (8) into the ReviewBoard codebase.
(1) proved to be quite hard to implement at the end because the documentation is not really clear on some points.
(8) was quite easy to implement, and worked very well and would have my personal preference over the alternatives.
This was also the one that Christian suggested, so that seems the best way to go.
I am planning to fix my implementation for django-social-auth over the course of this week, as my current implementation is a Quick&Dirty one, and will submit this for review.
That is, unless there's someone with another implementation I should check out, or with additional points which I seem to have missed?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBCgAGBQJRttxpAAoJEIZXmA2atR5QiaQP/2pf4Qp7bt8/uakiqUvk7gjL
1SlAWg1LPOJTXUdFWbCJw2KEvIHaZSARuVvMAC2x3H8sTaaLorFt22rISdvKZaRT
sBEb3KQBS4W83eZjM76N+0D9T4wAl5bIywsux0OevM0s7J6ebV7EYzwOIodx4aJa
+dkxZsjb82aLdOOP3v0XxBL6bJmcVuvXDAPQPWu5Cm/dq0L4m7mh/fjVkMZCQxIM
Teflr8uLmJj8IBWdsuTKrSU8H6inTv4xGUC4hYb6hqUoShNJl76+EwlWXLx3YzyE
3DHudzh0gY7a3/weZGLc2HrwcWA13DNyk+ynQVZ69qEWl93yKAFQNHIlmwu8SVKJ
8+sziSrWaD1PUxVwiWit5CZxlVhyo2DReSpMkDq6kl/D0Pe3oKpxgIrKVJGzx+2M
aNejYwXmLYK9W54+ccVOOnUtMWqGkT4Cgmiq1JdS0xYis76NeMQi6aUgy/14vBif
lN0t8i9T0RCzL03QrEToEqhiTYHsnMiOq14a/ZySOKu1r/541fubhi/eYbft+Ioi
n4hh0cHQ67zOk3jJhb83+DiyQHNjL2oS8jZyMKkb8C0vaukv8IHQehqKNFjvtRiP
Nc/CRuod0vdAXDNQ8OALL5GwHuzO09GGTxUb5kAihSm/a9RBgiiTHyMF7UlqH+5P
pm/9pwK1LW0a75R/lWd/
=4Olf
-----END PGP SIGNATURE-----