OAuth for Python made easy(github.com)
github.com
OAuth for Python made easy
https://github.com/litl/rauth#rauth
9 comments
First, I believe rauth existed prior to your library: rauth is over a year old now. (Or maybe existed at around the same time; regardless as you'll see below, contributing to your project wouldn't have made sense for us.)
Second, you're trying to solve a different problem than rauth solves: we needed a library that provided for the practical, de facto implementation of OAuth 1.0/a and 2.0 as well as Ofly which allowed us to consume provider APIs. This is exactly what rauth does. It loosely wraps Requests, which means you get to basically use Requests that also happens to handle real-world OAuth providers as a consumer. I don't think it's really fair to call this "silly": it's clearly filled a hole in the ecosystem for some people.
If you want to consume an OAuth provider, rauth tries to give you a simple interface to do so with. It's almost as easy as using Requests. You might even say, it's OAuth for Humans. (Sorry, Kenneth. :)
Edit: to be clear, rauth is about pragmatic simplicity, about a clean API that's pleasant to work with. It's a client for OAuth modeled around the fact and philosophy of Requests. Vis-à-vis everything else I've seen, this is in pretty stark contrast to existing libraries.
Second, you're trying to solve a different problem than rauth solves: we needed a library that provided for the practical, de facto implementation of OAuth 1.0/a and 2.0 as well as Ofly which allowed us to consume provider APIs. This is exactly what rauth does. It loosely wraps Requests, which means you get to basically use Requests that also happens to handle real-world OAuth providers as a consumer. I don't think it's really fair to call this "silly": it's clearly filled a hole in the ecosystem for some people.
If you want to consume an OAuth provider, rauth tries to give you a simple interface to do so with. It's almost as easy as using Requests. You might even say, it's OAuth for Humans. (Sorry, Kenneth. :)
Edit: to be clear, rauth is about pragmatic simplicity, about a clean API that's pleasant to work with. It's a client for OAuth modeled around the fact and philosophy of Requests. Vis-à-vis everything else I've seen, this is in pretty stark contrast to existing libraries.
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 only shim library for OAuthLib I know of (though it's pretty simple to write something equivalent which bridges OAuthLib's domain knowledge and any given HTTP request implementation). I even rewrote Requests' underlying auth implementation to make this sort of thing possible. And now you have:
oauth = OAuth1(client_key=key, client_secret=secret) r = requests.post(url=request_token_url, auth=oauth)
I don't see OAuth1 getting simpler than that, and the underlying signing logic is there for anybody to use in any context—as a provider, consumer, in a stubbing library—whatever!
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 only shim library for OAuthLib I know of (though it's pretty simple to write something equivalent which bridges OAuthLib's domain knowledge and any given HTTP request implementation). I even rewrote Requests' underlying auth implementation to make this sort of thing possible. And now you have:
oauth = OAuth1(client_key=key, client_secret=secret) r = requests.post(url=request_token_url, auth=oauth)
I don't see OAuth1 getting simpler than that, and the underlying signing logic is there for anybody to use in any context—as a provider, consumer, in a stubbing library—whatever!
> 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.
Rauth is batteries included, ready to get you up and running in minutes, not hours or days. You won't need to write your own client or patch an existing client to make it work with an unsupported protocol like OAuth 2.0.
> I don't see OAuth1 getting simpler than that
Then you haven't used rauth. The whole auth dance is taken into consideration and various helpers make it a breeze, literally a two or three step process. Further, once you have tokens, it becomes as simple as:
I think in your attempts to compare your lib to rauth you're missing the broader thrust of rauth: rauth is a client library. It makes using OAuth (1.0/a, 2.0, even the OAuth-ish Ofly) as easy as we can make it. This is far removed from the goal of some generalized, spec-centric, even idealized, implementation of OAuth as a spec. Rauth isn't trying to do that, it's trying to make it easier for you to connect to Facebook or Twitter or whatever provider you happen to need. I wouldn't really know, but I've been told, it seems to shine in this regard. :)
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.
Rauth is batteries included, ready to get you up and running in minutes, not hours or days. You won't need to write your own client or patch an existing client to make it work with an unsupported protocol like OAuth 2.0.
> I don't see OAuth1 getting simpler than that
Then you haven't used rauth. The whole auth dance is taken into consideration and various helpers make it a breeze, literally a two or three step process. Further, once you have tokens, it becomes as simple as:
session.get('me')
I think in your attempts to compare your lib to rauth you're missing the broader thrust of rauth: rauth is a client library. It makes using OAuth (1.0/a, 2.0, even the OAuth-ish Ofly) as easy as we can make it. This is far removed from the goal of some generalized, spec-centric, even idealized, implementation of OAuth as a spec. Rauth isn't trying to do that, it's trying to make it easier for you to connect to Facebook or Twitter or whatever provider you happen to need. I wouldn't really know, but I've been told, it seems to shine in this regard. :)
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.
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.
Thanks for your work on rauth, I've been using it for a long time and I'm hoping to update my projects to use the latest version to pick up requests 1.x support some time soon.
Is it really necessary to couple to requests in order to have a decent OAuth implementation?
Why not a layered API, with lower levels supporting a higher-level wrapper library using requests?
Why not a layered API, with lower levels supporting a higher-level wrapper library using requests?
Look at the examples and docs on the oauthlib library. It's like Java. SkeletonValidator(RequestValidator) ??? This is totally the opposite of pragmatism, and one of the main reasons I've moved away from Python and build most things in Ruby now.
After doing Django for 5 years, the nail in the coffin was when I wanted to simply access a users me object from their facebook graph timeline. Riddle me that. In ruby-pragmatism land it's a gem and a line or two of code away, thanks to the awesome Koala library.
Kenneth Reitz's recent requests library is the first refreshing and pragmatic python tool I have seen in a long time. This oauth library shares the same friendly and straightforward interface too. The docs and examples are directly clear and directly in front of you. It's simple and pragmatic.
The stars on the repo's speak for themselves ... rauth has over 700 stars, whereas oauthlib has considerably less than half of that. I'm not trying to tell you that you suck, because I admire your work quite a lot, but I think these days developers want simple and pragmatic.
After doing Django for 5 years, the nail in the coffin was when I wanted to simply access a users me object from their facebook graph timeline. Riddle me that. In ruby-pragmatism land it's a gem and a line or two of code away, thanks to the awesome Koala library.
Kenneth Reitz's recent requests library is the first refreshing and pragmatic python tool I have seen in a long time. This oauth library shares the same friendly and straightforward interface too. The docs and examples are directly clear and directly in front of you. It's simple and pragmatic.
The stars on the repo's speak for themselves ... rauth has over 700 stars, whereas oauthlib has considerably less than half of that. I'm not trying to tell you that you suck, because I admire your work quite a lot, but I think these days developers want simple and pragmatic.
In one breath, you're complaining about a library's complexity in abstracting away an underlying mess, and in the next, you're praising a library that is complex and abstracts away some underlying mess.
It's not about stars. It's about the right architectural choice. Believe me when I say that we thought long and hard about the structure of OAuthLib, and it looks nothing at all like Java. When we started out, we were reacting to the mess that is/was python-oauth[2] and its class-based ridiculous. Like all real-world projects, after spending time with the spec and refactoring the parts which were common to the various signing flows, you end up with some real-world ugly.
It's not about stars. It's about the right architectural choice. Believe me when I say that we thought long and hard about the structure of OAuthLib, and it looks nothing at all like Java. When we started out, we were reacting to the mess that is/was python-oauth[2] and its class-based ridiculous. Like all real-world projects, after spending time with the spec and refactoring the parts which were common to the various signing flows, you end up with some real-world ugly.
This entire complaint would go away with a thin 'for humans' wrapper on top. If you look inside requests and its dependencies you will see some complexities too, they are just hidden from you. But this does not mean that it makes sense to write the low-level stuff in a way that prevents reuse - though that reusability might look abstract - this is the reason we are swimming in OAuth implementations.
Just in case anyone is confused, this is a library for client-side OAuth. That said, it's great for quick test scripts — it made my life a lot easier when I was working on a provider implementation.
EDIT: Although their README only shows an OAuth1 example, check out https://github.com/litl/rauth/blob/master/examples/github-cl... for an example of using it with an OAuth2 provider.
EDIT: Although their README only shows an OAuth1 example, check out https://github.com/litl/rauth/blob/master/examples/github-cl... for an example of using it with an OAuth2 provider.
So I guess that's the open part.
If you're looking for a more full stack framework in python, tornado has had support for oauth since it's release. It's implementation does rely on the tornado ioloop though, so it's not something you can easily just pull and use elsewhere.
This is the underlying problem: OAuth implementations that are coupled to other pieces of technology not strictly related to OAuth. So then we keep reimplementing the same protocol over and over again.
It's really easy to use too. I recently extended the base implementation for a service that it didn't support and it took me very little time.
I put some time into it a couple years ago before my 2nd kid was born. I've always wanted to go back and work on making it a bit easier to use. One of the things I'd love to do is get rid of it being so tied to request handlers so you can use it more seamlessly in apps.
Yeah it would be great to be able to make API requests using the helper methods from outside of a request handler. As it is, it isn't that difficult to do it otherwise but it's just more code duplication.
to be honest I am currently lost on the state of oauth in python, has sth changed since this post http://pydanny.com/the-sorry-state-of-python-oauth-providers...? as OP is a client lib, could somebody with practical experience tell me what's the current best library for setting up an oauth provider? bonus question: should I bother with 2.0 or stick to 1.0 (3rd party apps and mobile) http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell... ?
Not much has changed. I'm currently working to open source an implementation I worked on that's compliant with the finalized version of the spec. The most up-to-date implementation I've seen in the open is https://github.com/hiidef/oauth2app, which implements draft 16.
thanks, looks sane.
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.
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?
Thank You, Thank you! After the state of python-oauth2 this comes as the best oauth library to be used in Python. I however I have one query - how would you handle Oauth three-legged requests? [0] This is important for people who do not necessarily build web apps but collect data from Twitter using Oauth (for a higher API limit).
[0] https://dev.twitter.com/docs/auth/3-legged-authorization
[0] https://dev.twitter.com/docs/auth/3-legged-authorization
Does it work? I tried to do some OAuth in Python a couple of years back and it was a total disaster; four competing libraries, none of which worked. But that was a long time ago and I don't think this Rauth library even existed when I last looked.
Yes it definitely works and does so more easily than any alternative I've tried. I've used it to interface quickly to something like 20 different APIs at this point.
Maybe you should try it?
Yes.
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 python seems to have lots of half-baked libraries that are dead or dying. Makes you miss Ruby / Rails.
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 python seems to have lots of half-baked libraries that are dead or dying. Makes you miss Ruby / Rails.
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.
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.
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.)
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...
Does rauth work with Python 3?
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.
Doing OAuth signing logic correctly is pretty finicky. Requests is great, and we provide a shim layer for it, but it's silly to reimplement the underlying request signing logic for requests, urllib3 or what-have-you. And what happens when you need a server-side implementation for verifying signatures? It makes more sense to do the tricky logic in a separate, testable library than tying it to one representation of an HTTP request.
Having said all this, anybody willing to wade into this mess and write something is my kind of crazy. Respect.