State of the issue:

This is an important upgrade for all Facebook Applications, and it must be made before Oct 1, 2011. So a patch for this is a high priority and development is active.

The D6 branch is updated. Use the 6.x-3.x-dev release, or the 3.1 beta release. (The 3.0 release uses the older PHP SDK.)

The D7 patch needs testing. See the bottom of this thread for patch, and please post whether it works for you.

You can accelerate this effort by contributing. Stay tuned to this thread for updates. Thanks.

Original issue:

I downloaded the module, followed the prerequisite and everything went fine so far.
But when I tried to submit my facebook connect info I got Fatal error: Call to undefined method Facebook::getSession() line 177 of ... fb.module
I delete the module and I know I can't even reinstall it without getting this fatal error...

Can someone help?


I got this same error, and it's also in the fbconnect module, so it make me think Facebook changed their API in the sdk

Facebook did indeed change the API. This module will not work with version > 3.0.0 of the FB PHP SDK. You will need to use one of the older versions of the SDK - e.g.

On a related note, are there plans to update this module to be compatible with the new SDK?

Title:fatal errorPHP SDK v3.0.0 (a.k.a undefined method Facebook::getSession())
Version:6.x-3.0-rc3» 6.x-3.x-dev
Assigned:Will Igetit» Unassigned
Category:bug» task

Now I see what they've done. Changes like this are part of the reason it's taken so long to get modules fb 3.0 out the door.

I plan to get a modules/fb 3.0 released on Facebook SDK 2.2. Supporting their 3.0.0 probably means a modules/fb 4.0 branch. I'm interested in patches if anyone wants to upgrade these modules to PHP SDK 3.0.0.

Dave, on that page you're linking to it says the new PHP SDK is using OAuth 2.0, and that "all apps must utilize the new OAuth flows by September 1".
Do you think this means the old PHP SDK and code that depends on it won't work after that date?

Yes, whenever facebook removes support for it. Drupal for Facebook will support it long before that.

But since facebook, which before now didn't even assign version numbers to their SDK, is giving it a major release number, I'm going to assume that it is appropriate to create another branch just for this. So modules/fb version 4.x will be mostly like version 3.x, but using this new library.

Ok, cool. Thank you so much for your work! I wish I could contribute in some way, but Facebook still makes me really, really confused. So I think I would cause more damage than good if I started submitting patches now :)

Dave- which facebook-php-sdk tag is supported by the current fbconnect release and the dev version?

Looking through the commit history I see that v2.1.2 supports OAuth2 error formating, and it's not clear which tag you would need to roll back to in order to fix the getSession undefined method error.

I'm honestly not sure. My guess is anything that starts v2.

Rolled back to v.2.1.1 which works of course. I'm not sure why the v.2.1.2 commit uses OAuth2 error formatting if OAuth2 isn't introduced until v.3.0.0, but in any case didn't have a chance to look at it yet.

You're saying v2.1.2 does not work?

(I appreciate help testing this. Facebook, sometimes, is a bunch of kids doing really sloppy work. The platform is much better than it once was, but still shocking how little QA there is. It's like nobody there actually uses it.)

new454 bytes

Confirmed v2.1.2 works.

Also, attached is a patch for the README file for this release indicating that you need a pre-v.3.0.0 release of the fb-php-sdk. Without the patch users will almost certainly download the latest version and it will not work.

Your patch did not apply, but I added something to the README.txt.

Version:6.x-3.x-dev» 7.x-3.x-dev

Dave, could you put a note in the README for 7.x-3.x also? It took me a while to track this down.
Thanks for giving the community such a great module! Totally saved my bacon!




Rolling back the PHP SDK libraries from facebook-php-sdk-v3.0.1 to facebook-php-sdk-v2.1.2 solved my FaceBook Connect problems:

     - Thanks

Status:Active» Needs review
new240.23 KB

Okay, first thing is first, to start using SDK 3.0 we need to remove all instances of getSession(); and setSession(); from the php code. First git patch attached... against head version. Use setAccessToken() and pass the access_token variable that is retrieved from the javascript SDK.

Looking into the next steps...

Status:Needs review» Needs work

Your patch has many lines that seem to change only spacing. It's hard to read.

At any rate, no patch will complete the work until facebook releases the upgraded javascript SDK. In typical FB fashion, the latest PHP SDK is incompatible with the latest javascript. (

Thanks for the review. I couldn't find a copy of 7.x-3.x on git to run diff:

First patch, will try again soon.

Use master for 7.x.

Status:Needs work» Needs review
new4.83 KB

Okay, lets try this one. It looks a lot cleaner!


Just looking it over (haven't actually started using the 3.0.0 SDK), I noticed you replaced fb_get_token($_fb) with $_fb->getAccessToken(). Do you know, does $_fb->getAccessToken() return the application's token or the current user's token? They have access to different data and it can get confusing.

Since I already know what fb_get_token() does, I recommend not changing those calls. fb_get_token() returns the application's token, unless it is passed an fbu, in which case it returns that user's token (if known).

Thanks for the feedback! I will keep working on it. Maybe we can start a 7.x-4.x branch to play with soon.

Here is a snippet from the facebook PHP SDK 3.0. It looks like it will use the users access token if available and fall back on the application access token if not.

public function getAccessToken() {
    if (
$this->accessToken !== null) {
// we've done this already and cached it. Just return.
return $this->accessToken;
// first establish access token to be the application
    // access token, in case we navigate to the /oauth/access_token
    // endpoint, where SOME access token is required.
    if (
$user_access_token = $this->getUserAccessToken()) {

This little bit of code should set the user access token if they logged in: $_fb->setAccessToken($session['access_token']);

Status:Needs review» Needs work

So getAccessToken will return either a user's token or an application token. What that tells me is places that need a token should either...

1) use fb_get_token(). Or,
2) use $fb->getApplicationAccessToken(), when app token is needed.
3) use $fb->getUserAccessToken(), when currently logged in user is needed.

Calling $fb->getAccessToken() will just lead to confusing errors when either the app token or user token is expected but the other is returned.

Looking again at the patch, I see what I think are problems...

   // test if we are tracking only those apps that have been granted offline
-  // access.
-  $fb_session = $fb->getSession();
+  // access. Not sure what to do here yet ?? - NB
+  $fb_session = $fb->getAccessToken();

Above is wrong because getAccessToken will always return a token. That code needs to learn whether the user token expires. I'm not sure what's right, but not what's here.

-      $settings['fb_init_settings']['session'] = $fb->getSession();
+      $settings['fb_init_settings']['access_token'] = $fb->getAccessToken();

Above will (sometimes) put the application's access token into the page (javascript settings). Major security problem! User's should never be able to learn the application's token!


Hi Dave,
Is this what we've been waiting for?


Thanks udipl. That looks like the JS update we need.

I feel these updated APIs call for a 4.x branch of modules/fb. Even though the changes are relatively small.






Title:PHP SDK v3.0.0 (a.k.a undefined method Facebook::getSession())PHP SDK v3.1.1 (a.k.a undefined method Facebook::getSession())
new3.71 KB

Making some progress. Patched fb.module and fb.js to reflect some of the recent facebook SDK updates.



Status:Needs work» Needs review
new9.8 KB

Success! I have authentication working on one of my test sites with the fb module and the new facebook SDK changes. To test, git the master branch, patch it, download the latest php SDK (tested with v3.1.1). Enable modules: Facebook API, Facebook Apps, Facebook Connect, FB User Management. Configure as needed and update your app settings - enable oAuth settings under migrations. Clear cache and update as needed. May need to clear cookies.


new8.54 KB

Re-rolled to work with latest master. Removed a few unnecessary changes and a blank space error.

Hello all
another time with facebook SDK and drupal 7
i ve read the readme txt in facebook stream module:
the problem:
in sites/default/ settings.php
i ve been using the the link to sdk to the libraries:
$conf['fb_api_file'] = 'sites/all/libraries/facebook-php-sdk/src/facebook.php';

but it does not take it
i changed it to facebook stream directory:
$conf['fb_api_file'] = 'sites/all/modules/facebook_stream/facebook-php-sdk/src/facebook.php';
and with the facebook sdk version 2.2
i managed to enter my site admin interface


Priority:Major» Critical

Hi Dave,

Looking at the blog post you linked from here

Facebook has a deadline for the new SDK:

"All apps must utilize the new OAuth flows by September 1."

As I understand these come with SDK 3.0 and above.

Mind if I bump this to critical? This means we have 5 days to go :)

Title:PHP SDK v3.1.1 (a.k.a undefined method Facebook::getSession())Upgrade Drupal for FB to PHP sdk 3.1.1

This may be a better title

Title:Upgrade Drupal for FB to PHP sdk 3.1.1Upgrade Drupal for FB to PHP sdk 3.1.1 (a.k.a undefined method Facebook::getSession())
Version:7.x-3.x-dev» 6.x-3.x-dev

I understand the deadline to be Oct 1st. See (and don't expect any facebook blog posts to remain accurate or ever be corrected for accuracy).

I like "Facebook::getSession()" in the issue title. I may be kidding myself but I feel like I'll get less duplicate issues that way.

Also planning to address 6.x first.

+1, do you have an ETA? Are you looking for some help? If so in which areas?

I don't have 6.x installed on any of my sites. I might convert one over from fbconnect for testing. This module looks promising (well done sir!).

Anyway I imagine the changes are similar. We need to remove all instances of getSession() and setSession() from the PHP and add 'oauth' => TRUE to the $fb_init_settings.

In the Javascript FB.getSession is not compatible with OAuth2 (error message below). So that needs to be removed. Some calls to session need to be changed to authResponse with different variables. Such as response.session.uid is now response.authResponse.userID

Also app settings need to be updated on the facebook end. Not sure if that is possible from the module. I know nothing about that and it sounds like it will be automatic after the deadline 10/1/2011.

FB.getSession error message:

User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
Timestamp: Wed, 17 Aug 2011 05:54:07 UTC
Message: FB.getSession incompatible with OAuth2.
Line: 23
Char: 785
Code: 0

I wonder if facebook publishes an older "all.js" to maintain compatibility. It's possible to host your own (older) version of their JS, but that's a hassle.

It probably makes sense to make a 3.1 branch, rather than 4.0, if this is the only real change. Is it possible for one set of code to support both versions of their libs? Probably not worth that headache.

I think the 6.x and 7.x changes will be nearly identical. I'd like to also add something to the status report showing which version of facebook SDK is being included.

Is it possible for one set of code to support both versions of their libs? Probably not worth that headache.

On the Facebook Developers group, an employee of facebook told me that the apps based on the sdk v2.x will stop working on the 1st october.
See the conversation here:

Btw I tried the option "Encrypted Access Token" in the developer app using the sdk 2.x and I get an error from Drupal when forms are validated.

new1.74 KB

This patch is not an attempt to fix the problem, but an attempt to not fail quite so hard when the wrong version of facebook php sdk is installed.

My intention is to add this code to 3.0 branch, then fix the problem in the 3.1 branch.

We've got a couple of client projects running that will need to be upgraded to 3.x php sdk, if you need any help to roll out this patch let me know.

I appreciate the offers of help! In fact I've just set up a chip-in to raise some funds specifically for this. So if you or your company makes money in part via Drupal for Facebook, I'd appreciate sponsorship. See

The grant money that got this project off the ground is spent. Now, it is sponsored by companies that hire me for contract work or pay for specific features/fixes. There's no one company behind this particular fix, and since it is important to everyone using the module, I'd like to see it paid for by a community effort.

My goal is to have the fix checked in next week, so everyone has at least two weeks to update their servers. I know, even that is not a lot of time.

If you can't help financially (or even if you can), another way to help is testing the patches that appear on this thread. And contributing to those patches if you have the technical know-how. I will post a patch for 6.x shortly...

new11.22 KB

This patch is for D6. Based on Nathaniel's #39, with some cleanup for D6 and additions.

- fb-connect button "perms" attribute is now "scope" (you may have to manually reconfigure block).

- fb_user_app.module can no longer tell the difference between a user who's token expires and one that doesn't. So that module is broken and I'm not sure yet the fix.

So, these differences go beyond just changing calls to getSession(). As usual, Facebook makes it sound simpler than it really is. To be extra helpful, they've taken their "open source" javascript SDK and closed it, until their next f8 conference. I guess they think we like surprises. Anyway, some of this complexity I did not expect, and that's in part why I set up a chip-in campaign to sponsor this particular fix.

new18.21 KB

Here's an update, still very much work in progress.

Please help test! And in particular test complex log in/out situations. For example, connecting on one tab, the logging out of facebook in another, then returning the original tab and refreshing or following a link. That sort of thing. Try revoking authorization instead of logging out, or logging into facebook in another tab. All permutations you can think of that should result in session changes.

Also please try with third-party cookies disabled and see if anything works as it should.

Anyone out there relying on the "offline_access" permission? And using fb_user_app.module to store access tokens? I think that functionality is broken, or at least not all it used to be.

Patch is looking good over here, authorize / de-authorize works, account mapping works, tried it with third party cookies disabled as well. Tried the same thing via a canvas app with no luck, doesn't seem to work.

Also, I'm getting two FB Connect buttons on the login and registration forms, not sure how this is happening. The big one doesn't work, but the small one does. I temporarily fixed it by changing the class name of container div from "fb-login-button" to "fblogin-button". I found the same thing was happening with like buttons on another project.

Hope this helps!

Whoa, interesting comment. I wonder if facebook's javascript looks specifically for that class name (or any that starts "fb-"). Their javascript is no longer open source, so its harder to check what it is up to.

Can you be more specific about canvas pages? I just started testing some and haven't run into problems yet.

new21.54 KB

Here's the latest rev of the patch. What I'm currently testing.

Oh BTW, my initial sense is that this is a big improvement to facebook's auth! There's a lot of hacks in modules/fb to get around the handful of ways the older code was broken. I may be kidding myself but I'm hopeful all that code can go away. I'm also optimistic that this patch is close to ready.

Also regarding cookies, I've noticed the newer code sets cookies with a different name (fbsr_.... where it used to be fbs_....). So if you encounter problems its worth noting them, then clearing cookies and re-testing.

Just tried the canvas page again, seems to work well when I've registered an user account outside of Facebook. But, if I authorized / register a new user within a canvas page, it doesn't map the accounts properly.

My tests with canvas pages are still working. I see that new users are created/mapped within the ajax session change callback, as expected. Can you be more specific how to reproduce the problem?

I have my fb_devel.module enabled, and use $conf['fb_verbose'] = 'extreme'; so the drupal logs tell me exactly when the new user is created.

Here are my settings:

Page: admin/build/fb/app/%/fb_app

Facebook connect
- Primary

Facebook user settings
- Create local account > Do not create accounts automatically.
- Map accounts > Map when uid and fbid / email matches local account (Both checked)

Page: admin/build/fb/fb_user

User Settings
Username Style for Automatically Created Accounts > Human-friendly

Registration Process (canvas page):

Page: user/register

Connect > Allow

Page refreshes, I see my FB account details, fill in fields, create a new account, redirects to front page and I'm not logged in.

As an administrator, I check user/%/edit/fb_user and there is no account mapping.

Here is the post authorize event:

    [fb_app] => stdClass Object
            [fba_id] => 1
            [status] => 1
            [nid] => 0
            [label] => commix_drupal_test
            [apikey] => 162127037203745
            [id] => 162127037203745
            [secret] => (removed)
            [canvas] => commix_drupal_test
            [title] => Drupal Test
            [data] => a:4:{s:6:"fb_app";a:1:{s:13:"set_app_props";i:1;}s:9:"fb_canvas";a:3:{s:12:"theme_iframe";s:1:"0";s:15:"front_anonymous";s:0:"";s:11:"front_added";s:0:"";}s:10:"fb_connect";a:1:{s:7:"primary";i:1;}s:7:"fb_user";a:4:{s:14:"create_account";s:1:"1";s:11:"map_account";a:2:{i:2;i:2;i:3;i:3;}s:12:"new_user_rid";s:1:"0";s:18:"connected_user_rid";s:1:"0";}}
    [fb] => Facebook Object
            [appId:protected] => 162127037203745
            [apiSecret:protected] => (removed)
            [user:protected] =>
            [signedRequest:protected] =>
            [state:protected] =>
            [accessToken:protected] =>
            [fileUploadSupport:protected] =>
    [event_type] => post_authorize
    [event_data] => Array
            [q] => fb_app/event/commix_drupal_test/post_authorize/
            [signed_request] => H-c_-rjw6laV8DKicRPIi0O0hu4KhuIWWfTQxyyoges.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImV4cGlyZXMiOjEzMTU1MTkyMDAsImlzc3VlZF9hdCI6MTMxNTUxNTAzOCwib2F1dGhfdG9rZW4iOiJBQUFDVGRDUjJCU0VCQUswZGJJR05lSGM3RHB6ZlB2eXJVZTdsN1V3cnBEY3FaQ3pIYjFobXZPZ2tISDBTa1lQSzhGMWNFdVpDZ1pDUnNIZmV1SVd0eFFFTUhkWkNHMXlzSFpBRGRWUmxQWFFaRFpEIiwidXNlciI6eyJjb3VudHJ5IjoiY2EiLCJsb2NhbGUiOiJlbl9VUyJ9LCJ1c2VyX2lkIjoiNTEwMDA4OTY2In0
    [q] => fb_app/event/commix_drupal_test/post_authorize/
    [signed_request] => H-c_-rjw6laV8DKicRPIi0O0hu4KhuIWWfTQxyyoges.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImV4cGlyZXMiOjEzMTU1MTkyMDAsImlzc3VlZF9hdCI6MTMxNTUxNTAzOCwib2F1dGhfdG9rZW4iOiJBQUFDVGRDUjJCU0VCQUswZGJJR05lSGM3RHB6ZlB2eXJVZTdsN1V3cnBEY3FaQ3pIYjFobXZPZ2tISDBTa1lQSzhGMWNFdVpDZ1pDUnNIZmV1SVd0eFFFTUhkWkNHMXlzSFpBRGRWUmxQWFFaRFpEIiwidXNlciI6eyJjb3VudHJ5IjoiY2EiLCJsb2NhbGUiOiJlbl9VUyJ9LCJ1c2VyX2lkIjoiNTEwMDA4OTY2In0

What is it doing? Creating an account but not adding map to fb_user table? Do you appear to be an Anonymous user in Drupal?

In my tests it both creates and maps account.

Check the advanced tab on the remote (facebook) settings. Do you have signed request for canvas pages enabled? I'm testing with all the "migrations" enabled.

Correct, all migrations are enabled.

It will create an account but not map to fb_user table, and after account creation the user is still anonymous, if I login afterwards it will successfully map the accounts.

Another thing I'm noticing is that in this weird user state after creating the account and not having the accounts mapped. If I logout of Facebook and go back to the canvas page, I'm somehow logged in to Drupal with the account I just created. If I log back into Facebook, I'm logged out of Drupal.

Fresh Drupal install with only fb, fb_app, fb_canvas and fb_user modules installed. I can provide you with a link to a test site if you'd like.

Sure, send me a link via contact form. I'll take a look when I get a chance. I wonder if having fb_devel.module disabled make a difference.

I've applied the latest patch to (and So if anyone notices anything odd going on there, please let me know.

Hey Dave,

Re Oauth, you may want to take a look at this as it says it is a helper module for sites wishing to use oauth.


I had the same issue... in fb_user.module about line 1019 try this

function fb_user_get_local_user_by_email($fbu) {
  global $_fb;
  if (isset($_fb) && $fbu) {
    try {
      $info = $_fb->api($fbu);
      if (isset($info['email']) &&
              ($email = $info['email'])) {
        $users = user_load_multiple(array(), array('mail' => $email));
        $user = reset($users);
        return $user;
//        return user_load(array('mail' => $email));
    } catch (Exception $e) {
      // This can occur when user logs out of facebook in another window, then returns to our site.
      if (fb_verbose()) {
        fb_log_exception($e, t('Failed to get facebook user email.'));

Sorry for no explaination...I am about to get off the train. :)

After some digging, this looks to be a separate issue unrelated to the Facebook 3.1.1 SDK change.

I was able to solve it by changing line 603 in fb_user:

if (!$_fb_app && $op == 'insert' || $op == 'login') {
    // A facebook user has logged in.  We can map the two accounts together.
    $fb_user_data = _fb_user_get_config($_fb_app);
    if (($fbu = fb_facebook_user()) &&
        $fb_user_data['map_account'] == FB_USER_OPTION_MAP_ALWAYS &&
        !fb_controls(FB_USER_CONTROL_NO_CREATE_MAP)) {
      // Create fb_user record if it doesn't exist or update existing one
      _fb_user_set_map($account, $fbu);
      // @TODO - if the app has a role, make sure the user gets that role. (presently, that will not happen until their next request)


if (!$_fb_app && $op == 'insert' || $op == 'login') {
    // A facebook user has logged in.  We can map the two accounts together.
    $fb_user_data = _fb_user_get_config($_fb_app);
    if (($fbu = fb_facebook_user()) &&
        //$fb_user_data['map_account'] == FB_USER_OPTION_MAP_ALWAYS &&
        $fb_user_data['map_account'][FB_USER_OPTION_MAP_ALWAYS] == FB_USER_OPTION_MAP_ALWAYS &&
        !fb_controls(FB_USER_CONTROL_NO_CREATE_MAP)) {
      // Create fb_user record if it doesn't exist or update existing one
      _fb_user_set_map($account, $fbu);
      // @TODO - if the app has a role, make sure the user gets that role. (presently, that will not happen until their next request)

I will apply this patch on some test client sites and will let you know if I encounter are any other bugs.

Thanks funkym. I've pushed that fix (unrelated really to this thread) to dev release.

Doing some more in depth testing on client sites, noticing that some of my forms inside of canvas pages won't submit with "Encrypted Access Token" mode enabled in the Facebook App > Advanced settings.

I'm getting a "Validation error, please try again. If this error persists, please contact the site administrator." generic error upon form submission.

Seems to work fine with "Encrypted Access Token" disabled though.

Looking at the code, it seems as though the form token isn't validating or is not being sent. Is anyone else experiencing this?

It is probably getting confused about the session. I bet the session id (and also cookie domain) change when the form is submitted.

On a regular canvas page, where a signed request is found, it uses the app id from the signed request (encrypted). On the form submit, it gets the app id from the url rewriting (not encrypted). Probably the fix will be in It sets a cookie domain in there to prevent the session in an iframe from being the same as when you visit the site directly. But if the cookie domain changes between request, it will screw things up.

new24.8 KB

I think I've fixed the form submit problem in this latest version of the patch. Thanks for reporting it.

Sigh, there's so many complex cases in modules/fb, which have come from changes to facebook platform over time. I'm trying to remove the obsolete ones.

Dave, could you look into fb_test.module?

Using 6.x-3.x-dev with Facebook SDK 3.1.1

Call to a member function api() on a non-object in sites/all/modules/fb/contrib/fb_test.module on line 90

skolesnyk, if you can reproduce that error consistently, please submit another issue explaining exactly how to do it.

I tried out the patch on the latest dev release on one of my canvas apps today with 3.1.1, have not had any problems yet. Looking good!


Applied the latest patches, all seems to be working for me. I haven't tried https functionality yet, we're waiting for certificates.

Status:Needs review» Reviewed & tested by the community
new28.24 KB

Here's a update with a minor change to make fb_devel.module less verbose. I've noticed with the new oauth that api calls fail with the app token, and fb_devel.module was being very verbose about it. It's unclear whether it is a bug on facebook's side, or the new way things work, but the application's access token doesn't work as well as it once did. (When calling into facebook, you have a choice between the app access token or the user's access token). This shouldn't affect most app's, because they mostly use the user's token.

Glad to hear it is working. I'm planning to start the 3.1 branch with this patch.

Version:6.x-3.x-dev» 7.x-3.x-dev
Status:Reviewed & tested by the community» Patch (to be ported)

OK, now theres a 6.x-3.0.x branch for the older PHP SDK. The 6.x-3.x dev branch has this patch, so requires the newer SDK. I've created a 6.x-3.1-beta1 release, hopefully that will appear on soon.

The patch above needs porting to D7. Any volunteers? Any sponsors? I appeal once again if you use these modules professionally please contribute! I'm not the best at asking for financial support and I don't often ask but this particular issue has taken a lot of my time already. Thanks!

Hey Dave,

I will make sure to donate $50 later today. Way less then you deserve for all your work, but all I can afford. Hope it helps get 3.1 ready for October 1!

Anyone else using Drupal for Facebook to make money should contribute as well!

new28.29 KB

Well I took the fb_oauth_d6.patch and applied it to the fb 7.x-3.x-dev 2011-sep-09 snapshot.

My process was to go to fb directory and then use:
$patch < fb_oauth_d6.patch

Then I listed the .rej files and manually went through and applied those changes.

I've never used the fb module before so I can't verify correctness but I've attached what I did as fb_oauth_d7.diff using diff -ur.

Status:Patch (to be ported)» Needs review

Issue summary:View changes

Adding the current status.

Hey I finally figured out my problem with facebook and openid-selector( so I can now report that my patch works for me (for login atleast). If someone wants to point me in the right direction on how to setup a like button with a howto link I'll test that as well.

Dave Cohen wrote

The patch above needs porting to D7. Any volunteers? Any sponsors? I appeal once again if you use these modules professionally please contribute! I'm not the best at asking for financial support and I don't often ask but this particular issue has taken a lot of my time already. Thanks!

I think it's vital for many of us that 7.3.x module will be ready before October, 1st with patches or sending money to Dave.
Please contribute to this great module!

The link to contribute, financially, is

Hi Dave and other developers,

there's any chance that the 7.x.3.x version of this module would be ready by October, 1st?
Is there any 7.x.3.x testing version that support new PHP SDK?
Please make us clear how to collaborate to get a working version ASAP.

Facebook says in addition to supporting SDK 3.1.1 that "iframe Canvas and Page Tab apps must support HTTPS and provide a secure canvas or secure page tab URL."

Will Drupal for Facebook support using a secure canvas URL?

Title:Upgrade Drupal for FB to PHP sdk 3.1.1 (a.k.a undefined method Facebook::getSession())Upgrade Your App to OAuth 2.0 and HTTPS by October 1st (a.k.a undefined method Facebook::getSession())

Here's the latest patch I'm testing for Drupal 7.x. Please download the latest .dev release, apply this patch, test your site and post here whether you encounter any problems.

The switch to HTTPS is another issue. The most important thing you need to do there is configure your server to support HTTPS!. So if your website is, make sure also works. If you administer your site from the https address, and sync the properties of your app, it will automatically make the canvas callback url start with https.

If this upgrade for Drupal 7.x (or 6.x) is important to you, please contribute.

new30.7 KB

Woops, here's the latest patch I mentioned.

Regarding the HTTPS...

If you administer drupal via your https address, it will make all the callback urls HTTPS. This is probably fine.

An alternative is you manually edit the app's "remote settings" on facebook. Copy the value from "Canvas URL" to "Secure Canvas URL" and manually change http: to https: . Do the same with "Page Tab URL" and "Secure Page Tab URL".

You may need to set those Secure URLs even if you administer your drupal over https. Facebook's doc makes this not clear.

As far as I know, modules/fb can automatically set the Canvas URL and Page Tab URL, but facebook provides no mechanism to automatically set the Secure URLs.

It turns out, facebook has made the secure url properties available to the platform api. So they can be set automatically.

Please see #1295082: Secure URLs for canvas pages and tabs for HTTPS related issues.

This thread, let's keep it to just OAuth 2.0.


The patch seems to be OK. I am just testing fb, but without the patch 7.x-3.x-dev would not work at all. After applying the patch it seems to behave normally.

does that latest dev from the 30th include this patch?

Status:Needs review» Fixed

Yes, latest dev includes this patch.

I have applied the patch and everything works fine except that now when in Canvas page, the links absolute URLs are not re-written, and therefore the links jump out of the facebook to the main website. As far as I remember, when I was using the old version the canvas pages were OK and I have not made any changes in my applications. So I suspect that it has to do with the new patch or the new Facebook PHP library (Version 3). Anyone has the similar problem or idea on how to fix this?

Rather than applying the patch, get the latest dev build from It it still happens, submit a new issue so its clear which version you're using and all that.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

Updated status with link to 3.1 beta release