Port oauth to Drupal 7

Wondering too, and tagging

There will be a port, but I've no timeplan for it yet. If you need a D7 version of OAuth for any of your projects - then please tell and I will take that into consideration.

Keeping this issue open to keep track of the development.

subscribing. this has become important since Twitter's OAuthpocalypse

Subscribing :)

LinkedIn integration is important to the site(s) I am working on so OAuth capability will definitely be a consideration on for my D7 upgrade readiness

@MehmetOrun: Is it http://drupal.org/project/linkedin that you are referring to or some custom code? I know this module needs to be ported for modules like Twitter and LinkedIn to be able to be ported, but so far I don't know of any work on those modules that are lagging behind because of this module not yet supporting D7.

That is indeed the module, and it does appear to be lagging. I jut wanted to provide you with the use context as requested in the chain

@MehmetOrun: Can't find any status for the D7-port of it though, but thanks for pointing it out :)

I just tried to upgrade OAuth by using the coder module. This is no trivial task because the depending modules have somewhat changed (e.g. autolad / inpustream). Currently I don't really know the internals of OAuth to really be a help with dealing with the internals of this module. I really need it to get a twitter integration running. As you said in #6 it feels like a chicken egg problem. So I tried to upgrade the twitter module by using coder upgrade, too. But this module can't be used without OAuth so testing my upgraded code is not really possible.

The coder upgrade module is not really good when its dealing with DBTNG and both modules are doing some database stuff. This is really a sceewed up situation. What are the problems blocking a D7 upgrade?

We will release a stable version of 6.x-3.x prior to porting to D7. I don't know any problems with doing the port - we just haven't had the time yet.

Regarding the Twitter module - it currently doesn't use version 6.x-3.x - it uses 6.x-2.x and that version will not be ported to D7.

subscribing

Subscribing

subscribing

subscribing, my d7 project requires use of twitter and facebook oauth.

Subscribing— there is initial porting work being done for Twitter module, and OAuth is needed for a port of the 3.x branch.

Subscribing too.

subscribing.

Changed title for best use in the dashboard, changed feature request to support request since a new D7 version is a completely new animal altogether and changed the priority from minor to major since there are quite a few modules/custom code depending on the D7 port. Until then, it looks like most oauth based services for D7 are stumped and can't continue testing.

subscribe

subscribing

As drupal 7 release is near, I believe work has to be started on this.

Just so you know - I'm listening and I will try to do this asap - although there's a couple of other projects higher up on my priority list right now.

Hi voxpelli,

If you allow, I would like to assist you :)

needed, subscribing.

@Zareef: I think we need to wait a little - we should probably get at least #1002482: token_key column not large enough fixed prior to starting porting and as many other issues that should be part of the stable release as well - the more fixed prior to porting, the less back- or forward-porting we need to do later.

Take a look at all tagged issues if you want to start rolling patches for those issues: http://drupal.org/project/issues/search/oauth?issue_tags=OAuth%203.x%20S... Be sure to ask if anyone else has begun work prior to starting - I'm working on a few of them right now, like #1002482: token_key column not large enough.

Subscribing

Subscribing

Subscribing

Sub'ing and offering code assistance if dev is too busy. My company relies on several modules that need oauth(custom and contrib). Is there a github repo for this module? D7 is released so please at least open a new branch for 7.x.

@jlporter: I'll try to rush it as much as I can. As I wrote in #23 I think the focus should be on completing 6.x first and I'll be happy to accept any patches. I am very soon going to have a patch for #1002482: token_key column not large enough so please subscribe to that and be ready to review.

Patch in #1002482: token_key column not large enough posted and updates on how I'll go from here in its comment #7.

subscribing

subscribing

subscribing

subscribing.

subscribing

subscribing!!!!

Subscribing on offering help. Been porting D6 modules since D7 alpha 6 T_T

Also subscribing

Subscribing

+1

subscribing

subscribing

+1

Suscribing

subscribing

Subscribing.

Here is a patch comprising coder_upgrade + a bunch of reading through the diff and fixing up some obvious issues.

I'm confident it needs more work and testing than just this, but hoping this is a start. Also on https://github.com/GiantRobot/drupal-oauth

Have tried my hand at this despite knowing squat about OAuth because #780712: Port twitter to Drupal 7 needs it.
#1002482: token_key column not large enough was the only specified reason (?) for not getting this kicked off and it's been committed so I ran with it.

Removed dependency on Autoload module, but unsure if we need to alter oauth_common to suit D7 autoloading?

PS. You can apply this diff to 6.x-3.x in order to apply just the whitespace changes etc, which should make the actual changes a bit clearer.

Nice work ! It's not fully functionnal but it's a very goooood start !!! Thanks !

Do you got does errors on your side when you activate the module ?!?

* Notice: Undefined index: title dans _filter_list_cmp() (ligne 593 dans /home/myaccount/public_html/mysite/modules/filter/filter.module).
* Notice: Undefined index: title dans _filter_list_cmp() (ligne 593 dans /home/myaccount/public_html/mysite/modules/filter/filter.module).
* Notice: Undefined index: title dans _filter_list_cmp() (ligne 593 dans /home/myaccount/public_html/mysite/modules/filter/filter.module).
* Notice: Undefined index: title dans _filter_list_cmp() (ligne 593 dans /home/myaccount/public_html/mysite/modules/filter/filter.module).
* Warning: uasort() [function.uasort]: Array was modified by the user comparison function dans filter_get_filters() (ligne 583 dans /home/myaccount/public_html/mysite/modules/filter/filter.module).

@sw3b, those errors sound like http://drupal.org/node/224333#hook_filter_info but I think they may be coming from another module; possibly Twitter (#780712: Port twitter to Drupal 7 if you're using it) which dynamically generates some filters.

subs

I'm in Berlin for the rest of the week - will not be able to look at this for a while. Could someone take a look at the outstanding issues for a stable 6.x-3.x release? The reason I haven't done a coder upgrade for OAuth yet is because I wanted to fix those things first.

@voxpelli, my apologies if I have complicated things for you by pushing this forward - I want it working for Twitter module on Drupal 7. I hope that having a D7 module actively using OAuth is a positive step for testing and development of this version. I won't attempt to engage any of the issues in the OAuth 3.x Stable tag unless they get in my way for #780712: Port twitter to Drupal 7.

Here is an update of the previous patch from #46.

Code in my Github fork is updated, testers can grab tarballs there.

With this patch applied to oauth-HEAD, I can now successfully OAuth accounts against twitter.com on D7.

Subscribing.

+1

subscribing

While patch with #51 i get

patch -p0 <807390-oauth-d7_51.patch
patching file includes/DrupalOAuthClient.inc
patching file includes/DrupalOAuthConsumer.inc
patching file includes/DrupalOAuthDataStore.inc
patching file includes/DrupalOAuthToken.inc
patching file includes/OAuthSignatureMethod_HMAC.inc
patching file oauth_common.admin.inc
patching file oauth_common.authorizations.inc
patching file oauth_common.consumers.inc
patching file oauth_common.inc
patching file oauth_common.info
Hunk #2 FAILED at 17.
1 out of 2 hunks FAILED -- saving rejects to file oauth_common.info.rej
patching file oauth_common.install
patching file oauth_common.module
patching file oauth_common.pages.inc
patching file oauth_common_providerui.info
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file oauth_common_providerui.info.rej
patching file oauth_common_providerui.module
Hunk #1 succeeded at 2 with fuzz 1.
patching file updates/update.6001.inc
patching file updates/update.6002.inc
patching file updates/update.6003.inc
patching file updates/update.6100.inc
patching file updates/update.6200.inc
patching file updates/update.6201.inc
patching file updates/update.6202.inc
patching file updates/update.6300.inc

Attached is an updated patch which you can run from your modules root folder. i.e cd sites/all/modules; patch -p0<06022011-oauth.patch

EDIT: everything when well after patching in terms of going through admin/config/twitter but after trying to go to the users profile page i got

Fatal error: Call to undefined function db_fetch_array() in modules/oauth/includes/DrupalOAuthConsumer.inc on line 209

The patch in #51 is to be applied to CVS HEAD, which is why you had rejections on the .info files (only).

Patch docs are at Creating patches (note "CVS example (2)" and "Check your directory!" - module patches should be made from the module dir) and Submitting patches (please read "Name your patch").

Please do not be discouraged by the above - I'm utterly delighted to see more than just a 'subscribe' email - your contribution is most welcome and this feedback is intended only to help you be more effective, and help prevent people confused by multiple patches.

(comment mostly copied from here, updating both issues for clarity only).

subscribing

@grobot according to link you posted -R is an allowed option for creating patches, the only thing i didn't do was create a descriptive name for the patch. Thank you for your feedback and no worries it doesn't discourage me a bit :)

Can the maintainer create a 7.x-3.x-dev branch with the patch from #51 cleaned up as a starting point. Patching against a 6.x moving target will make this more difficult than it needs to be.

@jlporter: I prefer to have time to review the patch first - so might take a few days. I was in out traveling for the majority of last week.

@grobot: Taking a quick look I think this patch makes some excessive code style changes. I think I ran the D6 version through the upgrade and applied all sensible coding style changes. Those I didn't apply I think was the unwanted onces. Can you check if they make sense to you?

Subscribing

subscribing

sub+

The patch needs to be cleaned up to remove code style changes, this should be made into a separate patch.

Also, there are changes in update hooks that shouldn't be there. They actually need to be removed later, since the standard is for users to upgrade to latest 6.x version of the module before upgrading to 7.

sub++

Subscribing

subscribing

subscribing

Can we move development back to d.o, now that Git migration is done?

@recidive: The development is already here? There's no newer version of OAuth than the one at d.o? There's a few patches though.

I'll keep my personal GitHub-mirror though for my personal management of changes and patches.

Well - if anyone could separate the coding style changes in this issues patch into a separate patch then that would be nice - would make it easier to review.

I found a fatal error in oauth_common.admin.inc. When using theme_table, the cell and row class keys should be an array, not a string. So you can add multiple classes to a cell or row.

Attached a patch. I have the above patches applied, but this shouldn't be too much of a modification since then...

As a side note, OAuth configuration won't show up the main configuration page unless it is nested one more layer deeper than admin/config. It will show up if you go to the path manually.

I suggest "admin/config/services/oauth" so that it is grouped with Services and other like modules. This would need to be changed in the above patches (the operations links) as well as in oauth_common_providerui.module.

@mradcliffe - agreed re #76, and thanks for picking it up; thought I'd already flagged that but that it was here (and discussed on the related twitter issue)

I guess I am stupid. I have cloned the supposedly patched for D7 oauth project from #51. However, installing the module cause mysite.com/user to fail with a WSOD and complaining about db_fetch_array() in the error logs. I see that there is no db_fetch_array() in D7 so I am really confused as to HOW you guys have this module working.

I have tried every possible combination of Services and OAuth modules from D6 through D7 and have yet to get a working provider that actually honors and keeps the authorizations you allow. Will there EVER be a working OAuth provider implementation for Drupal?

I originally used the grobot's github remote/7.x-3.x, but have since switched to origin/master.

Edit: I am also trying to use Services and OAuth via services oauth, but am not sure if I'm going to be using OAuth provider as I have to do something special. It *is* a bit hard to comprehend how it all connects, which is why I am weighing what to do myself.

Also, the patches that I attach recently are based off #74's patches.

Here's a menu + context edit form fix patch. I am now three commits ahead of origin/master on my local repository:

• Both patches in #74 to my local repo.
• #75
• #80 (this patch)

What is "Add Authorization Level" functionality? This does not seem to do anything at the moment, but when clicked, before this patch, it would produce a select query exception. After patch, it just does not do anything.

What is "Add Authorization Level" functionality? This does not seem to do anything at the moment, but when clicked, before this patch, it would produce a select query exception. After patch, it just does not do anything.

I think this is the crux of my problem, then. Add authorization level seems related to running as an OAuth provider. Basically, I want to create a consumer key/secret that an application can use to request access to data. The user then has to authorize the application's request before it can get to the data.

So far, I can get to to the authorization page where I'm given the option to allow or deny the request for access, but it never saves it. I'm going to have to abandon OAuth provider functionality in my project for now.

Subscribing.

subscribing

The problem with the context/authorization interface in Drupal 7 is that the new AJAX API is incorrectly setting $form_state after rebuild.

I can get the interface working, but $form_state not saving. This may be because the documentation is rather poor. I did try using the "new way", which uses ajax_form_callback instead of defining your own menu callback, but maybe we need to keep doing it with our own menu callback and not use ajax_form_callback.

I was able to get the AJAX interface working for the OAuth consumer secret. Attached is a patch to get that working.

• #74
• #75
• #80
• #84

subscribing

I'm now utterly confused as to how to get from the Github fork posted in #51 to the last patch in #84. I've tried every combination of patching along the way and failed miserably. Can someone point me in the direction to the latest (pre-patched) version of this module for me to try?

These are all from origin/master here on git.drupal.org, not github. Here is a zip file with everything from #74 to now.

I haven't had a chance to work the admin interface issue since.

Ah, gotcha. Thanks.

subscribing

has someone got to apply all the patches? We have a lot of problems in implementing
Will we have a dev version soon? I understand that this module is very important to connect to (Facebook, Twitter, Linkedin,...) and there is a bootable version.

Can we create any branch?

Thanks,
Alvaro

I agree with alvmarveg...

We'll have a dev-version as soon as I get time to look at the code and to commit it. Real reviews of the port could of course speed that up - so far very few has actually looked at the quality of the patches - something I as a maintainer need to do. The fact that it works isn't enough.

If you need any help, ask us for helping.

thanks,

One can help in two major ways:

• Review the code in this issue's patches - all non-D7 related changes should be removed from them since they should be applied to both D6 and D7 and should therefor be separate patches
• Take a look at the issues needed for a stable release (valid for both D6 and D7): http://drupal.org/project/issues/search/oauth?issue_tags=OAuth%203.x%20S...

It's pretty much nowhere near done. There is a ton of work to be done (including D7 DBTNGizing many of the dynamic queries).

I forked to a sandbox so I can keep track of changes. Highly experimental/development.

You can add it as a remote repository, just like grobot's old github repository, at http://drupalcode.org/sandbox/mradcliffe/1118190.git.

Some recent additions:

• fixed several form callback issues
• changed DrupalOAuthConsumer and DrupalOAuthToken queries to dbtng. Delete stuff had to get unoptimized as joins are not supported everywhere (foreign key @todo). Deprecated stuff removed.
• more AJAX fixes
• some other minor changes in forms

I will begin work on this now and will commit as soon as I have something to commit.

I'm having major issues trying to get $form and $form_state to update in ajax_callback_form.

What do you think about switching to a ctools interface for authentication levels?

Nevermind. I figured it out. I had to rework the auth level stuff completely. The custom template for that is broken right now, but the functionality works for adding authentication levels. Committed to oauth-7.x-3.x.

I've added a test that runs through making drupal oauth requests in #1120310: Tests for OAuth 7. I was able to fix a couple of bugs because of the test I wrote. :)

Ideally we also probably want admin and user interface tests, but this works as a pseudo-unit (functional) test. It also would be a good start for documentation of 3.x branch.

At this point we have a github repo, and now a personal d.o sandbox. Shouldn't we think about getting an official 7.x oauth branch started, even if it's broken? It would make it easier to keep an updated clone for development and creation of patches that everyone can use. As it is now, the state of things is rather confusing.

subscribing

subscribing

subscribing

I can do some work on DB-TNG. I should be up to date on the latest patches.

I'm having trouble checking out the sandbox project. What am I doing wrong?

$ git clone http://git.drupal.org/sandbox/mradcliffe/1118190.git oauth_7_x_3_x
Initialized empty Git repository in /var/www/drupal7/sites/all/modules/contrib/oauth_7_x_3_x/.git/
remote: Counting objects: 387, done.
remote: Compressing objects: 100% (213/213), done.
remote: Total 387 (delta 266), reused 233 (delta 163)
Receiving objects: 100% (387/387), 133.12 KiB | 88 KiB/s, done.
Resolving deltas: 100% (266/266), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

It should still create the directory even if it "failed" to checkout the non-existent master branch. You need to git checkout -b oauth-7.x-3.x --track origin/oauth-7.x-3.x. I should probably rename oauth-master to master, but for now do that command.

edit: oauth-master changed to master branch (which corresponds to 6.x-3.x).

Hi,

First time looking at anything drupal so apologies if this is a obvious silly question.

I have been trying to apply patch 51 to my code and if fails because of
- DrupalOAuthToken.inc Hunk #5 FAILED at 123
- DrupalOAuthConsumer.inc Hunk #3 FAILED at 120

These appear to have comments in which were not expected in the patch, in Consumer this was //TODO: Add compatibility layer? at line 122.

Am I getting the wrong base source. I use the following command

git clone --branch 6.x.3.x http://git.drupal.org/project/oauth.git

Apologies is I have been stupid

So apart from the issue with the wrong code posted above.

Managed to check out 6.x-3.x add patch 51 (After removing 2 comments), patched 2-6 of mradcliffe. There were two other files with comments in which cause problems in one of the patches. Again I just removed them.

To get it to work I also had to

Change line 215 of twitter.module from

$key = $row->twitter_uid;

to

query->execute()->fetchCol()

And work around JSON_BIGINT_AS_STRING which does not exist on my Lucid 5.3.2. I simply change the if to have a 5.4. I am sure there are many many more professional fixes.

in need of Oauth for Drupal 7 version

Subbbbing

only 3 issues left on the D6 version (as per #23) so these have to be resolved before a D7 port.

http://drupal.org/node/980340
http://drupal.org/node/775334
http://drupal.org/node/927998

+1

subscribing

Not only would I like an official port to D7, an example implementation would be really nice too! The Twitter and/or Connector modules don't show how to use the oauth basics of getting authorised and fetching data from a third party like Facebook or Flickr.

subscribing

I want to use the D7 version found in git to fetch data from OAuth providers (consumer mode), but I can't seem to find where to configure those providers.

Or is this not possible yet in the D7 port?

That's done by using the oauth module API (in PHP). Sometimes, like Twitter, providers use really strange implementations of OAuth, which is probably why you found the Twitter module's usage hard to follow.

There are several classes to use:

• DrupalOAuthConsumer (or OAuthConsumer)
• DrupalOAuthToken (or OAuthToken)
• OAuthSignatureMethod
• DrupalOAuthRequest (or OAuthRequest)

Basically, you generate a consumer, token, and signature object via the methods required by the oauth implementation (facebook, google, etc...). Then you make an oauth request object via the consumer, token, url, etc..., and sign the request with the signature object. Then you can make a curl call to the url of the request $request->to_url().

Also, depending on the type of request you're making you may or may not need token. It should all fit into the OAuth work flow for that implementation.

@mradcliffe: if I understand correctly, this OAUth (aka oauth_common) module can store keys and secrets for Drupal users, which is the added value by using this module, right?

Too bad there's absolutely no documentation on how to use it...

I've separated my D7 port support question into a support ticket: #1146178: OAuth consumer

sub

Subscribing.

subscribing!

I have committed an initial incomplete port to D7 - most parts are done, but they are untested and some thing like AHAH haven't been ported yet.

The changes made has been made from scratch - when the basic functionality is there I will perhaps try and look for further enhancement from some of the others port that has contributed, but due to none of those ports being able to produce a proper patch that only changed what needed to be changed I've been forced to redo much work.

A dev-release has been created and will appear once the drupal.org-systems find time to build it.

I don't understand. With git, you can track the changes all the way back to the formatting patches. And then look at back porting the formatting patch.

Whatever.

@mradcliffe: Yes, I could of course go through the commits and check and change every line that I didn't agree with. But looking at the ports it looked like that would have been more work than doing the upgrade myself. As I said I will check the ports for further enhancements when the basic port is complete. Please feel free to start new issues with patches for such enhancements.

I'll keep this open until we've made sure that the D7 port works - which means at least until I've ported the AHAH things.

I will try to do some testing soon on this. I will be using it primarily in order to get the Twitter module to work in D7 as Oauth is a dependency.

subscribing

+1

subscribing

There's now a first release, 7.x-3.0-alpha1, at: http://drupal.org/node/1195326

It should mostly work and therefor I'm closing this issue as fixed. Please open new issues if you find any problems or anything that hasn't been ported.