OAuth 1.0 and 1.0a client

[Diana Maria Prajescu]

Hello everyone,

I have this PR opened for 6 months now and I haven't got too much feedback on it, maybe I should've been more insistent in order to get your attention. Anyway it seems to me that it won't be merged it the current form and I would really appreciate some details, how exactly do you want this to work?

Louis said he would like the oAuth authentications to be supported similar to basic authentication, by injecting it into JHttp instead of wrapping JHttp. Correct me if I'm wrong, the basic authentication is very simple, just set the username and password in the URI, using JUri. I can't see how the oAuth authentication can be done in a similar way. The oAuth flow requires several http requests before obtaining an access token and being able to make authenticated requests. How can this be done without wrapping JHttp?

--
Thanks,
Diana

[Donald Gilbert]

I'm sure you've looked at it, but the joomla/oauth2/client.php would be a good comparison factor on how to accomplish some of those things you listed. I haven't had a good chance to look at much of it (you're PR or the accepted oauth2 code), but I can guarantee that they would both benefit in having similar API calls.

I'm so swamped with the ns effort and things at work that I'm not sure when I'll have time, but I really want to go over this for you. :) I'll try to make the time this weekend.

[Diana Maria Prajescu]

OAuth1 and oAuth2 are similarly structured. I wrote the oAuth1.0a and 1.0 client during this summer because I needed it for my GSoC project (JTwitter and JLinkedin). OAuth2 was written by Aaron in a bit of collaboration with me, he wrote it initially for JGoogle and I was also using it  for Google+ and JFacebook.

--
Diana

[Ian]

I have been meaning to share some of my thoughts on this but haven't had a chance.  My apologies.

I think that OAuth really has to be broken out into two parts.  The first part is the process to get a token and the second part is making the actual request.

IMO the application really has to handle the flow for getting a token so the approach I would take would probably include building a controller that could be leveraged to handle the oauth callback.

The second part is making the actual request.  There are a variety of patterns that you could use here.  I think overall though, that the important thing is that we should end up with the ability to have some sort of JHttp descendant that handles the OAuth part more or less transparently.

The idea being that with, for example, a JTwitter class, you could make any JTwitter OAuth request by simply injecting in a JHttpOAuth1 object instead of a regular JHttp object.  That way you don't have to change JTwitter at all - you just swap in the JHttp object that knows how to inject in the OAuth token, and it does it.

Ian

[Amy Stephen]

Diana -

It's unfortunate things didn't go more smoothly, but, let me tell you, it did give you a chance to show the rest of us what patience and tenacity looks like! =)

I appreciate also that you are correctly pointing out that what matters is getting a OAuth1a solution in place for these applications waiting on it. I know you are short of time, and sadly, everyone I know seems to share that same problem.

Ian - rather than try to find someone with time to catch up in this area and make those changes needed, would it make sense to look at Louis's PR, again? If he has essentially coded this in the manner the platform maintainers want architecturally, is that be the quickest way forward?

https://github.com/LouisLandry/joomla-platform/commit/9bc988185ccc3e1c437256cc2c927e49312b3d00

Just throwing that out there for consideration.

Thanks guys.

[Ian]

On Saturday, 19 January 2013 08:42:39 UTC-8, Amy Stephen wrote:

Diana -

It's unfortunate things didn't go more smoothly, but, let me tell you, it did give you a chance to show the rest of us what patience and tenacity looks like! =)

I appreciate also that you are correctly pointing out that what matters is getting a OAuth1a solution in place for these applications waiting on it. I know you are short of time, and sadly, everyone I know seems to share that same problem.

Ian - rather than try to find someone with time to catch up in this area and make those changes needed, would it make sense to look at Louis's PR, again? If he has essentially coded this in the manner the platform maintainers want architecturally, is that be the quickest way forward?

No.  Louis' pull request is for an OAuth1 server rather than what we're talking about here, which is an OAuth1 client.

[Amy Stephen]

Understood on the server side difference. There is also a fair amount of client code that looks like it uses the approaches you are describing. The controllers, integrated into the HTTP request, getting tokens, etc. was hoping there might be overlap, that's too bad that there isn't.

Thanks Ian.

[Ian]

There is some overlap, for sure.  But it is solving different problems.  The message stuff is probably reusable because you're still creating the same signature.  The OAuth1Client class is different though - the one in Louis' pull request is for storing information on registered clients and that is generally not the sort of stuff that the client itself has to worry about - it will generally only have one set.

Ian