Designing OAuth2 client support about oauthlib HOT 12 CLOSED

I like where this is headed. I guess I'll have to read the spec a few more times before I can have much useful feedback, but I'll at least point out that in the real world, responses for OAuth 2 aren't quite as easily parsable as the spec suggests, at least for access tokens. For example, Facebook and GitHub return data in a URL-encoded string, rather than JSON, and Facebook even misspells expires_in as expires. But still, with this approach, the base implementation can follow the spec, while subclasses can override as necessary for provider-specific quirks.

from oauthlib.

There's also wildly inconsistent support for passing state back and forth. I'm not sure where that fits into this approach, but it's worth noting in case it gets buried into a method somewhere. For most services that don't support it, it can be mimicked by adding it as a query parameter to redirect_uri but there's no good way to know in advance whether a service supports it properly.

from oauthlib.

Interesting, I have mostly been reading the spec and have had little experience with OAuth 2 providers. I guess the inconsistency comes from early adoption, the first versions did in fact use url encoded strings.

The state parameter is optional and will be so in the client methods as well, so if they have dodgy support for it, it can simply be omitted. There might indeed be a need for special extensions that do not provide new grant types but rather patches provider specific quirks like those you mentioned.

On an unrelated note. Draft 27, that was published recently, is quite solid and will be submitted for RFC review. No major changes can therefore be introduced =) I have not checked the diff of 25 & 27 but doubt there is anything but fixed typos.

from oauthlib.

Oddly enough, I've been dealing mostly with providers and haven't been focusing as much on the spec so far. Admittedly, we should be able to use Content-Type to determine how to parse the access token, so that shouldn't be a big deal. I might spare some time this weekend to see if I can come up with a working set of classes that work the way you've described here and see how it plays out. For what it's worth, I also have a fork of requests where I'll be adding support for whatever we come up with here, as well as trying to use all of that in foauth.org, so it won't be purely theoretical. :)

from oauthlib.

Hrm I guess content-type could be used although it might be better to use provider specific extensions since url encoded responses are not valid OAuth 2 responses anymore and will not be in the RFC either.

Before I get all into OAuth 2 I was hoping to find my magic free time wand and send some ✨ over for @idan and @dgouldin who are both pretty swamped but really the brains behind this operation =)

When I do get started on OAuth 2 though my idea for the classes was to wrap the functionality provided by #18 as it already supports most of what I had in mind. #18 has not yet been merged but will try and get around to it after I've sorted OAuth 1 Server out. It should not require much work but want to spend some time inspecting it nonetheless, mainly to see what stupid things 3 months ago me might have written.

Will be fun to see what you come up with. If you do create code for OAuthLib remember that OAuthLib should be in strict adherence to the spec, be agnostic of other libraries (ie requests), have a pretty dumb but usable interface (ie uri, body, headers instead of some fancy request object). Oh and unicode everywhere!

from oauthlib.

Drafted some Client classes based on the ideas presented here. Will try and find some time tomorrow to test them out.

from oauthlib.

Made a few small tweaks, added initial tests for Client and WebApplicationClient. Hope to get tests in for UserAgentClient, PasswordCredentialsClient and NativeApplicationClient over the weekend. Will cook up OAuth2 support for requests as I go along and maybe a gist or two with examples =)

from oauthlib.

An example of using oauthlib & requests to access your Google+ profile using the OAuth 2 Web Application workflow

https://gist.github.com/3078882

from oauthlib.

What's the status of this ticket? My first impression after reading this ticket and browsing the source is that most of this has been implemented. Yes? No?

from oauthlib.

More or less yes. I'm still not that happy with the current state of OAuth 2 client support in oauthlib and thought I'd take a good look at it and see how it can be made better and what of requests-oauthlib can be ported over. Whether that is tracked here or in a new issue I don't really mind.

from oauthlib.

Sketched out a few changes in 6c14274 and will try test them out more thoroughly next week.

Main addition is the addition of a few recommended prepare_x_request methods to interact with clients in a more consistent way. Also HTTPS and state checking.

Might be easier to browse at http://oauthlib.readthedocs.org/en/latest/oauth2/clients/baseclient.html when its updated.

from oauthlib.

Closing since the majority of the ticket has been implemented.

from oauthlib.