Sometimes when a user signs up for my app, a duplicate entry is created in the user table, and D for FB just appends a "_2" to the end of the username. It does not look like the duplicate accounts are ever accessed because all activity is logged under the first account.

Last Access = Never

Any idea why that might be happening?

Thanks,

Ntrepid8

CommentFileSizeAuthor
#6 fb_user_login_11272010.patch1.39 KBjghyde

Comments

Dave Cohen’s picture

I'm not certain what would cause this, but one idea...

are you using the fb_connect login block? If so, have you customized the markup and is there an "onclick" or "onlogin" attribute? Try deleting that attribute, and letting the module's default ajax handle the login. I think there might be a race condition where the browser is both making an ajax call and reloading the page.

ntrepid8’s picture

Ok. I was using a custom button, with the "onlogin" attribute. Will the page still reload when the button is clicked without triggering it directly?

thx

Ntrepid8

jghyde’s picture

This appears to only happen on canvas pages. Everything works fine on the FB connect-enabled Web site.

joe

jghyde’s picture

Additional accounts for the same Facebook uid happens on canvas pages when the canvas pages expose the drupal for facebook login block with the <fb:login-button> tag. Not a bug, but possibly an instruction (-;

ntrepid8’s picture

I followed dave's advice in post #1 and it resolved the issue for me. Just have to let the AJAX work it's magic, and not create a race condition.

jghyde’s picture

Version: 6.x-3.0-beta3 » 6.x-3.x-dev
Status: Active » Needs review
StatusFileSize
new1.39 KB

Under certain conditions, I can replicate the duplicate user account problem on the fb connect Web site. I added this conditional to actually have a uid before making a select in fb_user.module function _fb_user_get_uid($fbu, $fb_app = NULL) function. This seems to have fixed the problem for me. Not sure if it opens any cans or worms elsewhere. Please test. Patched against HEAD.

Dave Cohen’s picture

Status: Needs review » Active

That patch in #6 is not right. That function should return work the same whether the $fbu passed in belongs to the current user or not.

I also don't see how it would prevent this problem.

Have you checked your fb:login-button markup to see whether it has an onclick or onlogin button?

I think a real fix for this would be to create a semaphore, so even with the race condition two accounts are not created. I'm not sure exactly how to do that.

GkaouPiou’s picture

I have the same problem and I'm not using the Facebook login block.
I'm using the alter form and the only way not to create a duplicate account is to disable the automatic account creation.
I'm also using this code from the recipies. to redirect user after login:
Redirect after connect

Thank you in advance for your help.

notluap’s picture

I have this issue occasionally as well, but sometimes up to 100 duplicate accounts have been created. All have last access = Never and the Facebook info from the registered user is not displayed on their drupal user page.

audiocollective’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Component: Code » Facebook Connect
Priority: Normal » Major

I am getting the same issue! it is very frustrating. Any update on how to fix this?

ariedels’s picture

We are having the same issue from time to time, and I wonder if it is an issue of user#1 getting through, having their ######@facebook username getting replaced with their actual email (fetched from FB). Then, of course, seconds later on a fb.user forced refresh, a dupe is not caught as normal user validate checks aren't catching it and a new user is created again with the #######@facebook username (and then possibly changed again when details fetched from FB!).

Dave Cohen’s picture

It is the fb_user table, and not the username, that associates a facebook user id to a drupal user id. So I'd be interested to know what's in the fb_user table for those duplicate accounts.

And I'm not sure what's changing the username for you. modules/fb does not change the ####@facebook to something else just because it learns the email. If you have some other module doing something like that, I suggest disabling it and seeing if the duplicate problem goes away.

laboratory.mike’s picture

I believe this issue is related with http://drupal.org/node/1117214 , from my database, an user account will be kept when created by Facebook login, then the account mapping will be deleted from dr_fb_user (entry simply doesn't exist anymore). But, if I manually plug the entry back in the connection will be restored.

Dave Cohen’s picture

Thanks for the reference to the other issue. I suspect they are related. That reports a PHP warning and this is far more serious.

If I understand the problem correctly, a temporary workaround is to give all users permission to "Delete own fb_user authmap". Then a user editing their own username/password should never accidently delete them from fb_user table.

Dave Cohen’s picture

Status: Active » Needs review

Normally I would mark this other thread as a duplicate of this one, because this is the more severe bug. However there's some room to doubt the actual cause of this problem. So please refer the patch in #1117214: Notice: Undefined index: map in fb_user_user_update() and test. And let me know if you still see new duplicate account with the patch applied. Thanks.

Dave Cohen’s picture

Status: Needs review » Closed (duplicate)

I'm confident the fix to #1117214: Notice: Undefined index: map in fb_user_user_update() also fixes this. However if I am wrong, please re-open this issue.

tunic’s picture

Issue summary: View changes

I'm having duplicated users with fb 7.x-3.4 release. I want to get more information about this before reopen this issue. At the moment I'm unable to reproduce the duplication of users, but I've have plenty of users with accounts duplicated, one connected to Facebook while the other is not connected.

Fix from #1117214: Notice: Undefined index: map in fb_user_user_update() is included, it was commited a few releases ago.