Topic on Project:Support desk/Flow

I would like to create a global login for the various Sturmkrieg wikis, which will include wikis for each language, and for different gaming related topics. I already have been running the English fanfic/player content wiki for some time now, where as the other wikis generally only have a single admin user account. (de.sturmkrieg.com has a few I believe.) With that, it seems that it would be better to use shared tables, and just stop using the old accounts on the other wikis. The problem though, is that the main English Sturmkrieg has several blocked spammer and troll accounts on it, that I would prefer no have access to the other wikis. I think there's something like 12 or 15 spammers and at least 20 troll accounts. The latter appear to all be the same person, based on Check User and Lookup User information. It would be very time consuming to block them on every wiki and simply changing their email and passwords to prevent them from logging in would be tedious as well.

We also use ConfirmAccount, so I'd like to make sure that will work with CentralAuth

Also, I need to make sure that user renaming would be able to work with the CentralAuth. Would renaming the user on all wikis be an easy way to make sure that the user maintains global login under one account without having any additional action on their part?

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

If you aren't using $wgDBprefix on any of those wikis, I'd recommend CentralAuth since it works best in that situation. ConfirmAccount does have issues with CentralAuth though.

However, using a shared database prefix is not easy either given that you already have user tables for all of those wikis.

I think the DB prefix is the same for them, if that helps.

Is there anyone who would know how to get ConfirmAccount working with CentralAuth?

It would be good because it eliminates spam accounts (most spammers don't even submit requests at all) and would prevent duplicate accounts, even by non malicious users (who may, for example, create them instead of using the reset password email) or by the same guy who already trolled the site, and made racist comments about "[blond space Germans] would be eagerly awaited on Valhalla (a fictional Red Army based world) for this." He also ran an account under the disguise of a writing instructor for several months until Lookup User revealed it was fake. (He also never specified who he was actually working for) I would prefer not to have to be checking everyone's stats to make sure they're legitimate.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

ConfirmAccount does have its issues with CentralAuth, but I'd defer to a developer of either extension.

CentralAuth should work fine with db prefix.

Shared tables is generally better if you're doing them from the get go. Central auth is better if you started with multiple wikis and want to merge. (I know nothing about confirmaccount, so cannot comment on that).

Yeah, but I try to avoid using $wgDBprefix with CentralAuth because my view is that CentralAuth is more likely to run into trouble when not on a WMF-style installation with no $wgDBprefix.

Yeah, I'd recommend CentralAuth - it's difficult, and make sure you do some small-scale testing first.

Oh, and by the way, a stopgap solution to account locking before you can get CentralAuth would be my home-made solution.

Thanks. Is this to address the problem of the troll accounts editing the other wikis? I assume this would need to be a global user group?

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Yeah, that's a given both if you want to use CentralAuth or a shared DB.

I wouldn't advice to use CentralAuth if you don't need to use different user tables. Only share user and user_properties tables, set $wgCookieDomain = '.sturmkrieg.com'; and if you want to use global user groups, install GlobalUserGroups extension. I've also coded a small extension to apply global blocks to users, too. I could prepare and send it you. Global helppages are possible by HelpCommons.

1. Well, he already has separate user tables so that's the scenario for CentralAuth; he's going to apply this to an existing wiki farm with many wikis, each with their own local user table that not necessarily are all the same.
2. Hey, the WMF would have really nice use for that extension!

Jasper, the WMF has GlobalBlocking extension for IP addresses and for loggedin users they block the global account of CentralAuth. I didn't read everything, I'm sometimes lazy as you should know.

I mean, there should be a replacement to just locking global accounts.

Most of the wikis only have a single user on them. Is CentralAuth still better in that case?

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

If that user is the same on all of them and you have only one large user table, then you may want to use shared tables. However, if you have more than just two large user tables, then CentralAuth is the better choice.

Would it be possible to use ConfirmAccount with shared tables? I only have one account on most of the other Sturmkrieg wikis, and I think the German Sturmkrieg might have three, but the users there could reregister.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

It can work if you use a shared user table. I don't know how does it work with CentralAuth. For the first variant, you can set the following:

$wgSharedTables[] = 'account_requests';
$wgSharedTables[] = 'account_credentials';

Thanks. How would rename user be affected by this? Would the renaming need to be done on the wiki that has the tables, or would any wiki be able to change the username? (they all have access to the same tables for users anyway)

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

ConfirmAccount should work OK with CentralAuth, especially if you disable the creation of global accounts by default (as on my wikis). RenameUser may be affected in terms of logging of the changes, so I'd probably restrict renaming to bureaucrats on your main wiki (the one used by $wgSharedDB(prefix)).

I wasn't planning on using CentralAuth, since there's only one large user table. Would the RenameUser still be alright in that case?

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

No, it wouldn't work. You can use ReassignEdits extension to reassign edits from an old user to a new one. It's also possible to use Renameuser for one wiki only. For the other wikis, you would still have to use ReassignEdits to reassign the user's edits on the other wikis, too. Therefore, creating a new account and using ReassignEdits extension is probably easier.

Would it be possible to rename the user on every wiki?

It wouldn't be much different with the ability to reassign the edits to new accounts.

While I could create the new account myself, I feel that it would undermine the sockpuppet policy.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

If you are using a shared user table, you automatically rename an user with Renameuser in this database and in the wiki's revision et cetera tables. But the edits get not transferred on the other wikis. Therefore, the easiest way is using Renameuser on your main wiki and for the other wikis use ReassignEdits to transfer the user's edits on these wikis, too.

I might just stick with separate accounts. It probably won't be a big deal anyway. Although renaming users probably won't be a big issue anyway.

I might still make a block user group for use by sysadmin to have a block option that only they control.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Though I found CentralAuth to be quite easy for me, as long as I used trunk versions. Though the ability to lock accounts is very handy for me, even locally (see my implementation, link on my userpage).

I told you the solution for renaming user accounts globally. For global blocks, you can create a global user group with GlobalUserGroups extension revoking some permissions by $wgRevokePermissions variable. Don't forget to define $wgLocalDatabases.

require_once( "$IP/extensions/GlobalUserGroups/GlobalUserGroups.php" );
// use extra translations for various user group names and similars
$wgGlobalUserGroupsUseEMWT = true;
// the following groups are defined as global, and intend to award on Special:UserRights listed in all the databases in $wgLocalDatabases are entered into the table 'user_groups' for each user
// for example:
$wgGlobalUserGroups = array(
    'globallyblocked',
);

// Revoke permissions for members of globallyblocked group
$wgRevokePermissions['globallyblocked']['createaccount'] = true;
$wgRevokePermissions['globallyblocked']['edit'] = true;
$wgRevokePermissions['globallyblocked']['sendemail'] = true;

// Allow system administrators to add and remove globallyblocked group
$wgAddGroups['sysadmin'][] = 'globallyblocked';
$wgRemoveGroups['sysadmin'][] = 'globallyblocked';

Thanks. Do I just setup the Global User Groups on the main wiki, or do I add it to all of the wikis?

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

I would suggest to use a global file for easily updating if you are not using one already. You just need to add or remove the global group(s) in one wiki and it / they will be added or removed on every wiki. If you decide to setup GlobalUserGroups extension on the main wiki only, global groups must be added and removed there only. Or you set it up for every wiki but you just allow adding and removing on the main wiki by default so you can add and remove global user groups on other wikis too if you grant the rights to system administrators to do so. You should set it up for every wiki and add messages for globallyblocked group in GlobalUserGroups.i18n.groups.php. But in any case, you need to set the $wgRevokePermissions part for every wiki.

Thanks.

Do I need to add

register_argc_argv=1

to the php.ini file?

I saw it when looking at Extension:MaintenanceShell. I noticed that using cron jobs to run the update.php were unsuccessful in previous projects, and I wonder if it was because of that, or if that setting only affects Maintenance Shell.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

The problem with this is that I haven't been able to run the update script.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Do you have shell access?

I don't think so. Where should I look for it?

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

On Linux: cd "<your MediaWiki directory>/maintenance" php update.php On Windows: cd "<Path to your PHP installation>" php "<Path to your MediaWiki installation>/maintenance/update.php" These are the commands you'd use, though I use Windows.

Thanks for your help on this.

I've been having trouble with the shared tables, but I expect to be able to get it to work at some point though.

Will it always be possible to use shared tables at any point, even if there are multiple accounts on the other wikis? I assume that would just require that the users of the other wikis would just need to recreate their accounts?

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

Shared tables can be difficult when your account system is not exactly the same, which is why CentralAuth is my suggestion.

Ok, it sounds like it's pretty good. Is it possible to use Confirm Account with it? It's perfect at keeping out spammers and good for keeping out vandals, so I don't want to lose use of it. It seems as though it treats the account creation as being created by the user who approved the account, if that helps at all.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

I've tried using ConfirmAccount, and I haven't verified whether it works with CentralAuth, mainly because my own CentralAuth instance is sorta broken. I would predict that users probably have to manually create global accounts because ConfirmAccount probably doesn't know to add to the centralauth database.