Live data from Hacker News

OAuth for Python made easy

github.com

31–39 of 39 posts

Re: OAuth for Python made easy

#32
post #16
post #12

Earlier quoted context omitted.

https://github.com/hasgeek/lastuser was the least painless method in my experience but I never tried any non-lastuser clients with it so I can't comment on library compatibility.

it doesn't have any docs and even from the page I have no idea what it actually does, it doesn't look like an oauth provider (?)

It implements oauth 2.0 draft 16. http://www.slideshare.net/jace/user-management-with-lastuser

It's not complicated to break down the UI as you need it.

Re: OAuth for Python made easy

#33

If you'll allow me a shameless plug... My company (dailycred) wraps ten OAuth 1 & 2 providers, as well as email & password and Mozilla Persona in a single OAuth 2 call. (We started this project because even just within OAuth 2, providers break spec left and right and OAuth can be a huge headache, so we manage all of those headaches for our customers.)

If you're wondering what some of the discrepancies are, I wrote up a bunch here: http://john-sheehan.com/post/41653656681/the-good-and-the-ba...

Re: OAuth for Python made easy

#34
post #30
post #25

Earlier quoted context omitted.

Whoops, didn't notice the chronology. All the same: OAuthLib and its libraries cover the exact use-case you've laid out, just in a fashion that has some architectural benefits on top of the usability goals. The simple "OAuth for Humans" thing you're reaching for exists—it's https://github.com/requests/requests-oauthlib . Kenneth and I hashed this interface out before we started out on OAuthLib, and thus far it's the…

> All the same: OAuthLib and its libraries cover the exact use-case you've laid out Nope. They very much do not: your expectation is that your users will roll their own clients or use Requests' shim, which seems a little rough around the edges and doesn't provide for the necessary use cases, e.g. OAuth 2.0 and Ofly. I'm sorry, but this is not providing for the use cases I've laid out by any stretch of the imagination…

Fair enough. I indeed _haven't_ used rauth, just read the docs. And indeed, OAuthLib's requests shim is a bit rough in terms of tests and docs, but the OAuth1 use-case is quite solid—it doesn't do the dance for you, but every subsequent request is the bulk of the work (in my experience). For that application, the API's seem pretty similar to me—you can instantiate a requests session with a set OAuth auth object and make requests like "session.get(some_uri)" without the magical per-service mapping.

I guess I just feel like tying to one specific service is too specialized. Libraries like requests should be providing you with enough primitives to be flexible and enough abstraction to be "simple," though we clearly disagree on what constitutes the appropriate balance.

Re: OAuth for Python made easy

#36
post #31

Earlier quoted context omitted.

Not yet.

Basically the main reason for python-social-auth ( https://github.com/omab/python-social-auth ) to use oauthlib/requests-oauthlib instead of rauth.

We have plans to implement Python 3 support. It's not the highest priority but we want it to happen. I'll probably slate it for v0.6.0. By the way, community participation is more than welcome...there was a pull request that provided support for 3 but unfortunately it wasn't updated to bring it inline with the breaking changes 0.5.0 had to introduce. So, if you have any inclination to hack on a patch that provided Python 3 support I'd be very grateful and could probably even work alongside its development.

Re: OAuth for Python made easy

#37
post #32
post #16

Earlier quoted context omitted.

it doesn't have any docs and even from the page I have no idea what it actually does, it doesn't look like an oauth provider (?)

It implements oauth 2.0 draft 16. http://www.slideshare.net/jace/user-management-with-lastuser It's not complicated to break down the UI as you need it.

I've moved up to draft 22. The OAuth2 spec is now final, but I haven't been keeping track of what's changed. The final revisions seemed to be all around SAML.

Re: OAuth for Python made easy

#38
post #37
post #32

Earlier quoted context omitted.

It implements oauth 2.0 draft 16. http://www.slideshare.net/jace/user-management-with-lastuser It's not complicated to break down the UI as you need it.

I've moved up to draft 22. The OAuth2 spec is now final, but I haven't been keeping track of what's changed. The final revisions seemed to be all around SAML.

Serious thanks for releasing this - it's been great to work with and really enjoyable to use as an entire platform for auth. We integrated it with our own openID service but great to have the functionality there if we want to open it to other sign-ons. Are you expecting any major changes once OAuth2 is final?

Re: OAuth for Python made easy

#39

Recently I tried doing cas integration for my django website. A colleague pointed to a Rails gem - install a gem, point to the cas url and, poof, done. For django, I struggled, and struggled. Found a couple of libraries and a number of forks of these spread across github and bitbucket. Got one, but it didn't work. Debugged the code, fixed some stuff in my own fork, and got it working 5 hours later. The world of pytho…

I couldn't agree with this more. In Rails, I'm used to using omniauth, and plugging in any number of provider gems that deal with the subtle differences between how Dropbox and LinkedIn and whatever implement OAuth...and having them all hook into whatever Rack based framework I use (Rails, Sinatra, etc)

Rauth is a good start, but without a library that couples it to a full web stack, I'm spending a lot of time hooking it into my flask app and trying to make sure I don't make mistakes managing my session variables, etc.

Perhaps I'll start up a rauth-providers repo to catalog this stuff.

Post reply on HN