Extension talk:CentralAuth

#REDIRECT = 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
 * The problem may be that the configuration lines were put before rather than after the  line in LocalSettings.php. Tisane 00:26, 29 May 2010 (UTC)

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)


 * I have this problem, too. 99.233.30.223 02:54, 4 August 2009 (UTC)

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)

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
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 ?
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
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. I appreciate any help i can get. Thanks in advance. Bud0011 19:14, 23 July 2009 (UTC)

Error with Special:GlobalUsers
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
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)

= Documentation =

wiki set
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
Hi,


 * 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
I am now using eAccelerator as cache. Can I use CentralAuth? Unsigned post

Language Setting
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 94.249.219.9 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. 145.97.65.62 13:27, 2 February 2010 (UTC)

Doesn't work in Internet Explorer
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)

=Development=

Multi-wiki watchlist
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?
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?
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)
 * 29616 Thompson.matthew 03:14, 15 October 2011 (UTC)
 * Fixed using development CA and 1.18wmf1. Thompson.matthew 04:06, 30 November 2011 (UTC)