Extension talk:Facebook

Public FAQ for Extension:FBConnect

When commenting, please include the reversion of FBConnect that you are currently using.

Base domain not valid domain
Hi, I just installed this and everything seems to work, however when I try and log in with my facebook account I get an error saying " please set your Connect URL in the application settings editor. " I tried to type our home URL into the field (in a variety of ways I.E. with http://, without, with a / at the end, and without..etc) but I keep getting an error that says "base domain is not a valid domain". 13:06, 23 April 2010 (UTC)
 * This isn't the best place to post this, you should hit up Facebook for support on their end. Regardless, do you the mean applications settings editor at http://www.facebook.com/developers/editapp.php? Make sure the "Base Domain" field is correct. Here is how my settings look:
 * Connect URL: http://www.trianglebruins.com/
 * Base Domain: trianglebruins.com
 * Edit: I just came across this: http://github.com/facebook/php-sdk/commit/078887046dc15aa1d1149e1e2a52de6b0694c646. If it is a problem with the PHP SDK, then it'll need to be updated to the most recent version. Keep an eye on this extension's SourceForge updates (mirrored here). Gbruin 19:32, 23 April 2010 (UTC)

Thanks a lot we got it working.

I have one other question, when we click "log out of facebook" it doesn't do anything. Our developer said the code is simply missing. Is this suppose to work?11:56, 24 April 2010 (UTC)

Path and cross-domain issues...
...are now a thing of the past! For details, see Extension:FBConnect.

Essentially, I migrated over to the new Facebook Connect JavaScript SDK (announced here) and the callback URL no longer needs to be specified ($fbCallbackUrl has been completely removed). If you are still receiving similar issues, they need to be reported to the GitHub tracker.

- Gbruin 07:53, 14 April 2010 (UTC)

MediaWiki 1.12
Hi everybody,

Is there a way to use this extension with v1.12 ? I really like this plugin and it would be great to be able to use it on previous versions of MediaWiki =)

--Marineam 16:37, 20 April 2009 (UTC)


 * Unfortunately, right now there is not. I started developing this extension on MW 1.14alpha and recently resumed development for 1.16.0beta1 wikis. However, I have included a significant amount of backwards compatibility code and research in the source if anyone wants to pick up the torch for legacy users. If you have PHP programming experience, I encourage you to give this a try =) Gbruin 22:55, 28 March 2010 (UTC)

Conflicts with other extensions
I noticed a conflict with the FCKeditor extension. Apparently the FCKeditor also uses the UserLoadFromSession hook. However, since the FBConnect extension registers with the hooks only after all the setup for the other extensions has been complete, the other extensions may have already loaded the user object by the time this extension registers its UserLoadFromSession handler. This results in the FBConnectHooks::UserLoadFromSession method never being run and the FB user from not getting authenticated.

I'm not sure if this is the best work-around, but it seems to do the trick. One potential risk is that the other extensions may initially load a different user as the FB user would not have been set up yet. If possible, this extension should load the user earlier in the setup process.

Here's my hack, in FBConnect.php: public static function init { global $wgXhtmlNamespaces, $wgAuth, $wgHooks;

...		// Install all public static functions in class FBConnectHooks as MediaWiki hooks $hooks = self::enumMethods('FBConnectHooks'); foreach( $hooks as $hookName ) { $wgHooks[$hookName][] = "FBConnectHooks::$hookName"; }		// HACK // Other extensions may have already loaded the user. Start the process over. global $wgUser; if ($wgUser->mDataLoaded) { $wgUser->clearInstanceCache ('session'); }		// END HACK // ParserFirstCallInit was introduced in modern (1.12+) MW versions so as to		// avoid unstubbing $wgParser on setHook too early, as per r35980 if (!defined( 'MW_SUPPORTS_PARSERFIRSTCALLINIT' )) { Mreall 23:08, 30 June 2009 (UTC)

Mreall, it works very well. I've included all your hacks, Thanks a lot for your work. profetes --86.171.130.44 22:40, 9 July 2009 (UTC)

LDAP conflicts
I have the LDAP extension setup to be used alongside the local accounts. When i enable FBconnect the domain drop down disappears. Is this easy to address?


 * In short, no. I re-wrote the extension, and believe the new version to be more pluggable in nature. Keep an eye on the head of the SVN and let me know if it looks like this becoming more possible. Gbruin 23:19, 28 March 2010 (UTC)

Using this connection in an wikifarm setup
Hi there,

does anyone tried to use this extension in an wikifarm setup? I'd like to use it and would share the extension across all my wikis. And another question: How is the progress on the missing features from the Extensionpage? --Marcus Stöhr 13:21, 26 July 2009 (UTC)

Does Mouseover Tooltips collide with Navigation Popups?
Anyone have an issue with Gadget:Navigation Popups being incompatible with this FBConnect feature? --76.216.200.201 03:26, 14 March 2010 (UTC)


 * These tooltips have been removed in the current version due to an architectural change in my extension. Moreover, if there is ever a need to re-implement them, it will be done using jQuery and hopefully won't conflict with your Gadget:Navigation Popus anymore. Gbruin 22:59, 28 March 2010 (UTC)

undefined method OutputPage::addInlineStyle
After fresh install on MediaWiki 1.15.2 I immediately receive "Call to undefined method OutputPage::addInlineStyle in FBConnectHooks.php on line 114". Any ideas? SeanFromIT 14:19, 1 April 2010 (UTC)
 * This function was added in r53282 on 7/14/09. If you can tell me the highest version missing this function (probably 1.15.2) then I'll write the workaround code. Gbruin 00:58, 4 April 2010 (UTC)
 * I fixed this in SVN, but I don't have a 1.15.2 wiki so I'm unable to test. Do you still receive this problem? Gbruin 01:35, 4 April 2010 (UTC)
 * In 1.15.2 it still errors because the Html class isn't in v1.15 either ;) -SColombo 02:01, 8 April 2010 (UTC)
 * *facepalm* haha should work now Gbruin 18:23, 8 April 2010 (UTC)

Signatures
Would it be possible in the next version to have the real name (or nick name) be used for the signatures? Because, right now, when you are facebook connected and use the ~ to place a signature, you get the 9 facebook id digits. This is not really meaningful. Fredd-E 10:50, 21 May 2009 (UTC)

Problems setting up: does not create new user
I am not sure what I am doing wrong. It all seems to work but when I log into facebook through the pop up window it doesnt create a new user and nothing changes. Then when I go to the Special Pages: Connect there is the option of logging out from facebook connect but I am still not logged into the mediawiki. --86.24.193.46 12:16, 26 June 2009 (UTC)

Problems with using an account prefix
I found a couple bugs when using an account prefix. My accounts weren't being created or when they were I wasn't being automatically signed in to them. The problem lies in a couple methods that should call FBConnectAPI::idFromName on the the ID before passing it to Facebook:

In FBConnectAPI.php, I commented out the original code and added in the fix: public function getRealName( $user ) { // HACK //$name = $this->getFields( $user->getName, array( 'name' )); $name = $this->getFields( $this->idFromName($user->getName), array( 'name' )); return $name[0]['name']; }	public function isConnected { global $wgUser; // Hack //return $wgUser->isLoggedIn && $this->isIdValid( $wgUser->getName ); return $wgUser->isLoggedIn && $this->isIdValid( $this->idFromName($wgUser->getName) ); } Mreall 13:38, 30 June 2009 (UTC)

Usernames
I was wondering how it could be implemented a solution to change the usernames of the facebooks users from numbers to names. Also, when I log in as administrator not-facebook user, I cannot see the names or numbers of facebook users on the user list. profetes --86.171.94.53 10:34, 24 July 2009 (UTC)
 * Seconded on this. Especially since you auth to Facebook (user-facing) with your e-mail - makes sense to store the e-mail in the profile (not currently done), auth with that, then maybe let the user set/pick a "user-friendly" Wiki name? e.g. Or maybe auto-set it to the "user" part of their e-mail (before "@"), and then just run it through the "check duplicate usernames" which is already implemented? --User:Dforester 8-Aug-2009


 * Both great ideas. Unfortunately, until recently Facebook wouldn't give out your email address, only a proxied email that looked like apps+2247576871.6549491.a8f9c147347345bd2d9e9aa57dd93ade@proxymail.facebook.com. Also unfortunate is that letting the user pick a "user-friendly" Wiki name is really the way to go, but would call for a complete re-write of the entire extension from the ground up. Now for the fortunate part: that's what I used by spring break for. The new architecture suggests a few usernames, but ultimately lets the Facebook Connect user choose their own the first time they connect. This should solve the username problems you two are having. Gbruin 23:17, 28 March 2010 (UTC)

Problem with 64bit Facebook UID numbers for server with only 32bit PHP
New Facebook accounts now have a much longer UID (64bit). With those accounts this extension does not work (new users are not created). This does not happens if your PHP handle 64bit (to check it see ). A workaround is to use float ... see, as I did, so:

(btw, I've before used the above patch by Mgrell: thank you Mgrell!)

A quick (and dirty) solution is: in config.php set

$fbUserName = '';

and in FBConnectAPI.php:

public function isIdValid( $id ) { ...               //HACK //return 0 < $id && $id < hexdec( 'FFFFFFFFFFFFFFFF' ); return 1 == 1; // I guess you can just have "return true", or "return 0 < $id" }

and, once again in FBConnectAPI.php

public function idFromName( $username ) { ...                       // HACK // return intval( $username ); return sprintf ( "%.0f", floatval( $username )); ...

--Oriettaxx 12:00, 13 October 2009 (UTC)

FB registered users can only preview but not save
I've installed this extension, it works (the xd_receiver only in IE), but when a user is logged on Facebook and tries to save a page, it always previews it. Wiki registered users work perfectly, only problem is with FBConnected users.

--Fulgen 10:54, 7 January 2010 (UTC)

Tries to create duplicate accounts
1User name conflict found: "XXXXXXXXXXX". Rename offending user or set $fbUserName = true.

Cannot enable it. I also deleted old account, merging it with another one. But after connecting once it doesn't understand the account already exists and tries to crete it again.

--Mrrux 21:43, 7 January 2010 (UTC)


 * Tracking down bugs like these would would have been a pain so I used my spring break to completely re-write the extension from the ground up. Account names are now chosen by the user and I removed the configuration parameter completely. This should eliminate the bug... if not, I would like to hear about it. Thanks! Gbruin 23:05, 28 March 2010 (UTC)

Don't FB authenticate if you're already signed in
When you are already signed in to the wiki under a local wiki account and don't want the system to automatically sign you out of the local account and into your FB account, add the following code:

In FBConnectHooks.php, UserLoadFromSession method (just the HACK section): static function UserLoadFromSession( $user, &$result ) { global $wgAuth, $wgUser; // HACK: don't do anything if the user is already signed in from the session. global $wgCookiePrefix; if ($user->mFrom == 'session' && isset($_COOKIE["{$wgCookiePrefix}UserID"])) { return true; }		// END HACK // Check to see if we have a connection with Facebook if ( !FBConnect::$api->user ) {

and in fbconnect.js addOnloadHook(facebook_onload_addFBConnectButtons); addOnloadHook(facebook_add_user_tooltips); addOnloadHook(facebook_init);

// HACK if (!wgUserName) { addOnloadHook(facebook_onload); } //END HACK Mreall 13:41, 30 June 2009 (UTC)

Special:UserLogin Vulnerability
First off, thanks for starting this extension.

I am not sure if this is isolated to my wiki. But once $fbAllowOldAccounts = true; in config.php, on Special:UserLogin if you enter any registered member's user name without entering a password and press login, this automatically logs you into the users account without any validation.

Could some one try this on there installation and let me know if its just my setup or its a bug withing this extension.

I'm running MediaWiki 	1.14.0

--69.41.102.224 19:42, 9 May 2009 (UTC)
 * Thanks for mentioning this. I'm running the same MediaWiki version 1.14.0 and you're absolutely right about the bug. This is a huge security issue. I've disabled FBConnect on my wiki for now until the developer gets active again. Fredd-E 10:43, 21 May 2009 (UTC)

--96.20.202.45 01:37, 2 June 2009 (UTC)
 * The script is producing the same security issue for me.


 * The problem is that "FBConnect::$api->idFromName( $username )" returns "0" for registered wiki member's and "FBConnect::$api->user" returns "null" when using local (wiki) authentication. First we should verify that we have a FB ID (see sample below):

FBConnectAuthPlugin.php: 56: public function authenticate( $username, $password = '' ) { 57:   $id = FBConnect::$api->idFromName( $username ); 58:   $user = FBConnect::$api->user; 59:   return $id > 0 && $id == $user; 60: } Mreall 22:30, 24 June 2009 (UTC)

SSO Not Working
Using Mediawiki 1.14, the extension loads fine, and on the Special:Connect page, I can log in and out of Facebook. However, upon clicking "Connect with Facebook" on, say, the Main Page. The pop-up appears, and I log in to Facebook. The Main Page is then reloaded, but I am not logged in, and no account was created. The "Log in" and "Connect With Facebook" links are still present. Additionally, there are no PHP errors, so I am at a loss to troubleshoot this extension. Any tips on troubleshooting this would be greatly appreciated. --John Thomson 03:06, 13 June 2009 (UTC)


 * Just as an update, Mreall's solution regarding the FCK conflict resolved the SSO issue for me. THANKS! --John Thomson 23:06, 22 August 2009 (UTC)

- Something similar happens to me. If I try to "facebook connect" in the main page as a logged off user, it just reloads the main page. --86.24.193.46 11:35, 21 June 2009 (UTC)

Loss of Session Data?
My fb-users can not save any edits. Logging out then in yields no improvements. From what I can tell. FBConnect is otherwise working as expected. Anyone else seen this?

'''Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in. '''

I have disabled Captcha and FCK to no avail...non-FB users have no issues.

TIA --John Thomson 23:05, 22 August 2009 (UTC)


 * Problem seems to have solved itself...must have been a conflict or other config issue. I just turned it on for the first time since this post, and now it works.   --John Thomson 02:22, 4 March 2010 (UTC)

Wrong, the problem is back, but now I can reproduce it:


 * 1) If enabled, disable the extension.
 * 2) Visit any page of the wiki, confirm you are not logged in as a FBConnect user
 * 3) Enable the extension
 * 4) Visit any page, verify you are logged in as your FBConnect user
 * 5) Edit any page, this ought to work.
 * 6) "Facebook Logout" of the wiki
 * 7) Log in through Facebook again.
 * 8) Edit any page, and you will get the Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in.  error
 * 9) Argh.

--John Thomson 03:13, 4 March 2010 (UTC)

Shows the Special:UserLogout page upon connecting with FBConnect
For some reason, when I login to my wiki via FBConnect, I am brought to the logout page. It still works - if I navigate away from the page, I'll find myself logged in under my Facebook account. This is hardly ideal, though - any thoughts on what might be wrong? I've tried applying some of mreall's hacks, but they don't seem to have addressed this issue. --218.186.8.236 17:38, 24 January 2010 (UTC)


 * Over my spring break I managed to completely re-write this extension and redo the underlying architecture. Hopefully this is no longer the case, but if so I would like to hear about it. Thanks! Gbruin 23:01, 28 March 2010 (UTC)