Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OAuth for Python made easy

github.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: OAuth for Python made easy

#21

Post by pekk »

llambda wrote: post #15
idan wrote: post #13

I wish the author had contributed to existing efforts ( 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 toward…

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 allowe…

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?

Re: OAuth for Python made easy

#22

Post by manojlds »

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.

Re: OAuth for Python made easy

#23

Post by pekk »

jrussbowman wrote: post #9

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.

Re: OAuth for Python made easy

#24

Post by pekk »

whalesalad wrote: post #14
idan wrote: post #13

I wish the author had contributed to existing efforts ( 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 toward…

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-pragma…

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.

Re: OAuth for Python made easy

#25

Post by idan »

llambda wrote: post #15
idan wrote: post #13

I wish the author had contributed to existing efforts ( 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 toward…

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 allowe…

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!

Re: OAuth for Python made easy

#26

Post by idan »

whalesalad wrote: post #14
idan wrote: post #13

I wish the author had contributed to existing efforts ( 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 toward…

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-pragma…

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.

Re: OAuth for Python made easy

#27

Post by denzil_correa »

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

Re: OAuth for Python made easy

#29

Post by nostromo »

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.)

Re: OAuth for Python made easy

#30

Post by llambda »

idan wrote: post #25
llambda wrote: post #15

Earlier quoted context omitted.

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 allowe…

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.

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')
Now, that's what I call simple.

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. :)

Post reply on HN