3 ms·

I wish the author had contributed to existing efforts (https://github.com/idan/oauthlib https://github.com/idan/oauthlib) instead of rolling yet another OAuth i

by idan 14y ago

I wish the author had contributed to existing efforts (https://github.com/idan/oauthlib https://github.com/idan/oauthlib) instead of rolling yet another OAuth implementation. We set out to build a robust, comprehensive, spec-complete OAuth signing logic library a year ago, and today it delivers what it says on the tin, thanks to a lot of work and a raft of dedicated contributors. We have support for all of the OAuth1 spec, and we're working towards OAuth2. The idea is to have one de-facto reference OAuth implementation for python instead of a few confusingly different choices, because the differences are really hard to spot for anybody who hasn't spent some time cuddling up with the RFC. 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.

whalesalad 14y ago
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.
- pekk 14y ago
  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.
- idan 14y ago
  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.
llambda 14y ago
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.
- pekk 14y ago
  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?
- trtg 14y ago
  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.
- idan 14y ago
  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 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!

by idan 14y ago

whalesalad 14y ago

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.

pekk 14y ago
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.
idan 14y ago
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.

llambda 14y ago

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.

pekk 14y ago
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?
trtg 14y ago
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.
idan 14y ago
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 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!