I have a normal user account on my Drupal site, with the login name admin, and has a role called "administrator". I tried out facebook connect and got the account linked to a test facebook account.
Today, however, when I tried to log in with my usual credentials, i.e. username admin, the account actually showed up as 1691221788@facebook.com, and it only had the authenticated user role! I verified that that is actually my facebook ID.
Since I set the connect block to only show up for administrators while I beta test my site, I had no way of undoing the wrong association and actually had to disable all facebook modules manually in the rpsystem database. But that's hardly the point. Why did it suddenly decide to ignore the link between my admin account and create a new bogus account?
I'm using Drupal 5 with the patch for rewriting the front page, and the latest version of Drupal for Facebook.
Comments
Comment #1
Dave Cohen commentedOk clearly it should not do this. But I'm confused as to exactly what happens and when. If it happened when you logged in via connect, then you should no longer be able to log in as 'admin'. Are you sure it did not create a new account? Go to admin/users to verify.
does the username end with '@facebook' or '@facebook.com'?
It's possible there's a bug in 5.x that I haven't run into. Because mostly I'm working on 6.x now.
Comment #2
laddiebuck commentedI had previously linked my admin account, after I had logged in, with my facebook account by clicking the facebook connect button.
Connect is only enabled for administrators via the block settings, which restrict the block to people of role 'administrator. (My goal for the module is initially just to link existing accounts with facebook accounts.) Hence I logged in by entering my username and password. I entered 'admin' and its corresponding password, I obviously authenticated as admin at some point because an incorrect password would just result in a failed login, and after that, without a new page load, simply before I could see any sign of my real user account being loaded, I become not admin but 1691221788@facebook.com. user/me redirects to a different UID, I don't have an adminmenu, etc.
The only thing I can recall doing in the meanwhile is having logged out of facebook.com, and restarting my browser a couple of times (which usually forces me to log in to Drupal again).
If it's any help, I just tried to run through the same steps that I described to you, but with a different result, which I think is also a bug. I logged in on Facebook and Drupal, linked my account with Connect, logged out of Facebook manually, logged out of Drupal, logged in to Drupal, and at this point I was logged in correctly, but a strange thing happened. The facebook block showed 'Facebook Logout', then it reloaded and showed simply 'Facebook', then it logged me out of Drupal! This is probably a bug on it's own, but I'm afraid I haven't been able to get a reproduce.
Comment #3
Dave Cohen commentedI'm not sure I understand, but it sounds like bug is "fb_user creates a new account instead of linking the existing account, when using facebook connect". That is, it left your admin account untouched, but created a new user, correct?
What do you have selected on the Facebook Application for user options?
What do you get from database query
SELECT * FROM authmap?Comment #4
laddiebuck commentedThat's right. The subtletly is just that this happens not when I click Connect, but sometime afterwards, under conditions I am unsure of, after I simply log in. What's more, before the page (and hence the Connect block) is even loaded.
Right now because of the bug I disabled the DFF User Management module entirely (that is to say, I disabled them all manually in the database, and only re-enabled Connect and its dependencies). If you like, I can re-enable it and see what the user settings were.
There are some non-facebook entries in my authmap table from a different authentication tie-in I wrote a while ago, so I omit those entries. Right now, we have (outer joining with the user table):
| 32 | 99667 | 1758752948@facebook.com | fb_user | 1758752948@facebook.com |
| 33 | 42 | 847710246@facebook.com | user | zoran |
| 34 | 45747 | 10742404@facebook.com | user | beenen34 |
| 36 | 110660 | 1691221788@facebook.com | fb_user | 1691221788@facebook.com |
| 37 | 111295 | 1087253281@facebook.com | fb_user | 1087253281@facebook.com |
| 38 | 111296 | 780174664@facebook.com | fb_user | 780174664@facebook.com |
| 39 | 111297 | 716568654@facebook.com | fb_user | 716568654@facebook.com |
| 40 | 111298 | 1570836691@facebook.com | fb_user | 1570836691@facebook.com |
The ones with names are my colleagues. I am not there at all (my uid is 1), yet my Facebook Connect block says "facebook Logout"!
Comment #5
laddiebuck commentedI wonder if you have any idea what's causing this. DFF Connect seems very unstable for me -- it drops the 'connection' very often!
In any case, at this point I think I'll try out the Facebook Connect module and see if it's better.
Comment #6
socialnicheguru commentedThis happened to me. I logged in as user 1.
It was deleted.
http://drupal.org/node/481120
There are still issues even after I disabled everything.
This was on D6.
Edit:
I just noticed a weird thing.
My admin account is admin@mysite.com
My user account is user@mysite.com
I used fbconnect to connect admin@mysite.com to test it
and I also did it for user@mysite.com
Now when I log into user@mysite.com, I am taken to the drupal account and uid for admin@mysite.com
I also noticed that I had fb_infinite_session on. When I turned it off, the two accounts were no longer linked.
When should fb_infinite_session be used?
Chris
Comment #7
Dave Cohen commentedfb_infinite_session used to be a lot more useful than it is now. Some of the facebook API require a session, like for example the api to register a feed template. (At least it did last time I checked) So if you configure an infinite session, it will be used when admins create new feeds. This is useful when you're using neither facebook connect nor canvas pages. Most people will not need fb_infinite_session.
Regarding the rest of this issue, I belive possibly the fb_user module is doing something wrong with authmaps, although I have not encountered this. I don't believe any of the modules are deleting any accounts ever.
If you guys could tell me exactly how to reproduce either problem it would help.
Comment #8
socialnicheguru commentedhttp://drupal.org/node/481120#comment-1660818
Comment #9
laddiebuck commentedI'm afraid I've done all I could to try to reproduce the issue. For now, I've simply switched to the Facebook Connect module. Since Drupal for Facebook has a much broader scope, all I had to do was to tweak some settings in my Facebook Application and I had it set up. In the last few days it's been fairly stable. Coming as it does without a block, the page load isn't affected so much as with Drupal for Facebook's connect block.
Comment #10
giorgio79 commentedI just experienced this.
When I clicked on the FB connect button while logged in as admin, it switched me to my FB User and created a plain user record in users and fb_user_app table.
The username was like 2348293472934@facebook (without.com) in the users table
I was simply able to logout, and log back in as admin.
(no user was deleted)
Should I try deleting 2348293472934@facebook user and relogin with FB connect? I think this user was created by an earlier version of FB Connect.
Comment #11
Dave Cohen commentedYou should be able to tell how old the 2348293472934@facebook account is.
What DFF does depends in part on how you configure the Facebook App node. By default it will link a local account if you're already logged in, or create a local account if you're not. However in your case where there is already a local account, but you're logged in as someone else, I'm not certain what it will do. The behavior you describe sounds reasonable to me. It certainly cannot map BOTH accounts to the same facebook user id.
This is all controlled by the authmap table. So if you want to break the association between a local account and a facebook account, you can delete a row in that table. Or delete the entire user. Either way should work.
Setting this bug to fixed, as I believe the original 5.x issue is fixed. And the 6.x behavior you describe does not sound like a bug. Am I wrong?