I've got two sites using DFF that, modulo a couple of things, are working fine. Except on two machines running Firefox -- one's a Mac running 10.7.2 and Firefox 7.0.1, one's an older test machine running 10.5.8 and Firefox 3.6.13. Here's what happens:

I've got a Facebook Connect button on the front page. I go into the browser not logged into Facebook, and click the Connect button. I get the popup window asking me to log into Facebook, and I do so -- I'm trying to log in under an account that I created previously, in a different browser. What I see is:

* The site refreshes and shows me what I ought to be seeing if I were logged in.
* The site flashes again, and I'm logged out. Some test code shows that $user is null, and $fbu is zero.
* I'm back on the home page, with the Connect button again present. If I click it again, the same thing happens.

If I look at the server logs, here's what I've get:

192.168.0.6 - - [28/Oct/2011:10:08:03 -0700] "POST /fb/ajax/session_change HTTP/1.1" 200 4 "http://[site home page]" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
192.168.0.6 - - [28/Oct/2011:10:08:03 -0700] "GET / HTTP/1.1" 302 - "[site home page]" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
192.168.0.6 - - [28/Oct/2011:10:08:04 -0700] "GET [proper destination of logged-in user] HTTP/1.1" 200 22155 "http://[domain name]/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
192.168.0.6 - - [28/Oct/2011:10:08:04 -0700] "POST /fb/ajax/session_change HTTP/1.1" 200 4 "[proper destination of logged-in user]" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
192.168.0.6 - - [28/Oct/2011:10:08:04 -0700] "GET
" HTTP/1.1" 403 9816 "[proper destination of logged-in user]" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
(but, since I'm no longer logged in, I get a 403.)

That is, I'm for some reason getting two posts of /fb/ajax/session_change -- one works, the other does something that results in me getting logged out. The same thing happens on both of the sites I've installed DFF on, with these two browsers.

Meanwhile, the code and the login process is working fine on multiple machines under Chrome (Mac and PC), Safari (Mac), Opera (Mac), and IE 9 (PC). It also works fine on Firefox (PC), and -- wait for it -- just to be infuriating, Firefox 7.0.1 on a DIFFERENT MAC, also running 10.7.2. That's, of course, the killer. I assumed that my Mac's Firefox was unhappy for some reason, and so I've rebooted and clean-installed Firefox a couple of times. No luck; the problem persists.

I hardly expect anybody around here to debug my sites or my Firefox installation, but the fact that I'm seeing the same behavior on two sites and on two different versions of Firefox is troublesome. Does this weirdness ring a bell with anyone? Thanks very much!

CommentFileSizeAuthor
#13 fb_third_party_cookie.diff10.62 KBDave Cohen
#7 fb_third_party_cookie.diff9.86 KBDave Cohen

Comments

Dave Cohen’s picture

Dave Cohen commented

How does www.drupalforfacebook.org behave with those firefoxes? Are they configured to accept third-party cookies? Accept any cookies? Any caching on the drupal sites?

After you get mysteriously logged out, if you go to facebook.com are you then logged in or out?

jim_at_miramontes’s picture

jim_at_miramontes commented

* The same thing happens with drupalforfacebook.org -- I get logged in, but then logged out. I'll bet you'll see two posts to /fb/... in the logs.

* Firefox is set up to "accept cookies from sites", but not to accept third-party cookies, just as Chrome is.

* After all this happens, I'm still logged into Facebook in the browser.

Thanks for the help,
Jim

jim_at_miramontes’s picture

jim_at_miramontes commented

Bingo, sort of -- The Firefox that was working was set up to permit third-party cookies. I went into both problematic Firefoxes, enabled third-party cookies, and they both worked.

But my Chrome and Safari installs are both set up to block third-party cookies -- really, I checked! -- and they're both working. Does this make any sense? Is Firefox's cookie blocking more rigorous that Chrome and Safari?

jim_at_miramontes’s picture

jim_at_miramontes commented

Just to close the loop, I went into the Firefox that was originally working and disabled third-party cookies, and it stopped working (as we'd expect at this point).

Dave Cohen’s picture

Dave Cohen commented
Title: DFF not working with (some) Firefoxes » DFF not working with third-party cookies disabled in firefox.

Sigh. This has been a headache for as long as I can remember. At some point I had a tiny bit of confidence than even with third-party cookies disabled the basics would work.

There was some code in fb.module which stored facebook's session info in the drupal session. And I now think that when the oauth2 update was necessary, that code went away. I was hoping it would work without it. Possibly what has to happen is the new "signed request" will have to be stored in drupal's session and used to initialize facebook libs. PIA.

I think different browsers have a different idea of what is or isn't a third-party cookie.

jim_at_miramontes’s picture

jim_at_miramontes commented

Sigh, indeed.

On the off-chance that you haven't tried it, Windows Firefox behaves the same way. No surprise, but confirmation is always a good thing.

Dave Cohen’s picture

Dave Cohen commented
Status: Active » Needs review
StatusFileSize
new fb_third_party_cookie.diff9.86 KB

Here's a patch I'm currently testing. Would appreciate testing and feedback.

Dave Cohen’s picture

Dave Cohen commented

Facebook has a time-honored tradition of paying no attention to bug reports. I don't expect this one to be any exception.

But if this issue is important to you please add a comment there: http://developers.facebook.com/bugs/173032012783482?browse=search_4eb81f...

jim_at_miramontes’s picture

jim_at_miramontes commented

I downloaded the patch in #7 and seem to have installed it without problem (on top of 6.x-3.x-dev). It's better, but I'm still having problems:

* In the case where I'm trying to log in as a user who has a Drupal account, it works correctly: The FB authentication happens, I get logged into FB, and am properly redirected within the site to where logged-in users are supposed to go.

* In the case where I'm trying to log in as a user who does NOT already have a Drupal account, there are problems:

1: The FB authentication happens, I get logged into FB, and my site gets the /fb/ajax/session_change post. But things then stop -- the user should get redirected to a Drupal-ish registration page to collect more details, and that doesn't happen. I suppose this could be something in my code, but the site is working correctly in other browsers.

2: If I refresh the page, I'm taken to my Drupal-ish reg page, which is sorta kinda the right thing. It's seeing the FB connection, and returns a correct FB ID for that user (fb_facebook_user()). However, if I log out of FB in that browser, my site refuses to forget that FB ID -- as I refresh the page, it is clearly getting the old value for fb_facebook_user(), who is now logged out. I can log into FB as another user, and it still has the old value for the FB ID. This is very persistent -- I have to clear cache and cookies and restart Apache to get it back to thinking that it doesn't have somebody logged in. (Not all of those clearing steps may be necessary; I could track it down further if it were helpful.)

Again, the site is working correctly in other browsers. I could track down the weirdness in case #2, but I thought I'd just report this back first in case it was informative. If you want more details, I can dig into it more.

Thanks for looking into this,
Jim

jim_at_miramontes’s picture

jim_at_miramontes commented

Done (#8, that is).

jim_at_miramontes’s picture

jim_at_miramontes commented

A bit of followup regarding #9 above:

* In case 2, clearing the browser cookies is enough to get my site back to the state where no user appears to be logged into Facebook.

* I get the same behavior with "accept third-party cookies" turned on and off in Firefox.

* I am getting the same behavior with Chrome, case 2 (page not refreshing after the POST, and fb uid not clearing) in particular.

I'm going to back off to 6.x-3.x-dev for now, but please post if you have a new version you'd like me to test.

jim_at_miramontes’s picture

jim_at_miramontes commented

Arggh. I suck (at least at QA). After backing out to 3.x-dev, I am now certain that I'm getting the "doesn't refresh after the POST" thing with 3.x-dev as well as the patched version. Sorry; the offer to test (more effectively, I hope) new versions still goes.

Dave Cohen’s picture

Dave Cohen commented
StatusFileSize
new fb_third_party_cookie.diff10.62 KB

Thanks for comments. Try this updated patch, which I believe will detect when the user has logged out. Unfortunately, it adds some overhead to each page to test that the connection is still valid. (Overhead on the client side, should not slow the server or page render)

As far as I know, there's no test to determine whether third party cookies are disabled. Even with them disabled, the cookie is set for a short time, so detecting it's presence or absence is not enough. I suppose the code could check whether the browser is firefox and only try this workaround in that case.

What this patch does is store the facebook tokens in the drupal session, and pass them on every page to the javascript. The javascript will work, mostly, but some calls like FB.getLoginStatus() fail, because facebook's platform is so weak. So this updated patch uses FB.api() to determine whether the user is still logged in.

I consider this more a workaround to facebook's bugs than the right way to do things.

jim_at_miramontes’s picture

jim_at_miramontes commented

Re patch 13: Sorry, but it's still not working for me (with 3rd party cookies disabled). I'm back to the original problem: When a Drupal user tries to log in, I get a brief view of their appropriate destination, but then the page refreshes again and the user is logged out.

With 3rd party cookies allowed, the "drupal user exists" case works correctly, but the "no user" case fails to refresh after login.

jim_at_miramontes’s picture

jim_at_miramontes commented
Title: DFF not working with third-party cookies disabled in firefox. » DFF not working with third-party cookies disabled in firefox -- now Chrome, as well?

Bump / new information: under 6.x-3.1 and Chrome 17.0.963.46 (released Feb 8, 2012, dff is no longer working when third-party cookies are disabled. Unless somebody snuck into my computer and changed my preference settings in the last couple of days :), this is a new thing. Third-party cookies must be enabled for my login process, which works fine in Safari and Firefox, to succeed.

I know I should be running the latest-and-greatest-dev version, but I've kinda been waiting for the smoke to clear in a couple of areas. Perhaps it's fixed there. In any case, dff and Firefox were known to have third-party cookie issues at various points along the way, and I wanted to send up a flag that Chrome may have joined the club. Arggh.

Dave Cohen’s picture

Dave Cohen commented

Huh. Facebook's official stance is third party cookies need to be enabled, which I find kind of insane.

I'd be interested to know if you have the problem with the latest code. Also with www.drupalforfacebook.org. I haven't noticed this problem yet.

jim_at_miramontes’s picture

jim_at_miramontes commented

When I disabled third-party cookies in Chrome (Mac; v. 17.0.963.56) and tried to log into dff.org at http://www.drupalforfacebook.org/node/7/dff_tour/identity, I got an error box with "An error occurred with Drupal F acebook. Please try again later." when I clicked on "click the connect buton to authorize". When I re-enabled third-party cookies and tried the page again, I got text on the page -- "Click the connect button to authorize." -- but not the Facebook button. This remained the case even after clearing the browser cache and restarting Chrome. Weird.

jim_at_miramontes’s picture

jim_at_miramontes commented

I've just moved to the 2/15/2012 dev version of fb, and I can't get logged in when third-party cookies are blocked in Chrome (Mac, 17.0.963.56) and Firefox (Mac 10.0.2). No problems with Safari (5.1.3 (7534.53.10)).

BTW, is this recent frenzy with Google allegedly finding ways around third-party cookies in Safari related to what you're doing here? If Safari tightens up its act here, are we going to get bit?

Dave Cohen’s picture

Dave Cohen commented
Status: Needs review » Active

My earlier patch is committed. Flagging this as active, because I still don't think all browsers work when third-party cookies are disabled, as comments indicate. I haven't tested the whole array of browsers lately.

(I think the true "fix" for this will come in a future version 4.x of this module, which does not rely on facebook cookies in any way.)

jim_at_miramontes’s picture

jim_at_miramontes commented

My quick and clearly incomplete survey of the situation, using the latest browser versions available as of today (June 22), where "fails" means "login doesn't work with third-party cookies blocked":

Mac:
Safari 5.1.7: Works
Firefox 13.0.1: Fails
Chrome 19.0.1084.56: Fails

Windows:
IE 9.0.8112.16421: Works
Firefox 13.0.1: Fails
Chrome 19.0.1084.56 m: Fails
Safari 5.1.7: Works

I haven't tried things like allowing third-party cookies, getting logged in, and then disabling them to try other things, since I can't imagine any real user actually doing that.

The good news, I guess, is that Safari is (I think) the only browser whose default setting is to block third-party cookies and DFF works there, and most users tend not to change their browser settings. With complete appreciation for what you've already done here(!), is there any hope of a fix/workaround/hack for this short of a 4.0 rewrite? The restrictions above map out a pretty large chunk of the browser space, and who knows what will happen to default settings in the future. I doubt that my php/js/drupal-fu is up to yours, but I've been working with Drupal for close to 5 years and know a thing or two, and am willing to help out if I could be helpful in some way.

Dave Cohen’s picture

Dave Cohen commented

Thanks for that list. It's such a pain to test multiple browsers X multiple settings. It adds up.

I assume you were using the modules/fb default settings for those tests. You could try checking "Use tokens in session to initialize javascript" as that is perhaps the settings most geared toward not caring whether there's a cookie or not.

jim_at_miramontes’s picture

jim_at_miramontes commented

I enabled "Use tokens in session to initialize javascript", and the results from my previous survey are unchanged -- Chrome and Firefox are still failing when third-party cookies are blocked.

jim_at_miramontes’s picture

jim_at_miramontes commented
Issue summary: View changes

domain name removed for anti-indexing purposes...