Posted by gallamine on October 29, 2009 at 1:28am
Jump to:
| Project: | Drupal for Facebook |
| Version: | 6.x-3.x-dev |
| Component: | Facebook Connect |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I tried to link a drupal account to a FB account and I get the following warning message displayed:
user warning: Duplicate entry 'bce7de40db7a05d7325d903fe433c9ef-4294967295' for key 1 query: INSERT INTO fb_user_app (apikey, fbu, added, session_key, session_key_expires, time_access, uid, proxied_email, time_cron) VALUES ('bce7de40db7a05d7325d903fe433c9ef', 100000448786826, 1, '', 0, 1256777685, 3, 'apps+61838263958.100000448786826.bc81be1f73441eeb217bc847b129e7fa@proxymail.facebook.com', 0) in /home/admin/domains/robotbox.net/public_html/test/sites/all/modules/fb/fb_user.module on line 98When this error occurs, the "F| Connect" button never changes, and also stops working (ie doesn't open a popup). I've tried linking the same FB account to two different Drupal accounts and I get the same error. I've tried deleting the entry in the fb_user_app table, but I still get the same error.
Comments
#1
Update:
I just tried connecting to FB (a different FB account than above) with an account that isn't associated with any Drupal users, and I get the same error:
user warning: Duplicate entry 'bce7de40db7a05d7325d903fe433c9ef-4294967295' for key 1 query: INSERT INTO fb_user_app (apikey, fbu, added, session_key, session_key_expires, time_access, uid, proxied_email, time_cron) VALUES ('bce7de40db7a05d7325d903fe433c9ef', 100000433877009, 1, '', 0, 1256780835, 0, 'apps+61838263958.100000433877009.7e2949323caa9e419ceacb0ceec78169@proxymail.facebook.com', 0) in /home/admin/domains/robotbox.net/public_html/test/sites/all/modules/fb/fb_user.module on line 98.#2
Same here.
#3
I get these constantly in the app that I run as well. The issue appears to be that it's trying to insert when $uid = 0. My guess is this is not an expected scenario and there is some root issue at play. For the time being I've updated fb_user.module with the following:
...if ($result && !db_affected_rows()) {
// The row for this user was never inserted, or deleted. Insert now.
$fbu = fb_facebook_user($fb);
if ($fbu && $uid != 0) {
...
#4
There is a unique key on the table, which should not be there. The unique contraint should be the apikey and facebook user id, not the drupal user id. Should be an easy fix, but I haven't generated a patch yet.
Once, I thought the uid=0 scenario was a problem, but it's not. The modules need to support it.
#5
To gallamine and Carlos,
Please get to a sql prompt and type 'describe fb_user_app;' What do you see for the fbu column? It should be a bigint.
If it's not, check the update.php script. Under 'select versions', which versions would run for fb_user module? Update 6004 is supposed to make that field a big int. If that update has already run, and that field is not a big int, that's the problem. I'm not sure why that would be the case, though.
#6
Dave,
I went ahead and altered my table so that it would accept the 0 uid for the auth mapping. But, I have just discovered this could cause other issues...at least in my custom code. I wasn't previously expecting fb_get_fbu to return a user for the anonymous account. Now it returns the last person to have been associated with it. Won't this cause issues elsewhere? Should fb_get_fbu be updated to not return when the uid passed is 0?
#7
ahansen1, probably right that fb_get_fbu should not return an fbu for anonymous user. However I don't understand how the behavior has changed. Before this patch, there could have been one entry in the fb_user_app table with uid==0. The difference now is that there could be more than one. And the fb_user_app table is not even consulted when fb_get_fbu() is called!
So if fb_get_fbu() is doing the wrong thing, please submit an issue with details of how to reproduce.
#8
The bug originally described above is caused by the fb_user_app.fbu field not being large enough to store facebook's new longer user ids. I attempted to fix this long ago, in fb_user_update_6004(). So I have to ask those of you reporting the problem, have you run update.php????
And I recommend to everyone, add this line to mysql's my.cnf. It will help catch problems like this right away. You may be surprised that this sort of problem occurs in many places!
Add to my.cnf:
# make it strict http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.htmlsql-mode=TRADITIONAL
#9
Automatically closed -- issue fixed for 2 weeks with no activity.