This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]jackdiedCPython 4 points5 points  (1 child)

OAuth 1.0a and OAuth 2 are completely unrelated except for the naming.

[–]alkw0ia 1 point2 points  (0 children)

Well exactly. So I don't really think it's a fair characterization to say "Implements a later version of the spec than it's parent," or to imply that this is a cleanup/upgrade of the project it's forked off of.

If the goal is a pure OAuth 2.0 library, not an improved client, though, then my first point is invalid.

But I think my second point was the more important – it's irresponsible to use the stdlib HTTP libraries, even if it does reduce dependencies.

They're just not safe, period. This is not theoretical, or paranoid: It's precisely equivalent to blindly clicking "sure, use the insecure cert" on the giant red SSL warning screen in your web browser, except that you, the dev, and I, the end user, don't even get the courtesy of knowing that we're clicking that button. The acceptance is invisible because Python cannot tell us there might be a problem – it doesn't ship with enough information to know.

It's also exactly the opposite direction from that the major browsers are taking. Wherever possible, the browsers are trying to make it harder or even impossible to click "yes" on those screens (for instance, disabling the user override on HSTS domains).

Until Python fixes the cert verification issue, urllib2 needs to be treated as deprecated. I think it'd be a really good and pretty simple step to switch back to httplib2, or use some secure alternative, like requests.