Extension talk:CentralAuth

Latest comment: 1 year ago by Lwangaman in topic Unknown column 'gu_hidden_level' in 'field list'

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)Reply

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)Reply
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)]Reply

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)Reply

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)Reply

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)Reply

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)Reply
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)Reply

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)Reply

Site-specific Werdna 08:36, 2 April 2008 (UTC)Reply

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)Reply

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

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. --72.198.213.23 17:27, 10 May 2008 (UTC)Reply

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)Reply
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)Reply

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)Reply

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)Reply

changing the version # at the extension data

edit

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

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.

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

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?

Backtrace:

  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)Reply

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

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)Reply

Special:MergeAccount

edit

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
System:

  • Mediawiki 1.13alpha
  • Central Auth (versjon r37422)

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

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

500'd

edit

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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

$wgDBprefix

edit

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)Reply

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)Reply

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.   12:05, 8 November 2017 (UTC)Reply

Steward can't manage and create global groups

edit

For some reason, I'm not able to create or manage global groups even though I am a member of "steward" global group which has "globalgrouppermissions" right. What am I missing?

I have followed this walkthrough and tried MediaWiki 1.33 and 1.32.3.

Lugimax (talk) 17:18, 29 July 2019 (UTC)Reply

Documentation

edit

wiki set

edit

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

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

SUL Problems

edit

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)Reply
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)Reply
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)Reply

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)Reply

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 94.249.219.9 01:26, 22 June 2009 (UTC)Reply

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)Reply
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)Reply

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)Reply

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

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)Reply

Development

edit

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)Reply

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)Reply

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

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)Reply

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

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)Reply

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)Reply
It turns out that it was a problem with my caching settings.--Jasper Deng (talk) 14:54, 24 September 2012 (UTC)Reply

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)Reply


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)Reply

Centralauth

edit

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 109.150.66.198 15:04, 22 June 2013 (UTC)Reply

CentralAuth without shell

edit

Hi,
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)Reply

yes you can. 86.173.52.65 11:22, 20 April 2014 (UTC)Reply
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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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 '=' (1.2.3.4)

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)Reply

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)Reply

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)Reply

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:

ALTER TABLE globaluser CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

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

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)Reply
For additional info, please check out bawolff's helpful message. Thanks and cheers, --Till Kraemer (talk) 21:16, 22 September 2016 (UTC)Reply

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)Reply

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)Reply

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)Reply

SQLite database

edit

How create a table in SQLite format? 2804:431:D701:3E65:7C4A:B193:9822:C8AD 13:54, 15 September 2019 (UTC)Reply

SULs are created, not “registered”!

edit

The <fieldset id="mw-centralauth-info"> thing (Global account information) contains such field as Registered:. It is, generally, misleading – SULs historically were not always created upon registration, and were not created directly within the registration process before deployment of AuthPlugin in 2018. Incnis Mrsi (talk) 09:47, 7 February 2021 (UTC)Reply

error database

edit

i Try installing Centrauth but when running the commands to merge the accounts I get this:


alAuth/maintenance/migratePass0.php

PHP Deprecated:  Use of $wgParser was deprecated in MediaWiki 1.32. [Called from require_once in /home/lapluma/laplumaazul.tk-web/htdocs/wiki/includes/Setup.php at line 838] in /home/lapluma/laplumaazul.tk-web/htdocs/wiki/includes/debug/MWDebug.php on line 376

CentralAuth migration pass 0:lapluma_azul preparing migration data...Wikimedia\Rdbms\DBConnectionError from line 1507 of /home/lapluma/laplumaazul.tk-web/htdocs/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Cannot access the database: Unknown error (sql)

#0 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(995): Wikimedia\Rdbms\LoadBalancer->reportConnectionError()

#1 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(960): Wikimedia\Rdbms\LoadBalancer->getServerConnection(0, 'lapluma_cargo', 4)

#2 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1099): Wikimedia\Rdbms\LoadBalancer->getConnection(-2, Array, 'lapluma_cargo', 4)

#3 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/extensions/CentralAuth/includes/CentralAuthUtilityServ:ice.php(110): Wikimedia\Rdbms\LoadBalancer->getConnectionRef(-2, Array, 'lapluma_cargo')

#4 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/extensions/CentralAuth/includes/CentralAuthUtils.php(36): CentralAuthUtilityService->getCentralDB()

#5 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/extensions/CentralAuth/includes/CentralAuthUser.php(900): CentralAuthUtils::getCentralDB()

#6 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/extensions/CentralAuth/maintenance/migratePass0.php(56): CentralAuthUser::storeMigrationData('lapluma_azul', Array)

#7 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/extensions/CentralAuth/maintenance/migratePass0.php(27): MigratePass0->doPassZero()

#8 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/maintenance/doMaintenance.php(112): MigratePass0->execute()

#9 /home/lapluma/laplumaazul.tk-web/htdocs/wiki/extensions/CentralAuth/maintenance/migratePass0.php(78): require_once('/home/lapluma/l...')

#10 {main} Gota de agua (talk) 03:49, 25 June 2021 (UTC)Reply

Gota de agua  I'm not an extension's dev, but the problem seems to come from your config: double-check that DB's infos (credentials, server and DBname (especially $wgCentralAuthDatabase)) are correctly set in LocalSettings.php. Raphoraph (talk) 20:49, 5 July 2021 (UTC)Reply

OpenId/keycloak integration possibilities

edit

hi all,

we've 3 MW1.36 sites (en/zh/vi), users uses AD account login thru keycloak (v9.0.3), I.e. we've managed 3 sets of MW user account in db, as more & more users contributes contents.


How to enable central auth together w/ SSO like keycloak?


thanks. Lamjon (talk) 06:27, 23 February 2022 (UTC)Reply

Can someone teach me how to install CentralAuth on MediaWiki please?

edit

Hi. I want to install CentralAuth, but i don't understand some steps. Can someone explain me in a better way, please? CJWorldGamerinQP031 (talk) 17:45, 4 November 2022 (UTC)Reply

Unknown column 'gu_hidden_level' in 'field list'

edit

Just a heads up for non-wikipedia wikis using this extension, when upgrading Mediawiki to v1.39 you will probably get another error caused by a change in the database schema for this extension. Running the maintenance update script doesn't help, because this extension isn't included in the maintenance script. You have to manually run the SQL patch, see the comments at the bottom of phabricator issue T297094 and related SQL patch. Lwangaman (talk) 23:36, 21 March 2023 (UTC)Reply

Return to "CentralAuth" page.