Infinite redirects when visiting facebook CONNECT pages

What are the user settings on the facebook app. Are you creating local accounts and mapping them? Please be more specific than "logged in". Do you mean logged into facebook or drupal? Has the user authorized the app?

I've made a bunch of changes lately. Mostly to better support facebook connect. It's very possible I broke canvas pages in the process...

I got the same problem too, and I think the demo link in the http://www.drupalforfacebook.org/ also got that redirect loop problem..

I can't reproduce it. What's the URL your browser is pointing to?

What operating system and browser versions are you using?

Here's the link: http://apps.facebook.com/drupalforfacebook/node
I'm using WinXP SP2 and Firefox 3.0.7

Browsing with firefox gave me this error:

Redirect Loop
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

EDIT: Using Opera 9.50 on the same box, the link is working as intended. So, I guess this is a firefox-only problem

I'm also having the same issues. Tested in 5.14 and 6.10 getting the same results.
It works great on the canvas page, when not logged into Facebook.
But, once logged into Facebook the redirect loop error is displayed in Chrome, IE, and FF.
However, in Safari "Error while loading page The URL http://mysite.com/fb_cb/180/fb_cb/180/ did not respond." is displayed.
And in Opera "The URL was redirected to http://apps.facebook.com/myapp/fb_cb/180/. Please click the link to go there." is displayed.

I am quite sure I had this all working on 5.14 install as of 2 days ago, and I did not make any changes. So i'm quite curious as to why this is happening, any ideas on how to fix it?

*update so yea, once logged into FB it just keeps going to http://mysite.com/fb_cb/180/fb_cb/180........ which causes the re-direct loopy loop! I never used to have this problem with a 5.14 install of drupal (had same issue with 6.10 so I went back ot 5.14)...I installed this patch http://drupal.org/node/241878 to fix the front-page problem, and everything in the world was peachy! but the day after, started getting the redirect-loop error in 5x too. HMm

shiver, sounds like everything you described was fixed by the http://drupal.org/node/241878 patch. The infinite redirects is something else.

I can't reproduce it, on apps.facebook.com/drupalforfacebook or any of my test apps. I believe you guys, but I need better instructions on how to reproduce this problem.

I m trying to set up a facebook app with the 6.x-2.x-dev version of the fb module.
I ve enabled following modules:
DFF Applications
DFF Connect
DFF Facebook API

When I try to view the app I get stuck in the redirect loop
http://dev.kosmospiraat.com/fb_cb/12/fb
If i m correct using this url should show http://dev.kosmospiraat.com/fb when going to the app on facebook http://apps.facebook.com/kosmospiraatdev
I used 'Set Application Properties Automatically' when creating the fb app node.

I also tried to use the connect button: http://dev.kosmospiraat.com
When I m logged in to facebook I get logged in on the site too and everything looks fine.
When I log out using de button on the site and try to log in again I also get the redirect error.
When logging in to facebook again I m connected again when going back to the site.

The patch I ve been reading about does not apply to drupal 6

Is their a solution yet for the drupal 6 version?

Hello,

I seem to be having the same issue.

Just installed the latest dev.

Created facebook app on facebook, installed fbml theme, and created a facebook app on my site. Added secret key and app id, hit save.

Now when I go to apps.facebook.com/myapp shows me this in the iframe

The page isn't redirecting properly         

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

    *   This problem can sometimes be caused by disabling or refusing to accept
          cookies.

I also tried accessing my site like this

http://www.mywebsite.com/fb_cb/23608/ and had the same

I also tried setting the application to FBML instead of iframe inside the App settings on Facebook, and then I got this

Error while loading page from appname
The URL http://www.whatever.com/fb_cb/23608/ did not respond.

There are still a few kinks Facebook and the makers of appnameare trying to iron out. We appreciate your patience as we try to fix these issues. Your problem has been logged - if it persists, please come back in a few days. Thanks!

I have all DFF modules enabled, so not sure.

Any ideas?

have you guys edited the settings.php file as instructed in README.txt?

Are you using a domain name that is visible from facebook? Nothing like 'localhost'.

If someone can tell me how to reproduce, I will try to fix. For now I'm at a loss...

Yep, I have that. Could it be perhaps some kind of interference with a module?

I will pull a list when I am at my other comp.

Breezing through now, I have modules like Boost, Path Redirect, Global Redirect, Pathauto. These could interfere with the path callbacks I guess

Aha, I think I found sg.

I disabled LoginToboggan module and my app started working.

Any of you have LoginToboggan installed?

If this only happens with logintoboggan enabled, I consider it a bug in that module, unless someone can show me otherwise.

If it happens without that module enabled, someone give me exact steps how to reproduce.

I have the redirect problem in different browsers (FF, Safari, Opera, IE) here WITHOUT USING LoginTobaggon.
I have read the readme.txt from top to bottom.
I am using newest drupal 6 and most recent fb dev.
I followed the readme.txt precisely including changes in settings.php.
I am having a drupal connect facebook application (settings as described in the readme.txt).
I use the facebook login block. I am registered but not logged in at facebook, hit the connect button enter mail and password and get the redirect error as described above.

URL is: http://localhost/np/fb_cb/4423/fb_connect/receiver?fb_login=&fname=_open...{%22session_key%22%3A%223.ZW8LlDBDtTbUwVN_i7f_Lg__.86400.1262685600-100000542624456%22%2C%22uid%22%3A100000542624456%2C%22expires%22%3A1262685600%2C%22secret%22%3A%22TwKvamgk2wU6Avp9mbTaow__%22%2C%22sig%22%3A%222d2e424d675a10c8caebf381de6529ee%22}

This error occurs both when runnign on localhost or a facebook.com visible domain.

Please let me know if you need any more info.

When I see the redirection loop, i am logged in at facebook.com but not at my drupal site.

I have set the $base_url in the settings.php to http://www.mydomain.com because some other modules (notifications) had problems without that line.

I removed the line but it does not solve the fb redirect problem :-(

I also installed the fb devel but there is no error log in at admin/reports/dblog when the redirection loop occurs

At IE 7 I just see that the login block is not showing up any more. The browse says: waiting for .../fb_cb/4423/fb_connect/receiver (where 4423 is the nid of my facebook node)

I have had this problem, but I **think** its to do with the way Facebook users are set up in your Drupal Facebook application.

I had my application set so all pages required the Facebook user to be logged into Facebook. All well and dandy.

I then thought I'll put in the Facebook Connect button on the Drupal site so that if users should happen across the Drupal site, they could use their Facebook login.

What then happens (I think but Im no expert) is Drupal connects with Facebook to login with a session ID and Facebook connects back to the Drupal site with a different session ID and they just keep batting it back and forth. Forever.

So the solution is not to have the Drupal Connect login button on your Drupal site if on the Facebook site you are requiring Facebook logins.

Well it worked for me.

PS big tx to David for excellent work on this module.

I recently ran into a problem where I couldn't get the facebook connect module to stop prompting the user for login. What happened for me was that I also had enabled facebook connect. I then set my facebook application as the primary application checkbox and had it require login. This ends up putting the facebook connect init on every page which forces the login. Even after I logged back in and disabled the primary checkbox login from the facebook application node it still kept putting the facebook connect code on every page and was prompting the user to login. I finally figured out that I had to delete the fb_connect_primary_apikey variable from the system table. After this, I was able to finally get back to a normal state. Thought I'd share in case it helped.

This patch should fix the problem ahansen1 reported. Will be checked in soon.

Index: fb_connect.module                                                        
===================================================================
--- fb_connect.module   (revision 2124)                                         
+++ fb_connect.module   (working copy)                                          
@@ -573,6 +573,10 @@
       variable_set('fb_connect_primary_apikey', $node->fb_app['apikey']);      
       drupal_set_message(t('!node is now the primary Facebook Connect applicat\
ion.', array('!node' => l($node->title, 'node/' . $node->nid))));               
     }                                                                          
+    else if ($node->fb_app['apikey'] == variable_get('fb_connect_primary_apike\
y')) {                                                                          
+      // This app was the primary one, but the user has unchecked it.          
+      variable_set('fb_connect_primary_apikey', NULL);                         
+    }                                                                          
   }                                                                            
 }       

Thanks to ahansen1 for the detailed description!

DFF calls a function of the facebook api, $fb->require_login(), when the require login option is checked. It does this both on Facebook Connect and Canvas pages. This function, in turn, calls $fb->redirect(), whether the user is logged in or not. In short, it's not safe to call $fb->require_login on Facebook Connect pages.

My fix will probably be to not support this feature on Connect pages. I'll change the text on the app edit page to indicate "require login on all canvas pages". And I will not support any option to force login to Connect pages. I doubt anyone really wants that anyway.

So, to everyone who reported this problem I ask, did you check the require_login option? If anyone can reproduce this problem without that option checked, please let me know. That would be a whole different bug requiring some other solution.

Here's the patch I'm testing. Moves control over the require_login() calls to fb_canvas.module and only applies it to canvas pages.

If you've selected the require login feature for your apps, you'll need to manually edit the settings. The update.php script can't easily do this. So just apply the patch, then edit the Facebook Application node. Select the require login setting under canvas settings, its no longer found under user settings.

lowering priority, as there is a workaround. Namely not selecting the require login feature.

Checked in the patch above. If it causes problems or does not fix the problem please let me know.

Again, visit your Facebook Application nodes and manually change the require login settings if necessary, after you update.

A thing I had done was turned off requires login in the FB application node. Then in the FBML theme I added a block to control when login was required:

$fb_app = fb_get_app(<appid>);
$fb = fb_api_init($fb_app, FB_FBU_CURRENT);
$fb->require_login();

This way require_login was only triggered on FBML pages and I could specify which pages (inclusive or exclusive) that it was triggered for.

Hello,

I have this problem with "Require authorization" set to "Allow anonymous visitors". My application details are:

Callback URL
http://vamist.ro/fb_cb/466/
Canvas Page Suffix
brokeri-forex

Canvas URL
http://apps.facebook.com/brokeri-forex

I use the latest version of the module.

If you need any other details, please tell me.

[edit]The "Net" tab from Firebug shows "301 Moved Permanently" for http://vamist.ro/fb_cb/466

Thanks.

This issue is for CONNECT pages, not canvas pages.

If you're experiencing something like this with canvas pages, please submit a new issue. Thanks.

I've also got this problem using the latest dev version of the module
I'm using drupal 6.15
I've checked "Require authorization: * Allow anonymous visitors"
and the site is stable, but if i click on either the facebook connect widget on this page, or i go to the facebook connect page and select my application for the "primary connect application" my site then just continually refreshes.
this happens to both logged in users and logged out users, in firefox and safari (on a mac) and also happens whether or not the user is currently logged into facebook.

harmonyhalo, please tell me the URL where I can see that happen. If you don't want the world to know, use my contact form here on drupal.org.

I'm having the same issue as harmonyhalo. I'll send you the link to my development box so you can see what's going on.

Hi Dave Cohen,

That code you gave above solved the problem for fb_connect.module.
Now it is working fine. You and Dries and the others who created modules for drupal ARE GENIUSES.
ARE GENIUSES.

Regards,
RainDrupalets

Hi,

The patch that should be placed in fb_connect.module , provided by Dave Cohen (module developer )solved the problem of FireFox page redirects.

Thanks a Ton.

I'm having the same problem.... not just on Firefox though. it happens on IE and Chrome as well.
Where can I get this patch?

I'm using 3.x from from today (June 24. 2010)

I'm having the same problem.... not just on Firefox though. it happens on IE and Chrome as well.
Where can I get this patch?

I'm using 3.x from from today (June 24. 2010)

Does disabling caching fix it?

Disabling caching didn't, but removing the space in the application label did (I missed the part where it says not to use spaces). Now that you mention it I should try enabling cach again and see if it breaks again. Will report back as soon as I do

since this thread is for 3.x-dev i'm surprised there is discussion about if/where require_login() is called; the new fb php sdk doesn't support this according to your fb_connect.module comments. this post refers specifically to the fb 3.x-dev package version for facebook-php-sdk-v2.0.4

dave, after getting the resizable iframe patch working in http://drupal.org/node/835954 this bug appeared. this issue appears for any user that isn't user 1. this issue appears even after making sure the fb user doesn't exist in users or authmap tables, truncating sessions table, flushing all caches, deleting the application from the fb user's application list, clearing browser cache of cookies and temporary files. this issue appears ONLY when requesting a canvas page and the user has authenticated with fb through fbconnect either at the site or at the app canvas page.

when logged in as user 1 but not into fb and attempting to delete a user that was created through fb api, the following error is returned:
Failed call to users.getInfo: Invalid API key 101. (logged into facebook as )
Exception: 101: Invalid API key

about the site and fb application:

FB API SIDE [facebook-php-sdk-v2.0.4]
options enabled: iframe, resizable, new sdks

DRUPAL SIDE [6.17]

using zen sub-theme, modified to handle iframe page resizing described at the above link. page.tpl.php file modified with xmlns:fb and FB_HiddenIFrameContainer div.

caching mode is off but only css compression is on for the performance options [ie hoses theme without css compression].

/fb_app settings:
options enabled: enabled, Set Application Properties Automatically, Register Local Users on Facebook, Primary Facebook Connect
System Default theme for canvas pages
Front Page fields are blank
Create Local Account If user has authorized the app
Map account when both local uid and Facebook id are known

/fb/fb_canvas settings: both options enabled

fb/fb_connect settings:
single fb app label selected for both Primary Connect Application and Add Button to Login Form
ALL theme overrides enabled

module packages installed+enabled are all current as of this writing [logintoboggan un/installed doesn't affect this bug's appearance]:
admin_menu-6.x-3.0-alpha4.tar.gz
captcha-6.x-2.2.tar.gz
cck-6.x-2.7.tar.gz
checkbox_validate-6.x-2.1.tar.gz
ckeditor-6.x-1.1.tar.gz
computed_field-6.x-1.0-beta3.tar.gz
currency-6.x-1.2.tar.gz
date-6.x-2.4.tar.gz
devel-6.x-1.20.tar.gz
emfield-6.x-1.20.tar.gz
fb-6.x-3.x-dev.tar.gz ***2010-Jun-23 release***
filefield-6.x-3.5.tar.gz
format_number-6.x-1.6.tar.gz
formatted_number-6.x-1.3.tar.gz
image-6.x-1.0-beta5.tar.gz
imageapi-6.x-1.8.tar.gz
imagecache-6.x-2.0-beta10.tar.gz
imagefield-6.x-3.3.tar.gz
imce-6.x-1.4.tar.gz
legal-6.x-2.2-beta4.tar.gz
logintoboggan-6.x-1.7.tar.gz
money-6.x-1.2.tar.gz
pathauto-6.x-1.3.tar.gz
phone-6.x-2.16.tar.gz
plus1-6.x-2.6.tar.gz
scheduler-6.x-1.7.tar.gz
taxonomy_menu-6.x-2.8.tar.gz
token-6.x-1.13.tar.gz
ubercart-6.x-2.2.tar.gz
views-6.x-2.11.tar.gz
votingapi-6.x-2.3.tar.gz

let me add that in settings.php, the following lines were added/modified

ini_set('arg_separator.output',     '&');
...
/**
 * Drupal for Facebook settings.
 */

if (!is_array($conf))
  $conf = array();

$conf['fb_verbose'] = TRUE; // debug output
//$conf['fb_verbose'] = 'extreme'; // for verbosity fetishists.

/**
 * Enable Drupal for Facebook.  
 * Sets up custom_url_rewrite and session handling required for 
 * canvas pages and Facebook Connect.
 */

// More effiecent connect session discovery.
$conf['fb_apikey'] = '{api key}'; // Your app's apikey goes here.

require_once "sites/all/modules/fb/fb_settings.inc";

$conf['session_inc'] = "sites/all/modules/fb/fb_session.inc";

I had this same issue and yes, disabling caching DID fix it for me.

i had the same kind of infinite loops when longing in to my site using connect on ie.
what fixed it for me is disable the developer modules. then when i enabled them again the loops didn't return?!

If this remains a problem for anyone, I suggest opening a new thread. This has already been closed and re-opened.