Extension talk:CentralAuth

= Installation issues =

Does anyone got this extension running in a prefixed environment? I try to setup CentralAuth using only one database with 3 different prefixes for 3 different MediaWiki installations. After creating the appropriate tables using central-auth.sql, including the CentralAuth.php in LocalSettings.php, I only get errors when trying to use Special:CentralAuth or when pointing to my settings.

Do I have to adjust some other settings first or is it just not useable yet?`--Marcus Stöhr 11:53, 29 March 2008 (UTC)


 * CentralAuth is currently running on Wikimedia sites (including Wikinews, Wikipedia, etc) for sysops, who are being used as guinea pigs. At the moment, we have 1,472 CentralAuth users. I think Wikia uses the same system, but am not in a position to check this at the moment. Kylu 13:45, 29 March 2008 (UTC)


 * Yeah, I know. I've been following the postings on the mailinglist. But I'd like to test in my own environment. At the moment, I'm "sharing" users by using VIEWS over the user tables. But it's a pain in the a** if you are doing upgrades. --Marcus Stöhr 10:46, 30 March 2008 (UTC)]

Wikia has always used a shared user table, which has been in the core for years and years. Werdna 08:39, 2 April 2008 (UTC)
 * What does Shared Table means in this specific context? Using a VIEW or using another technique? --Marcus Stöhr

After some research, I got it working to fetch the correct database (custom one) for the CentralAuth-tables. This should be easier to modify/customize. Another issue is the usage of prefixed databases to have multiple wikis in one database, as I stated above. The plugin should load the information about the current wikisetting from the LocalSettings.php from the wiki it is executed from. Should this be classified as a bug in the bug tracker? --Marcus Stöhr 06:55, 7 April 2008 (UTC)


 * Note: The above (success) is contradicted the statement on Stöhr's user page, dated 11 April 2008. Anybody had success with CentralAuth when using a single db with table prefixes? --Vigilius 21:45, 28 July 2008 (UTC)

table describes (reference)
mysql> describe globalnames; +-+--+--+-+-+---+ +-+--+--+-+-+---+ +-+--+--+-+-+---+ 1 row in set (4.42 sec)
 * Field  | Type         | Null | Key | Default | Extra |
 * gn_name | varchar(255) | NO  | PRI |         |       |

mysql> describe globaluser; +--+---+--+-+-++ +--+---+--+-+-++ +--+---+--+-+-++ 14 rows in set (0.05 sec)
 * Field                       | Type                                  | Null | Key | Default | Extra          |
 * gu_id                       | int(11)                               | NO   | PRI | NULL    | auto_increment |
 * gu_name                     | varchar(255)                          | YES  | UNI | NULL    |                |
 * gu_enabled                  | varchar(14)                           | NO   |     |         |                |
 * gu_enabled_method           | enum('opt-in','batch','auto','admin') | YES  |     | NULL    |                |
 * gu_home_db                  | varchar(255)                          | YES  |     | NULL    |                |
 * gu_email                    | varchar(255)                          | YES  | MUL | NULL    |                |
 * gu_email_authenticated      | char(14)                              | YES  |     | NULL    |                |
 * gu_salt                     | varchar(16)                           | YES  |     | NULL    |                |
 * gu_password                 | tinyblob                              | YES  |     | NULL    |                |
 * gu_locked                   | tinyint(1)                            | NO   |     | 0       |                |
 * gu_hidden                   | tinyint(1)                            | NO   |     | 0       |                |
 * gu_registration             | varchar(14)                           | YES  |     | NULL    |                |
 * gu_password_reset_key       | tinyblob                              | YES  |     | NULL    |                |
 * gu_password_reset_expiration | varchar(14)                          | YES  |     | NULL    |                |

mysql> describe localnames; +---+--+--+-+-+---+ +---+--+--+-+-+---+ +---+--+--+-+-+---+ 2 rows in set (0.13 sec)
 * Field    | Type         | Null | Key | Default | Extra |
 * ln_dbname | varchar(32) | NO   | PRI |         |       |
 * ln_name  | varchar(255) | NO   | PRI |         |       |

mysql> describe localuser; +---+-+--+-+-+---+ +---+-+--+-+-+---+ +---+-+--+-+-+---+ 4 rows in set (0.04 sec)
 * Field                | Type                                                            | Null | Key | Default | Extra |
 * lu_dbname            | varchar(32)                                                     | NO   | PRI |         |       |
 * lu_name              | varchar(255)                                                    | NO   | PRI |         |       |
 * lu_attached_timestamp | varchar(14)                                                    | YES  |     | NULL    |       |
 * lu_attached_method   | enum('primary','empty','mail','password','admin','new','login') | YES  |     | NULL    |       |


 * Kylu 05:33, 2 April 2008 (UTC)

User permissions?
Is a sysop on one site a sysop on all sites, or does the CentralAuth preserve site specific ops? --Dmb 06:13, 2 April 2008 (UTC)
 * Site-specific Werdna 08:36, 2 April 2008 (UTC)

GlobalUsage-Extension needed?
I've tested the latest SVN-version of CentralAuth and got an error message:

Fatal error: Call to undefined function wfGetLB in /home/MYDIR/extensions/CentralAuth/CentralAuthUser.php on line 27

After a little googling, I came up with the GlobalUsage-Extensions, which doesn't seem to work. The error still remains, even if I include the GlobalUsage.php BEFORE CentralAuth.php in LocalSettings.php. Does this extension, CentralAuth, only works with the latest trunk-build of MediaWiki or is there another thing I've overlooked? --Marcus Stöhr 21:38, 6 April 2008 (UTC)


 * Nevermind, fixed it by testing with latest trunk. --Marcus Stöhr 22:33, 6 April 2008 (UTC)

Getting the same error message on May 9th
I'm getting the same error message of Fatal error: Call to undefined function wfgetlb in /home/MYDIR/extensions/CentralAuth/CentralAuthUser.php on line 65

Line 65 is the 3rd line in this code:
 * public static function getCentralDB {
 * global $wgCentralAuthDatabase;
 * return wfGetLB( $wgCentralAuthDatabase )->getConnection( DB_MASTER, array,
 * $wgCentralAuthDatabase );
 * }

I was using the latest version of the CentralAuth files from the SVN downloaded on May 9th. Any ideas of what to do next? I'm using Mediawiki 1.12 and wondering if I have to upgrade to the current version of 1.13 being used on Wikipedia and related WMF sites. --72.198.213.23 17:27, 10 May 2008 (UTC)
 * Actual code of CentralAuth requires 1.13. Use can use the code from the 1.12 branch wich should work with 1.12. i Alex  17:34, 10 May 2008 (UTC)
 * Thanks for the quick reply. I'll either upgrade the wiki to Mediawiki 1.13 or will use the 1.12 version of CentralAuth. --72.198.213.23 17:40, 10 May 2008 (UTC)

Error in WikiMap.php section
I am using the May 10th version of Central Auth with the May 10th version of Mediawiki 1.13 and have installed the CentralAuth extension on this test wiki. The problem I have run into is this code in SpecialMergeAccount.php: function foreignUserLink( $dbname ) { $wiki = WikiMap::byDatabase( $dbname ); if( !$wiki ) { throw new MWException( "no wiki for $dbname" ); } WikiMap.php is returning NULL and this generates the "no wiki for $dbname" error message. The problematic part of WikiMap.php is the statement list( $major, $minor ) = $wgConf->siteFromDB( $dbname ) that is in the code below: class WikiMap { static function byDatabase( $dbname ) { global $wgConf, $IP; static $initialiseSettingsDone = false; // This is a damn dirty hack ... {5 minor lines omitted)  		list( $major, $minor ) = $wgConf->siteFromDB( $dbname ); 				if( isset( $major ) ) { 			$server = $wgConf->get( 'wgServer', $dbname, $major, array( 'lang' => $minor, 'site' => $major ) ); 			$path = $wgConf->get( 'wgArticlePath', $dbname, $major, array( 'lang' => $minor, 'site' => $major ) ); 			return new WikiReference( $major, $minor, $server, $path ); 		} else { 			return null; Since my wiki set-up only consists of three sites, I presume that I can probably just comment out the call to WikiMap in SpecialMergeAccount.php and add a statement like $wiki = 'ignatian_en';. However, I tried about ten variations of what I thought $wiki should be (e.g., en, http://en.ignatianwiki.org, ignatian_en, etc.) and none worked.  The current wiki site structure we have is: I was able to add a new test account on the English wiki and it added that account (User:Workmantest4) to the English and the Global user tables.  On the English user preferences page it says for Global account status: "All in order! Your account is active on 1 project site."  However, when I select "Manage your global account", I get the error messages above. I'm planning to manually merge accounts (or let users merge accounts) as we have only 80 English, 25 commons, and 10 Spanish accounts. I would appreciate any advice on a value to set for $wiki (or other workarounds) to the problem I'm having in the code above.--Workman 02:51, 13 May 2008 (UTC)
 * English - http://en.ignatianwiki.org
 * Spanish - http://es.ignatianwiki.org
 * Commons - http://commons.ignatianwiki.org

changing the version # at the extension data
hey, Maybe it would be better if the information on the working branch of CentralAuth for earlier versions of mediawiki will be noted at the main page there it says that CentralAuth is for mediawiki 1.11+, but it's really just for 1.13. perhaps a new download section should say where to get the earlier versions of CentralAuth

I didn't want to do it myself because I don't want to step on any toes :) thanx, Nir.
 * Done. i Alex  06:44, 26 May 2008 (UTC)

no support for $wgDBprefix?
is it just me or that there is no support for $wgDBprefix?

should I even use it in my wikis?

thanx, Nir.

--77.124.100.125 23:12, 26 May 2008 (UTC)

Tenho um problema
Instalei essa extensao porem a mesma apresenta o seguinte erro ao tentar unificar o login:

LoadBalancer::reuseConnection: connection not found, has the connection been freed already?

Backtrace:


 * 0 C:\www\wiki\meta\w\extensions\CentralAuth\CentralAuthUser.php(1201): LoadBalancer->reuseConnection(Object(DatabaseMysql))
 * 1 C:\www\wiki\meta\w\extensions\CentralAuth\CentralAuthUser.php(1179): CentralAuthUser->importLocalNames
 * 2 C:\www\wiki\meta\w\extensions\CentralAuth\CentralAuthUser.php(1109): CentralAuthUser->lazyImportLocalNames
 * 3 C:\www\wiki\meta\w\extensions\CentralAuth\CentralAuthUser.php(1314): CentralAuthUser->listUnattached
 * 4 C:\www\wiki\meta\w\extensions\CentralAuth\CentralAuthUser.php(608): CentralAuthUser->queryUnattached
 * 5 C:\www\wiki\meta\w\extensions\CentralAuth\SpecialMergeAccount.php(169): CentralAuthUser->migrationDryRun(Array, false, Array, Array, Array)
 * 6 C:\www\wiki\meta\w\extensions\CentralAuth\SpecialMergeAccount.php(56): SpecialMergeAccount->doDryRunMerge
 * 7 C:\www\wiki\meta\w\includes\SpecialPage.php(533): SpecialMergeAccount->execute(NULL)
 * 8 C:\www\wiki\meta\w\includes\Wiki.php(224): SpecialPage::executePath(Object(Title))
 * 9 C:\www\wiki\meta\w\includes\Wiki.php(55): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 1) 10 C:\www\wiki\meta\w\index.php(92): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
 * 2) 11 {main}

Alguem pode me ajudar?

SQL error
I encounter this SQL error: SELECT user_id,user_email,user_email_authenticated,user_password,user_editcount FROM `user` WHERE user_name = 'User123' LIMIT 1

in function „CentralAuthUser::localUserData“. MySQL error „1054: Unknown column 'user_editcount' in 'field list' (localhost)“.

MediaWiki 1.13 (r37557) PHP 5.2.1 (apache2handler) MySQL 5.0.37 Windows XP

Any idea how to solve it and what's wrong? --Valac 14:17, 11 July 2008 (UTC)

share users in multiples wikis
which are the steps to complete to installation?
 * 1) I download CentralAuth extension
 * 2) Add this extension on my LocalSettings.php
 * 3) run central-auth.sql
 * 4) run the scripts

i posted this

http://www.mwusers.com/forums/showthread.php?t=8340&page=2

i have a problems

no show me the new special pages:


 * 1) Special:AutoLogin (unlisted special page)
 * 2) Special:CentralAuth
 * 3) Special:GlobalGroupMembership
 * 4) Special:GlobalGroupPermissions
 * 5) Special:GlobalUsers

show me the message: the special page dont exist

i have problem to unified login?

when i visit special:MergeAccount showme the page, but after which is the step?

is possible automatized unified logins?

which is the better to do it?

so, how to register a new account, i can login in all wikis, within visit special:MergeAccount

this is possible?

thanks

--200.77.227.68 17:13, 23 July 2008 (UTC)

Spesial:MergeAccount
When i try to migrate an account on Spesial:MergeAccount i get the following error: PHP Warning: array_map [function.array-map]: An error occurred while invoking the map callback in C:\Inetpub\wwwroot\knowledgebase\test1\extensions\CentralAuth\SpecialMergeAccount.php on line 396 System: --Aroekene 13:55, 17 July 2008 (UTC)
 * Mediawiki 1.13alpha
 * Central Auth (versjon r37422)

500'd
When I try to access Special:MergeAccount on my 1.12 wiki, I get a HTTP 500 error. Dagoth Ur, Mad God 03:07, 27 July 2008 (UTC)

Single database with prefixed tables
Is it correct, that no-one has managed to get this extension to work in a setup where multiple wikis share a single mysql database and are distinguished by prefixes? If so, this should be clearly stated on the extension page itself. I am getting desparate. Marcus Stöhr above raised similar questions and on his discussion page it is stated that he did not get it working either. --Vigilius 19:54, 28 July 2008 (UTC)

Cannot get this to work... fully
I got it working with accounts being merged, but can't get Special:GlobalGroupPermissions to work properly... anyone know of a fix for this?? I'm using the latest SVN build of MediaWiki. --82.42.237.84 22:11, 25 August 2008 (UTC)