Hello,

I usually get this notice for anonymous users, browsing the site on apps.facebook.com without having connected to the site.
You can see it in action here http://apps.facebook.com/proofreadbot
Any tips?
Notice: Undefined variable: _SESSION in Facebook->clearPersistentData() (line 79 of /sites/all/libraries/facebook-php-sdk/src/facebook.php).

Comments

giorgio79’s picture

Component: I am lazy and not paying attention » Canvas Pages (iframe)
gianfrasoft’s picture

subscribe

Alex Savin’s picture

subscribe

wisniewski’s picture

subscribe

scott shipman’s picture

Title: Notice: Undefined variable: _SESSION in Facebook->clearPersistentData() (line 79 of /sites/all/libraries/facebook-php-sdk... » Notice: Undefined variable: _SESSION & indefinate Loop error.
Issue tags: +indefinate loop, +_session
StatusFileSize
new18.73 KB
new16.41 KB
new17.91 KB

Sorry for the long msg, but its a lot of debug info for you: I get the error:

Notice: Undefined variable: _SESSION in Facebook->clearPersistentData() (line 79 of /sites/all/libraries/facebook-php-sdk/src/facebook.php).

when a user is not logged into facebook or the drupal app. But only in IE 8 and IE 9. Safari, Chrome and Firefox all work OK.

BUT, when I visit the apps.facebook.com/[appname] page as a logged in user to facebook, but not the application, I get the indefinate loop. Only in IE 8 and IE 9. All other browsers seem ok. I have read the forums / bug discussions on indefinate loop and presumed it was closed. I havent applied the changes to the canvas module to add the !empty portion yet.

I followed the readme txt file correctly to install. I have allowed the application in facebook. I synch settings automatically on save of DFF settings.

I have enabled these modules:
Facebook API (7.x-3.x-dev), FB Apps, FB Connect, FB Canvas Pages, FB Dev Tools, FB User Mgmt, FB Views, FB Extended Perms, FB Registration

I clicked the checkbox to match accts by email and when both UIDs are present. All 3 session setting checkboxes are clicked. Both Canvas Page settings are checked. And I use User Friendly names.

My FB devel info is attached for 3 scenarios. No other logs in my PHP or Drupal error logs.

scott shipman’s picture

I may or may not have fixed this by adding this line to my settings.php:
header('p3p: CP="NOI ADM DEV PSAi COM NAV OUR OTR STP IND DEM"');

replacing the line from the readme.txt ("- Also for canvas pages, see http://drupal.org/node/933994 and search
for "P3P" to avoid a common problem on IE.")
header('P3P: CP="CAO PSA OUR"');

see: http://stackoverflow.com/questions/4467326/facebook-app-works-on-all-bro... and http://www.p3pwriter.com/LRN_111.asp for info about these new p3p values.

After this change, my FBdevel Info using IE8 or IE9 matches in the Session and Cookies areas to that of other Browsers.

scott shipman’s picture

OK, new update...I still get the infinite loop issue, and I made it happen in Safari too.

Dave Cohen’s picture

Here's what apps.facebook.com/drupalforfacebook has at the end of it's settings.php...

// Header so that IE will accept cookies on canvas pages.                                                                                                 
if (!headers_sent()) {
  header('P3P: CP="We do not have a P3P policy."');
}

The error that this thread is about is in facebook's php library, not modules/fb code. I personally have yet to run into it.

Are the PHP error and infinite loop related? Or is this issue about two separate things?

jherencia’s picture

@Dave, the reason because this fails is:
fb_canvas on hook_exit run fb_canvas_redirect($app_destination) that executes exit(), see:

function fb_canvas_redirect($url) {
  echo "<script type=\"text/javascript\">\ntop.location.href = \"$url\";\n</script>";
  exit;
}

which don't let other modules to run hook_exit and worse, it prevents drupal_exit from saving the session:

function drupal_exit($destination = NULL) {
  if (drupal_get_bootstrap_phase() == DRUPAL_BOOTSTRAP_FULL) {
    if (!defined('MAINTENANCE_MODE') || MAINTENANCE_MODE != 'update') {
      module_invoke_all('exit', $destination);
    }
    drupal_session_commit();
  }
  exit;
}

The case I encounter this, was when another facebook user enter in a current session of other FB user, which deletes the session, creates a new one and redirects the user to the current path.

The problem is that the session is not saved, due to the problem explained above, so $_SESSION has no value.

I have different aproaches:

  1. To run drupal_session_commit(); before exit(), which I don't like, because it's not elegant
  2. To implement module_implements_alter to make fb_canvas the last module to run hook_exit and then it is not needed to run exit(). I don't know for sure if this will work, but in any case it would be much better to implement that hook in any case to let other modules to run hook_exit.

@Dave this was what I wanted to tell you in IRC, because I think it is needed to implement a better behaviour than "exit()", and wanted to know more of the current flow to see if I can provide another aproach.

Dave Cohen’s picture

Yeah, fb_canvas module does some ugly stuff on hook_exit. I think the code you're referring to was ugly but harmless in Drupal 6.x. But what you point out is breaking sessions in 7.x. In an ideal world, we wouldn't have to do anything there, but since canvas pages are iframes, we are trying to change the URL of the top frame, not just the iframe. When the top frame is correct, facebook will send an up-to-date signed_request.

I would try replacing the call to fb_canvas_redirect() with just a call to echo the <script...>. That way exit() would not be called and it might just work. I wonder which module implements hook_exit() and is responsible for doing something with the $destination?

gianfrasoft’s picture

Any standard solution...?

fdambrosio’s picture

same problem

Dave Cohen’s picture

Status: Active » Needs review
StatusFileSize
new994 bytes

@jherencia, if I understand you correctly, this patch which uses hook_module_implements_alter might have an effect.

Do you happen to know which of your modules are also implementing hook_exit and their order? I'd like to reproduce consistently. I'm attaching a patch based on your idea but I havent' tested at all.

Dave Cohen’s picture

Status: Needs review » Fixed

Committed the patch. Hopefully fixed.

Status: Fixed » Closed (fixed)

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

avpaderno’s picture

Issue summary: View changes
Issue tags: -indefinate loop, -_session