Unnecessary(?) "fbu" GET param on redirect busting our caching.

sub

It is intended to fix caching problems.

For example if your cached page shows a facebook connect button, but after the user connects you want to show their name and profile pic... well, you don't want the cached page. For most sites, being connected to facebook is like being logged into drupal, and caching is not desirable.

It's true that carefully built sites may still want caching on these pages. I'm open to configuration option that prevents the fbu from being appended, as long as the default is to append the fbu. I'll review any patches that do that.

That patch is easier to read, for sure. I haven't looked it over in detail yet. I'm a little worried about the approach, as it removes the URL parameter but still reloads. In your case, the reload hits the cache, there's really no reason to do it. And also I'm not sure why, if the reload comes from the cache, you are not starting an infinite series of reloads. Because in the theory the page should also be served as if the user is not logged into facebook, and the javascript learns that the user is logged in, it should try to reload.

I agree there are cases where a full page reload is not necessary. Here's what I would recommend as a workaround. Create your own module, let's call it custom.module and have that module call drupal_add_js() to load custom.js. In custom.js define Drupal.behaviors.custom something like this...

Custom.sessionChangeHandler = function(context, status) {
  // Here, we can act when the user logs into or out of facebook.
};

Drupal.behaviors.custom = function(context) {
  jQuery(document).unbind('fb_session_change'); // Unbind the default behavior.
  jQuery(document).bind('fb_session_change', Custom.sessionChangeHandler); // Bind our custom behavior.
};

This will completely replace modules/fb handling of the session change with Custom.sessionChangeHandler(), which in the example above does nothing.

So, I recently learned that appending the user id to the url is a Bad Thing. I'm planning to get some change in the next release. Probably some combination of this patch and also change exactly what gets appended to the URL, maybe a hash of the id.

I wish I could remember exactly the problem I solved with this. Probably one of those situations where third-party cookies are disabled.

Ok, here's the patch I'm planning to test on drupalforfacebook.org.

Instead of appending the user's ID, it will append a hash value.

Instead of enabled by default, it will be disabled. Its ugly, both the code and what it does to the URLs. So I hope eventually to get rid of this entirely. But there was a reason to add it in the first place so let's see whether anyone encounters problems without it.

Thanks again for your help with the original patch submission.

I did check this in. Re-open if still an issue.

It seems to be working on my installation. I am releasing it on my users today due to #1225830: Email from Facebook, "Action Required for app" and will see what happens.