Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Current version: http://oauth.googlecode.com/svn/code/php
This library has little support. The aim is to replace it by http://pecl.php.net/package/oauth.
Comments
Comment #1
juampynr CreditAttribution: juampynr commentedWork should be done at branch 7.x-4.x. I have made an initial commit there with an updated README, but the version select field does not yet show the 7.x-4.x branch.
Comment #2
sunLet's do an extensive research for possibly existing PHP libraries first in order to not re-invent the wheel.
Also, just found this: ;)
http://grokbase.com/p/php/php-internals/115mjc0m2m/php-dev-porting-pecl-...
If we're going to port/write the PHP library from scratch, this should ideally be done outside of Drupal and this module (e.g., github), using a more permissive non-GPL license (e.g., MIT), be based on latest PHP 5.3 features and also adhere to the PSR-0 standard.
I'm highly interested in this, might even consider to lead that effort (in case it is needed).
Comment #3
voxpelli CreditAttribution: voxpelli commentedI think the focus in a switch like this should be to better support multiple versions of OAuth - have a unified system that can get tokens through both the OAuth 1 way and the OAuth 2 way and which can at least handle OAuth 1 access tokens and OAuth 2 bearer tokens but also be pluggable to support more or less any kind of OAuth 2 token - like eg. mac tokens (http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05) and completely custom tokens.
I have yet though to see a good library that does both OAuth 1 and OAuth 2 - and I think I haven't seen a single one that supports OAuth 1 and 2 for both servers and clients like the currently used library does for OAuth 1.
I think the best idea, if the current library should be switched out, is to build an entirely new one.
Beware though - some (most) of the current libraries - like the one we are using and tmhOAuth and such has some quirks that's not entirely documented. If I remember correctly variables like "foo[]" or "foo[bar]" is dealt with in a rather weird way - something that an OAuth 1 client and server needs to be able to deal with to stay compatible with existing libraries.
Also beware that the current library is patched to support a few OAuth 1 extensions, like http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/s... and I think http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html - these should imho be supported in a new library as well as they make OAuth 1 much more useful and since without them some sites might find themselves stuck with the older version.
Lastly: Also be aware that at least in Drupal 6 many other modules are using this module to include the OAuth library file and not because they actually use the module itself - it will be hard to provide a good upgrade path for them. Hopefully this isn't true for Drupal 7 though.
Comment #4
juampynr CreditAttribution: juampynr commentedChanged issue title.
Branch 7.x-4.x is ready. Now it is time for people to chime in and give their opinion about what is better. Possible chances we have seen so far are:
Are there any other libraries? What is the current library missing? Why building a new one?
Comment #5
sunI thought the current library is http://oauth.googlecode.com/svn/code/php ?
Comment #6
juampynr CreditAttribution: juampynr commentedIt is based on http://oauth.googlecode.com/svn/code/php, but @voxpelli did a couple of fixes on it. That is why I have moved it out to Github.
Comment #7
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedHi there, I was contacted today by juampy. I have a working module of OAuth for drupal 7 based on PECL, you may have a look here: http://drupal.org/sandbox/SylvainLecoy/1127118.
Juampy asked me why I did on my own and you may interrested to following the discussion. That's the email I answered:
Also, please note that I submitted the idea in september 2010 and it was rejected #926368: PECL::OAuth.
Comment #8
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedI would also add that the PECL OAuth has very good support.
I have a couple of email with John Jawed one of the current maintainer asking for feature request (such as making non-final the OAuth class) to allow extensibility and he answered very positively. Here is the discussion for instance: https://bugs.php.net/bug.php?id=59578.
Comment #9
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedWhat about working together then ?
I could work on making the 'application' entity system integrate better with drupal. We could decide on a set of quality API interfaces that we agreed on for any OAuth objects used by the module. On your side you can also create your own library to be switched in case there is no PECL available... Just tell me ! I would be very excited to collaborate.
Regards,
Sylvain Lecoy
Comment #10
juampynr CreditAttribution: juampynr commentedThe main author of the OAuth protocol leaves the team because of lack of consensus and direction on the OAuth 2 project. This may make us think twice if we really want to support OAuth 2.
Have a look at http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell
Comment #11
RobKoberg CreditAttribution: RobKoberg commentedAt least for now, any chance of checking for an existing OAuthException? If you install the pecl oauth extension there is a conflict.
Comment #12
pwolanin CreditAttribution: pwolanin commentedWow, I was on the emil list for Oauth2, but stopped reading it regularly since I didn't think the MAC protocol discussion was going to be very fruitful.
Based on the post at http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell I'd agree it might be better to simply stay focused on OAuth 1.0a
Comment #13
juampynr CreditAttribution: juampynr commentedThis leaves us with the pending task to review if the PECL library implements OAuth 1 or 2, and if it also implements both server and client protocol. Has anybody have had a look at it?
For the moment, we can still keep with our library, which is hosted at https://github.com/juampy72/OAuth-PHP
Comment #14
sunhttp://pecl.php.net/package/oauth / http://php.net/oauth implements OAuth 1.
Comment #15
MD3 CreditAttribution: MD3 commentedThis kind of goes along more of the lines about our current implementation, but what is different about our library from the googlecode version? I created an issue here on the Github repo so that developers outside the Drupal community can see it as well:
https://github.com/juampy72/OAuth-PHP/issues/2
Comment #16
juampynr CreditAttribution: juampynr commented@MD3, see #3 for differences in our Library against the Googlecode one.
I would have to go through the log to view changes on the library, as they were mostly done by previous maintainers. Not sure if I can find time for that at the moment.
Comment #17
MD3 CreditAttribution: MD3 commentedThanks @juampy! I guess I missed that when I was reading the thread. That explains pretty well what he added:
-Better 2-legged support, it looks like?
-support for parsing formats other than x-www-form-urlencoded
I've gone ahead and quoted @voxpelli in the Github issue for future reference and closed it!
Comment #18
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedSorry for the late answer,
PECL OAuth implements OAuth 1.0a, as well as both client and server protocol.
The team is reactive and responsive, also very open-minded. The two leads are Rasmus Lerdorf and John Jawed. Since 1.1.0 the project has been pretty stable and no major API changes has been committed since, which is a good indicator for project maturity.
Comment #19
bojanz CreditAttribution: bojanz commentedAs I said in #795994: Implement OAuth 2.0 protocol, I don't think it's necessary for this module to try and support OAuth2 at all.
So the library can be OAuth 1 only.