OpenID progress

30 views
Skip to first unread message

Patrick Uiterwijk

unread,
May 20, 2013, 8:43:54 AM5/20/13
to reviewb...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everyone,

As mailed earlier, I'm working on ReviewBoard as an intern for Red Hat, Inc. [1]
As such, my manager has requested me to send a weekly email to the list with my progress of the last week.
Do not hestitate to ask any questions or provide any comments.

What I have done last week:
- - Discuss with Christian about how to implement the API Tokens, as we will need those regardless
- - Added a flag to WebAPIResource so that middleware can check whether or not a request is a webapi request [2]
- - Added API token into the user interface, including a way to reset it (code will be submitted shortly)
- - Looked into how authentication for the web API and web interface is performed
- - Work up a draft of how to get API tokens into the authentication system

What I plan to do coming week:
- - Get the API token in the authentication system
- - Compare several OpenID authentication modules for Django, and try to implement one.

With kind regards,
Patrick Uiterwijk



[1]: https://groups.google.com/forum/?fromgroups#!topic/reviewboard-dev/e9Mx27rZUtg
[2]: http://reviews.reviewboard.org/r/4135/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBCgAGBQJRmhqKAAoJEIZXmA2atR5QMb0P/18yTUMGnboouX1T5vBDLZDL
STkqXq6NuGqsEp/MmQg+zPC5/80Of6ATCOtCLyTfG1dYhMXfwuuu+ahq3hboSowj
FbInnzkPPunx/ut0Kgv81NHi5YE5O84AajZiMx3Gcc17UXsIA+3E66AgzaYjt23I
QZpp1SjKE5lINw4HVStMnAYqwGYiShvbMaavmkDyJt0tzh/b3+r8KerGi1Y5djqI
DHyQURhRkv5TyjJk54PnRSGLMhaNHF5d+7PZ7JsLHGQFq2kD0F82xFUwpa+Ge8HH
afKU2I5WktErCd4B3ckOEw9FZSxFhT8qDZJzSYrBId2T1E0MoltQF3+I+4rvV4Nj
4qc4e1EcmbDMLLHLpDuD+ZPnZpguTNuydGWTjNMI/1l6NXiQSNfK6DlAUthhek6f
wgWz0cEPCB5sn5M2NmXOF0+Bs6dILc3fYDJ2LCeWxAXZr1/P7CjNhhPzzy1VuXwK
1zxe/v/cEJZK+DoAjNhMxb9CJHl2D6X3WVezVW/mqLO3LeGYE8cESQWcJRmXba6P
GrUN0Nnvj+z3zEFGvksnFI/kxP5uIU0a5wi+FgVg534u2NGh3EKKXUjLAlsrmyQA
9FXWd9a9ca7Y3NvJIEiz+O3UzWoLZHrvpnc2TIxo1nyqLmk76xE25HbnYp/JkKsF
X9jthiE0xXmx0N6iplKC
=eMUI
-----END PGP SIGNATURE-----

Patrick Uiterwijk

unread,
May 24, 2013, 7:26:21 PM5/24/13
to reviewb...@googlegroups.com
Hello everyone,

Hereby my email with progress of last week.
Last week I have coded the necessary parts to get the API token in, and I will submit this soon.
This has taken me more time than I had expected, so I have not been able to compare the different OpenID modules yet, so this is what I will be doing the upcoming week.

Christian Hammond

unread,
May 24, 2013, 7:44:12 PM5/24/13
to reviewb...@googlegroups.com
Hi Patrick,

Thanks for providing these reports. They're very useful :)

I'll take a look at the latest draft of your change probably tonight. I hope that's not blocking you too much on this work. (This is where Git branches are awesome.)

Christian

-- 
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org

--
 
---
You received this message because you are subscribed to the Google Groups "reviewboard-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Patrick Uiterwijk

unread,
Jun 11, 2013, 4:14:33 AM6/11/13
to reviewb...@googlegroups.com
-----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-----

Christian Hammond

unread,
Jun 11, 2013, 4:21:13 AM6/11/13
to reviewb...@googlegroups.com
Hi Patrick,

This is a fantastic overview. Thanks for doing this research!

My initial suggestion for django-social-auth was based purely on the recommendations of others, so I'm happy to see your input on it. Sounds like it's the best option.

I'm curious, what kind of changes did you see in the forks, if you went that far into it? (Don't feel you need to if you haven't.)

Christian

--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com


Patrick Uiterwijk

unread,
Jun 11, 2013, 4:32:20 AM6/11/13
to reviewb...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Christian,

The changes vary from fixing specific bugs in peoples setups to attempts to port it to using oauth (yeah, I've seen those on some of the openid specific auth modules).

So some of the forks did fix errors that were showstoppers in the upstream repositories, but since most forks only get one or two bugfixes, they aren't very useful by themselve unless you pull the changes from multiple forks, which was the reason I didn't decide to go for that route.
Especially after finding that django-social-auth is that good of a project (it was the last one I looked at...), I stopped checking all the forks.

Patrick
iQIcBAEBCgAGBQJRtuCUAAoJEIZXmA2atR5Q17kP/2/l7Z6Fw84uKD7NiLIeh3Ck
w46mc1QRUqV5iFXjdlFcL155q//Oh/NveFA/Ttc3zRJhnOFgUAmWtJ8GjFPf1p6L
AkxIuJVIKG4eBVbz5EU6goCNuexg5Pz8Rr+SjRhYQxcIhQtX6HhWgQiA5YEbQ5jJ
iydD2eQ1wLDAtzE/ZJ58nyrNgBAhp/wXKeCA+aGTTl2USt/gVeDcMUNfCRc2Lhgx
FTznQ5YpbchoG/76qfEBEZ53z0DdhczzSnWkmIjtj3N0y8tnCXA49mmkcuEVKjOM
fIg2JdySlOIU1/Q458/1NvqS6xAbb3jg45AtRamsA19Edjkfze2aOoqlyBSKf+NL
kYBSySwV/jOJQpRlD7d8Zttv+7e1jp+0i7Xz49EWLz7EiMV59Re8XQsxF4mdEIjz
v5SnZ98kVGsYli7bjyF1HUPVlPlLSpeaTltNu8euf+zspDaV8jv1ghYDWQoh6j1D
rFbjmw3d47Xf4Tn7to++MI253B76GidPyjJOeX2+c7vxg05fJZpnuhNJ0fkKrxMA
qlxF0SJ4SebzSbWivzC3MsHz5ZYq+X1U787e8CvGrvKX90DhCN4zVqCdi8tI5DP7
B4offTOa+OxNBL3TzwhemvzlmOoKrGMsMkISutoFgT399GEdUCumbuT73s1oxb2k
ZMp+amlbspCWCpOR1W3T
=LHX9
-----END PGP SIGNATURE-----

Patrick Uiterwijk

unread,
Jun 14, 2013, 7:12:50 AM6/14/13
to reviewb...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everyone,

Hereby my next progress report.

Last week, I have been working on implementing django-social-auth into reviewboard.
This worked out pretty well, except that I need to figure out how to setup the UI (both admin of setting it up as well as user-side for logging in).

The hard thing is that social-auth has a lot of different backends, and each of them has different options that need to be set.
Do we want to have all of the backends in the admin panel, or should I just let the admin put it in local_settings.py (as is documented by django-social-auth)?

Thanks in advance,
Patrick Uiterwijk
iQIcBAEBCgAGBQJRuvqxAAoJEIZXmA2atR5QcU4P/1l6+E2xjHX0kV2lanLBk4Nn
C6RNhGOTDXX9Ar3DssZAtYBdaAGxZp29y0WA5XIbzd0dEx++Qm4u3oAocYiT2ytv
KzRewIoU7jkgOVyCnxFOo4uyMwVOTe7Tq9UO6HLlZ9v2qwvkompF04QOC2knVNSV
OINU8u5NveaizlwyGEoP5Ox46oP6vgCn9x2/xUCWENoGp/WqSrw9eRoolOq8N9Ln
FQRNCi8cn+zb/iUOF2GJe8uuLG9VdzGHugGEoAnX3ADPnqeJsehpTTpucuTZ7EqL
7XxiK146HHfaWHN5/ZZe9BjvfwrNJTrNG0b3wmfRF3qbo6YaGaBOprEQZSaivfe5
SkpRpQ5NG7I5K3x+6JhbWqmcUk+YopZGJtOU6Qm5nxQLPp3CGoXxG5SSF91/jgBf
4cyWBTf1WfyeEp2nf2xeMsWjtEJcoPnLNWx9yBbcU/7h/zWwTxs24GZIXtTCWvko
fkNQuQg4iTIm9QFpEbZC8uvl5s6KKg1konqHZCHmw0WnlYMxAdEKNZB07KwxqnG3
AvnMmk15srZUNDPbaRDUwmgaHKTYMm0IIG2CtCeA7DCD7y6PaNVSyzPW9kGL2ej/
qwd1CHCMLIgp5v+qiqJzehV00SRYeE0fmW38FdT5/NtKPoW66cvbMImMjd2bimya
dh0v1Whb+exjoErlCt1v
=ykXo
-----END PGP SIGNATURE-----

Christian Hammond

unread,
Jun 14, 2013, 3:51:28 PM6/14/13
to reviewb...@googlegroups.com
Hi Patrick,

We generally try to avoid admins having to modify settings_local.py. That file should, ideally, be set once during creation of the site (or when rb-site updates it), and that's it. We should have backend customization in the admin UI, just like we do with other auth backends.

There's infrastructure for settings pages today, and for mapping fields in settings pages to django.conf.settings keys. There's also stuff you can reuse for dynamically showing/hiding forms (see what the current auth backends do).

Christian

-- 
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org

Patrick Uiterwijk

unread,
Jun 25, 2013, 10:09:26 AM6/25/13
to reviewb...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everyone,

Hereby my progress report about last week.
It has been a bit delayed, as I had a very busy week at university.

Last week, I have been busy with adding some meta-info do django-social-auth backends, so I can integrate it with the reviewboard admin system.
I have made this for all backends currently in the repo, and will be going to create a merge request with this today or tomorrow, after which I'll use the rest of the week to integrate it into the ReviewBoard admin panel.
I hope to have the review request in coming friday.
iQIcBAEBCgAGBQJRyaSWAAoJEIZXmA2atR5QUtsP/R80+bCpG51TipEHBJvGVRUQ
inFOFVCzULkojRA+g+QtegW4BVih7gkJXo08XbnZPsnrVvPKp1ZCnLNY0Pn9jqZo
O6CXqu1+cdiKmaRodxL7zFpfTzjjRzO5H7sjpYT5mH+r41xKGK9bgDfqy3iMU63g
qsCwJxclJn10b5KlDPL4n0chmwiUNjatQA7B4iG/FUV+oaXNDInOGPvMwMt0WJuF
T9GFLIIuWOKA5u5ROxSiTw1QRpoepDNXPMGz4TByC456FL+G9HNhtUjt51btXN9C
nkKC17rKCd91hE5nWmUG9oPkd57mwaNNwzBpAXmhsLS/oBxmtiVtupR5IyF9E+i1
d2iydlJOQjZ+dNBhBCjF3SNUPRCmyIN3MZrKBDbt8il0nPrRsyjeatZJfEXiq/fG
uKUAVwvtqakygzSw4CbCC9lFimRWGwLo/JH/92zd71kMPGwzimUA3YSFj9ZbTITP
1tpLNe48Rewkm0kbYW1oTmA93X6WU3pzu4tyEIVGsk17X2LXw8WtqhWI/PPu3PkK
rsr/x0KoM0c9T1syM/9P5NHwmTlkrB4lqvKaZvAwWOTcFnEElObJwhAk5sDx9R29
G1oszFCkjLCz/CU/Iiwk9nmppWYitIeqVuWwPRvmojse36mlErjLOlh8xO2uN0kC
vn4uv/mrpBF+LBTVX7S2
=5xwj
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages