Extension talk:CentralAuth

From MediaWiki.org
Jump to navigation Jump to search

Installation issues[edit]

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)[edit]

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

mysql> describe globaluser;
| 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    |                |
14 rows in set (0.05 sec)

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

mysql> describe localuser;
| 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    |       |
4 rows in set (0.04 sec)
Kylu 05:33, 2 April 2008 (UTC)
mysql> describe global_group_permissions;
| Field          | Type         | Null | Key | Default | Extra |
| ggp_group      | varchar(255) | NO   | PRI | NULL    |       |
| ggp_permission | varchar(255) | NO   | PRI | NULL    |       |
2 rows in set (0.00 sec)

--Teststudent (talk) 04:22, 19 April 2012 (UTC)

User permissions?[edit]

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?[edit]

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[edit]

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. -- 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. iAlex 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. -- 17:40, 10 May 2008 (UTC)

Error in WikiMap.php section[edit]

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)

The problem may be that the configuration lines were put before rather than after the require_once ("$IP/extensions/CentralAuth/CentralAuth.php"); line in LocalSettings.php. Tisane 00:26, 29 May 2010 (UTC)

changing the version # at the extension data[edit]

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. iAlex 06:44, 26 May 2008 (UTC)

no support for $wgDBprefix?[edit]

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

should I even use it in my wikis?

thanx, Nir.

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

Tenho um problema[edit]

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?


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

Alguem pode me ajudar?

SQL error[edit]

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[edit]

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


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?


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


When i try to migrate an account on Special:MergeAccount i get the following error:
PHP Warning: array_map() [<a href='function.array-map'>function.array-map</a>]: An error occurred while invoking the map callback in C:\Inetpub\wwwroot\knowledgebase\test1\extensions\CentralAuth\SpecialMergeAccount.php on line 396

  • Mediawiki 1.13alpha
  • Central Auth (versjon r37422)

--Aroekene 13:55, 17 July 2008 (UTC)

I have this problem, too. 02:54, 4 August 2009 (UTC)
Me too. The variable $callback is holding an array, when it should hold the name of a function. --Felipe (talk) 23:57, 2 November 2013 (UTC)


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)

The same issue here. Probably gone unanswered because there are far too many variables involved that could cause this sort of thing. --Teststudent 00:01, 18 January 2012 (UTC)

Single database with prefixed tables[edit]

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)

Wow can I "Run central-auth.sql" on a shared host ?[edit]

How can I

Run central-auth.sql

on a shared host when I do not have the access to Run central-auth.sql? --Fonds 15:39, 3 September 2008 (UTC)

Try using phpmyadmin or another database tool. Techman224 02:20, 7 October 2008 (UTC)

need help with usage after installation[edit]

I've installed the extension on a wiki of mine, and use a Bureaucrat-level user-name for everything (editing, admining, etc). So, does anyone have any idea wht i get this:

Sorry, you do not have permission to access this page.

Read more about unified login…

The wiki is located here [1]. I appreciate any help i can get. Thanks in advance. Bud0011 19:14, 23 July 2009 (UTC)

Error with Special:GlobalUsers[edit]

I am getting this error: Fatal error: Cannot access private property GlobalUsersPager::$requestedGroup in /home2/rpedorg/public_html/twogrok/includes/specials/SpecialListusers.php on line 49 Any thoughts on what might be causing that? Thanks, Tisane 02:15, 29 May 2010 (UTC)

central-auth.sql error[edit]

It return

Specified key was too long; max key length is 1000 bytes

How can I fix that? --by Devunt at 07:57, 6 June 2010 (UTC)

Create DB Centralauth in a Binary mode --Андрей Краснобаев 07:21, 27 September 2010 (UTC)


CentralAuth ignore db prefixes and doesn't work. How to fix it (i can't remove prefixes)? Devwebtel (talk) 15:05, 29 December 2014 (UTC)

Several installation issues[edit]

I have several installation issues, and I have emailed them to mediawiki-l (see archive). I am posting here to encourage more people to consider helping me resolve those issues.

Thanks! Huji (talk) 00:49, 10 August 2017 (UTC)

Cache Issues, SUL, $wgCentralAuthAutoLoginWikis[edit]

On our wiki farm we have set CACHE_ACCEL and running REL1_26 of MediaWiki and CentralAuth. So far the extension can be activated without errors and I followed the documentation’s configuration, but the single user log-in into $wgCentralAuthAutoLoginWikis does not happen. Would this work also setting cache type CACHE_ACCEL? Or must it be implicitly CACHE_DB or memcache? --Andreas P. Icon External Link E-Mail.png 12:05, 8 November 2017 (UTC)


wiki set[edit]

Hi, what exactly is a wikiset? --Kjoonlee 04:36, 16 September 2008 (UTC)

It define wikis that global permissions should be applied. "Global bot" uses wiki set.--Kwj2772 08:36, 18 September 2008 (UTC)

SUL Problems[edit]


I'm having problems with SUL, it seems that SUL isn't compatible under iSafari: I'm having to log in to the wikimedia foundation sites manually as SUL isn't automatically logging me on, could the Developer's fix this problem - it works fine under Mozilla but not the Safari browser. Dark Obsidian 18:35, 11 December 2008 (UTC)
Currently you may have to change your cookie setting from "Only from sites you navigate to" to "Always" for the cross-domain session cookies to be set; otherwise you'll only be logged in within each domain (so, all *.wikipedia.org or all *.wikimedia.org or whatever, but only whichever one(s) you've logged into). --brion 22:51, 11 December 2008 (UTC)
I've tried what you've suggested and SUL seems to be working now, thanks for the help at least now I don't have to use Mozilla to use SUL. Dark Obsidian 08:51, 12 December 2008 (UTC)

Cache Issue[edit]

I am now using eAccelerator as cache. Can I use CentralAuth? Unsigned post

  • onsidering eAccellerator isn't compatible with MW 1.16+, and centralauth is still in heavy development for MW-users (mostly built from code specified for the bleeding-edge wikimedia network's framework for now) it's likely you'll run into problems. You'll probably want to update to a later version of MW and use a different accelerator anyways. --Teststudent (talk) 03:37, 19 April 2012 (UTC)

Language Setting[edit]

There should be some default language setting if I go to an new language-site so the menu is in my tongue. I have some probs to read Hebrew or Hindi ;-) So if I hadn't set preferences in that interwiki I'ld prefer to have the setting from my home-wiki. Maybe there could a new option in the home-wiki "use this language for global-account". I won't write articles in foreign languages but sometimes there are interwiki-links to set. --Hagrid@de.wikipedia.org 01:26, 22 June 2009 (UTC)

I second this. It feels annoying to have to go to Special:Preferences at every new wiki and set the language to my, for example, English. 13:27, 2 February 2010 (UTC)
Surely, some settings such as gender and interface language should be copied from the home wiki instead of resorting to local defaults. But would it wise to copy all setup? Incnis Mrsi 16:28, 30 January 2012 (UTC)

Doesn't work in Internet Explorer[edit]

This extension doesn't work in Internet Exploer (I've tested on 6th and 8th versions). This extension uses special pages, that set central cookies and return images. Problem is that Internet Explorer doesn't allow to set cookies to one site, while being on another site. For example when I login on www.mediawiki.org, then I'm not logged in on en.wikipedia.org. Everything works fine on Firefox, Google Chrome and others.

--Aik099 07:32, 19 November 2009 (UTC)

Go to Tools/Internet Options, Privacy tab. Set to Medium, and the Sites list. --Arseny1992 17:45, 8 December 2009 (UTC)

Home wiki[edit]

What is it actually but gu_home_db field in a table? There were several cases in Wikimedia where a user disbanded his SUL and recreated it only to change so named "home wiki". A tool for changing gu_home_db should exist, if not accessible by the owner himself but at least by stewards. Incnis Mrsi 16:28, 30 January 2012 (UTC)


Multi-wiki watchlist[edit]

In reference to bug 3525, should a multi-wiki watchlist be implemented by an enhancement to CentralAuth? I'm thinking that either a new field, identifying the wiki on which the page is located, will need to be added to the watchlist table, or a whole new table will need to be created to store the necessary data. If unified logins are in effect, it does seem to make sense to tie that in with this functionality. Thoughts? I don't think it's necessarily out of the question to have another extension that relies on this extension without being an integral part of it. It would be essentially an extension of an extension. Tisane 11:03, 24 May 2010 (UTC)

Step by step guide... Anyone?[edit]

Pardon me for my stupidity. But can anyone create a step by step guide to install CentralAuth? All my wikis use MediaWiki version 1.16wmf4(which all WikiMedia sites are powered by) and I don't have root access and using cPanel. Thanks Hydriz 05:23, 24 June 2010 (UTC)

Nevermind, I fixed it myself. Hydriz 16:49, 19 March 2011 (UTC)

No Global User Membership?[edit]

This is really annoying...

I finally got CentralAuth installed, and everything works except Special:GlobalGroupMembership. It just redirects to Special:UserRights. I can only set group membership through SQL queries. Everything else works - merging, creating global groups and adding permissions.

Any ideas?

Thompson.matthew 04:05, 14 October 2011 (UTC)

bugzilla:29616 Thompson.matthew 03:14, 15 October 2011 (UTC)
Fixed using development CA and 1.18wmf1. Thompson.matthew 04:06, 30 November 2011 (UTC)

Configuring SUL[edit]

I have MW 1.18.0 and the latest revision of the extension. I host my 3 wikis as subsites of a single subdomain, with the webserver being IIS 7.5. However, when I set $wgCentralAuthCookieDomain=true;, logins do not stick, indicating a problem with cookies.Jasper Deng 06:44, 14 February 2012 (UTC)

Your question is rather brief, but nonetheless, I would suggest that you enable $wgCentralAuthAutoLoginWikis. Do see the example of Wikimedia and customise it to your needs. Cheers. --Hydriz (talk) 10:56, 24 September 2012 (UTC)
It turns out that it was a problem with my caching settings.--Jasper Deng (talk) 14:54, 24 September 2012 (UTC)

CentralAuth wiki table name prefixes?[edit]

I've been trying to set up CentralAuth on a localhost test wiki, but I can't work out how to specify a wiki's database table name prefix. My DB name is 'mediawiki_test3' and the table name prefix is 'mw'. It was suggested to change the DB name to suffix a hyphen with the table name prefix, but it still goes looking for the same thing. ('mediawiki_test3.user') I would've expected it to look for 'mediawiki_test3.mwuser' (what I want to happen) or 'mediawiki_test3-mw.user' (not interpreting mw as the table prefix), but it just seems to ignore what I added completely. Anyone know how to do this? --Krenair (talkcontribs) 02:44, 11 March 2012 (UTC)

  • In my experience you can't use a prefix, sorry :( .Jasper Deng (talk) 06:22, 11 March 2012 (UTC)

  • Workaround: mysqldump your wiki databases. Create new databases with a common suffix. import the sql dumps into your new databases. Redirect your localsettings to point at the new databases you just created. Continue with your CentralAuth installation. Matt Thompson has a splendid walkthrough. --Teststudent (talk) 03:31, 19 April 2012 (UTC)

No accounts matching your name were found in the central account tracking table! The database must be corrupt.[edit]

How to solve this problem if anyone knows? --Kolega2357 (talk) 11:03, 19 June 2013 (UTC)


hi how can I add my doamins for wikis so that people who register for global account on different wikis can look at what projects they are on so for example people who are on the English Wikipedia see en.wikipedia.org for the account they are on if they go on to another wiki for example simple.wikipedia.org they see en.wikipedia.org and simple.wikipedia.org 15:04, 22 June 2013 (UTC)

CentralAuth without shell[edit]

I want to install CentralAuth on my own wiki's. But I don't have shell access - is it possible to install CentralAuth without shell? If needed, I can enable/disable cronjobs and have access to phpMyAdmin. Southparkfan (talk) 14:13, 18 February 2014 (UTC)

yes you can. 11:22, 20 April 2014 (UTC)
How? I try to do all manually or with phpMyAdmin and when I go to my wiki page i see this: A database query error has occurred. This may indicate a bug in the software. How to install CentralAuth withouth shell and when you can only use one database (for centralauth and all of wikis)? Devwebtel (talk) 17:49, 28 December 2014 (UTC)

AP rights fr.wiki not shown[edit]

I have one question. I am quite sure that the Autopatrolled flag of frwiki is not shown in the table summary. This flag is given after 500 edits and 90 days, see fr:Aide:Statuts_des_utilisateurs#Utilisateur_autopatrolled, and I saw in fact the "!" disappear in front of my edits 1-2 months ago in "Modifications récentes". So I have this flag, but it is not shown in the the table. I am sure I am not the only one.

Is that a bug?--Alexmar983 (talk) 16:55, 12 May 2015 (UTC)

No direct access from wikidata[edit]

If you try to access the Global account information interface typing Special:CentralAuth in wikidata you can't access directly as with other wikis.

You have to type the full name and then you have a contradictory statement: "There were no results matching the query." followed by "There is a page named "Special:CentralAuth" on this wiki." It takes globally 2-3 seconds more than in other platforms to access it.--Alexmar983 (talk) 11:00, 11 September 2015 (UTC)

Update outdated documentation at Extension:CentralAuth/Walkthrough[edit]

Hi please update outdated documentation at Extension:CentralAuth/Walkthrough Paladox2017 (talk) 12:00, 13 September 2015 (UTC)

Errors while installing...[edit]

Hi, I was installing CentralAuth and I tried to go to [[Special:CentralAuth/<username>]] but I got:

Exception encountered, of type "Exception"

Debugging doesn't show anything nor does Apache's error log. Any idea why? Agent Isai (talk) 00:03, 18 December 2015 (UTC)

Database error when using createLocalAccount.php[edit]

Hi, when I use createLocalAccount.php or visit https://data.domain.com/wiki/Special:CentralAuth/টিল, I'm getting the following error:

Query: SELECT gu_id,gu_name,lu_wiki,gu_salt,gu_password,gu_auth_token,gu_locked,gu_hidden,gu_registration,gu_email,gu_email_authenticated,gu_home_db,gu_cas_token FROM `globaluser` LEFT OUTER JOIN `localuser` ON ((gu_name=lu_name) AND lu_wiki = 'datawiki') WHERE gu_name = 'টিল' LIMIT 1 

Function: CentralAuthUser::loadState

Error: 1267 Illegal mix of collations (latin1_bin,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' (

I can create user টিল on my other language wikis and I also can create user Till everywhere but not টিল on datawiki.

I performed ALTER DATABASE centralauth CHARACTER SET utf8 COLLATE utf8_general_ci; as suggested here, but the second part (ALTER TABLE globaluser CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;) resulted in the following error:

ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes

Any help is more than welcome!

Thanks and cheers! --Till Kraemer (talk) 10:44, 21 September 2016 (UTC)

The first three columns of globaluser look like this:

| Field                        | Type                                  | Collation         |
| gu_id                        | int(11)                               | NULL              |
| gu_name                      | varchar(255)                          | latin1_bin        | 
| gu_enabled                   | varchar(14)                           | latin1_swedish_ci |
| gu_enabled_method            | enum('opt-in','batch','auto','admin') | latin1_swedish_ci |
| gu_home_db                   | varchar(255)                          | latin1_bin        |
| gu_email                     | varchar(255)                          | latin1_bin        |
| gu_email_authenticated       | char(14)                              | latin1_bin        |
| gu_salt                      | varchar(16)                           | latin1_bin        |
| gu_password                  | tinyblob                              | NULL              |
| gu_locked                    | tinyint(1)                            | NULL              |
| gu_hidden                    | varbinary(255)                        | NULL              |
| gu_registration              | varchar(14)                           | latin1_bin        |
| gu_password_reset_key        | tinyblob                              | NULL              |
| gu_password_reset_expiration | varchar(14)                           | latin1_bin        |
| gu_auth_token                | varbinary(32)                         | NULL              |
| gu_cas_token                 | int(10) unsigned                      | NULL              |

Do I need to change those latin1_bin and latin1_swedish_ci collations? LocalSettings.php of all wikis looks like this:

$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

Thanks and cheers! --Till Kraemer (talk) 11:18, 21 September 2016 (UTC)

Okay, I can do something like ALTER TABLE `globaluser` MODIFY `gu_home_db` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin;, but that doesn't work with gu_name. I can change the varchar length to 200 and it works, but I don't know if that's such a good idea. I can change gu_name varchar(255) to utf8_bin in a fresh centralauth database but not in the one that is already populated with users. Thanks and cheers! --Till Kraemer (talk) 14:07, 21 September 2016 (UTC)

With the help of this article, I entered:

SELECT * FROM information_schema.TABLES WHERE table_schema = 'centralauth' AND table_collation != 'utf8_bin';

...and I noticed that most of the tables use engine MyISAM.

I changed that using ALTER TABLE globaluser ENGINE=INNODB; and then I was able to do things like:


Everything works perfectly now. Thanks and cheers! --Till Kraemer (talk) 15:17, 22 September 2016 (UTC)

I had to repair some special characters by hand though. I couldn't do the exporting, editing and importing thing since it resulted in a "duplicate entry" error. Thanks and cheers! --Till Kraemer (talk) 17:39, 22 September 2016 (UTC)
For additional info, please check out bawolff's helpful message. Thanks and cheers, --Till Kraemer (talk) 21:16, 22 September 2016 (UTC)

Unknown column 'lu_local_id' in 'field list'[edit]

Hi, thanks for this great extension! However, after upgrading to MediaWiki 1.28.0, I had this problem too. Applying patch-lu_local_id.sql to the centralauth database fixed it. Cheers, --Till Kraemer (talk) 19:58, 29 November 2016 (UTC)

Cleaning up spambot accounts?[edit]

Even if you take effective measures to block spambots (identifiable through Special:AbuseLog) they still successfully fill wikis with an excess of fake user accounts. With CentralAuth is there any way to clean these up? --Rob Kam (talk) 11:01, 14 December 2017 (UTC)

Try locking the account if you have access to the lock function. Otherwise just block the user. If you have sysadmin access try Extension:BlockAndNuke since you can set up a list of legitimate users and automatically block and nuke the leftover users --Sau226 (talk) 08:55, 3 February 2018 (UTC)