Skip to content
GitLab
Closed
Issue created by Wolfgang Fahl@WolfgangFahlMaintainer

Lower case user names

Lowercase Username Login Failure — Analysis / Analyse

Wiki: wiki.genealogy.net (genwiki39e) · DB: wiki Date: 2026-06-10 Example user: christa (user_id 1772134387, email ch.pawop@web.de, cai_id 200)

English

Symptom

A user with a resolved ("zugeordnet") compgen_auth_identity row cannot log in via WeChange OAuth. Instead of being logged in, they receive:

Die automatische Erstellung des lokalen Benutzerkontos ist fehlgeschlagen. Die automatische Benutzerkontenerstellung ist nicht erlaubt.

(MediaWiki autocreation failure — autocreation is intentionally disabled.)

Root cause

The production wiki contains legacy users whose user.user_name begins with a lowercase letter (e.g. christa). Such a name is not a canonical MediaWiki username — MediaWiki canonicalizes the first character to uppercase (UserNameUtils::getCanonical('christa') === 'Christa', and isValid('christa') === false).

The CompGenAuth login flow had two coupled defects:

  1. CompGenIdentity::getUsername() returned the raw, non-canonical name (CompGenIdentity.php:96).
  2. CompGenIdentityResolver::ensureMapping() stored that raw name in wsoauth_multiauth_mappings.wsoauth_remote_name, which is a case-sensitive varbinary(512) column.

WSOAuth then looks the mapping up with ucfirst($name) against that binary column (WSOAuth.php:310, :386):

stored:    christa   (lowercase, from ensureMapping)
lookup:    Christa   (ucfirst, from WSOAuth.getLocalAccountID)
varbinary => case-sensitive => NO MATCH

Login flow consequence (WSOAuth.php:316-355):

  • Case 1 (mapping found → direct login): skipped, because the binary lookup misses.
  • Case 2 (already logged in locally): not applicable.
  • Case 3 (no mapping, not logged in): falls through to autocreation.

Autocreation is intentionally disabled on this wiki (sites/wiki.genealogy.net/CompgenSettings.php:142: $wgGroupPermissions['*']['autocreateaccount'] = false;), so MediaWiki aborts with the German error message above.

Workaround applied (single user)

Canonicalized the username christa → Christa in three tables in one transaction:

START TRANSACTION;
UPDATE user  SET user_name='Christa'  WHERE user_id=1772134387 AND user_name='christa';
UPDATE actor SET actor_name='Christa' WHERE actor_user=1772134387 AND actor_name='christa';
UPDATE wsoauth_multiauth_mappings SET wsoauth_remote_name='Christa'
  WHERE wsoauth_user=1772134387 AND wsoauth_remote_name='christa';
COMMIT;

Verified: WSOAuth Case 1 lookup for Christa now returns user_id 1772134387 → direct login, no autocreation. User can log in.

Software fix applied

CompGenIdentity::getUsername() (CompGenIdentity.php:96) now canonicalizes the username via UserNameUtils::getCanonical() before returning it. Because this method is the single chokepoint used by both ensureMapping() (stored mapping name) and toUserInfo() (name handed to WSOAuth), canonicalizing here fixes both consistently:

public function getUsername(): string {
    $rawName = \User::newFromId( $this->localUserId )->getName();
    $canonical = \MediaWiki\MediaWikiServices::getInstance()
        ->getUserNameUtils()
        ->getCanonical( $rawName );
    return $canonical !== false ? $canonical : $rawName;
}

This guarantees ensureMapping() stores the same string WSOAuth queries for, and that WSOAuth receives a valid username.

Remaining scope

70 local users still have lowercase-initial user_name values (same latent bug). The software fix corrects the mapping side, but WSOAuth Case 1 still logs in as User::newFromId($localUserId)->getName(), which remains the raw lowercase name until the user/actor rows themselves are canonicalized. For full robustness those rows should be renamed too (same 3-table update as Christa, ideally via the Renameuser extension once it is loadable in the CLI config).

Find all affected users:

SELECT user_id, user_name FROM user WHERE user_name REGEXP '^[a-z]' ORDER BY user_id;

Deutsch

Symptom

Ein Benutzer mit einer bereits aufgelösten ("zugeordneten") compgen_auth_identity-Zeile kann sich nicht über WeChange-OAuth anmelden. Statt angemeldet zu werden, erscheint:

Die automatische Erstellung des lokalen Benutzerkontos ist fehlgeschlagen. Die automatische Benutzerkontenerstellung ist nicht erlaubt.

(MediaWiki-Fehler bei der Autoerstellung — die Autoerstellung ist absichtlich deaktiviert.)

Ursache

Das Produktions-Wiki enthält Altbenutzer, deren user.user_name mit einem Kleinbuchstaben beginnt (z. B. christa). Ein solcher Name ist kein kanonischer MediaWiki-Benutzername — MediaWiki wandelt das erste Zeichen in Großbuchstaben um (UserNameUtils::getCanonical('christa') === 'Christa', und isValid('christa') === false).

Der CompGenAuth-Anmeldefluss hatte zwei zusammenhängende Fehler:

  1. CompGenIdentity::getUsername() gab den rohen, nicht-kanonischen Namen zurück (CompGenIdentity.php:96).
  2. CompGenIdentityResolver::ensureMapping() speicherte diesen rohen Namen in wsoauth_multiauth_mappings.wsoauth_remote_name — einer case-sensitiven Spalte vom Typ varbinary(512).

WSOAuth sucht das Mapping anschließend mit ucfirst($name) in dieser Binärspalte (WSOAuth.php:310, :386):

gespeichert:  christa   (klein, von ensureMapping)
Suche:        Christa   (ucfirst, von WSOAuth.getLocalAccountID)
varbinary  => case-sensitiv => KEIN TREFFER

Folge im Anmeldefluss (WSOAuth.php:316-355):

  • Fall 1 (Mapping gefunden → direkte Anmeldung): übersprungen, da die Binärsuche fehlschlägt.
  • Fall 2 (lokal bereits angemeldet): nicht zutreffend.
  • Fall 3 (kein Mapping, nicht angemeldet): fällt durch zur Autoerstellung.

Die Autoerstellung ist auf diesem Wiki absichtlich deaktiviert (sites/wiki.genealogy.net/CompgenSettings.php:142: $wgGroupPermissions['*']['autocreateaccount'] = false;), daher bricht MediaWiki mit der oben genannten deutschen Fehlermeldung ab.

Angewandter Workaround (einzelner Benutzer)

Benutzername christa → Christa in drei Tabellen in einer Transaktion kanonisiert:

START TRANSACTION;
UPDATE user  SET user_name='Christa'  WHERE user_id=1772134387 AND user_name='christa';
UPDATE actor SET actor_name='Christa' WHERE actor_user=1772134387 AND actor_name='christa';
UPDATE wsoauth_multiauth_mappings SET wsoauth_remote_name='Christa'
  WHERE wsoauth_user=1772134387 AND wsoauth_remote_name='christa';
COMMIT;

Geprüft: Die WSOAuth-Fall-1-Suche nach Christa liefert jetzt user_id 1772134387 → direkte Anmeldung, keine Autoerstellung. Der Benutzer kann sich anmelden.

Angewandte Software-Korrektur

CompGenIdentity::getUsername() (CompGenIdentity.php:96) kanonisiert den Benutzernamen jetzt über UserNameUtils::getCanonical(), bevor er zurückgegeben wird. Da diese Methode der einzige Engpass ist, der sowohl von ensureMapping() (gespeicherter Mapping-Name) als auch von toUserInfo() (an WSOAuth übergebener Name) genutzt wird, behebt die Kanonisierung an dieser Stelle beides konsistent:

public function getUsername(): string {
    $rawName = \User::newFromId( $this->localUserId )->getName();
    $canonical = \MediaWiki\MediaWikiServices::getInstance()
        ->getUserNameUtils()
        ->getCanonical( $rawName );
    return $canonical !== false ? $canonical : $rawName;
}

Damit ist garantiert, dass ensureMapping() exakt den String speichert, nach dem WSOAuth sucht, und dass WSOAuth einen gültigen Benutzernamen erhält.

Verbleibender Umfang

70 lokale Benutzer haben weiterhin user_name-Werte mit Kleinbuchstaben am Anfang (derselbe latente Fehler). Die Software-Korrektur behebt die Mapping-Seite, aber WSOAuth-Fall 1 meldet sich weiterhin als User::newFromId($localUserId)->getName() an, was bis zur Kanonisierung der user/actor-Zeilen der rohe Kleinbuchstaben-Name bleibt. Für volle Robustheit sollten auch diese Zeilen umbenannt werden (gleiches 3-Tabellen-Update wie bei Christa, idealerweise über die Renameuser-Erweiterung, sobald diese in der CLI-Konfiguration ladbar ist).

Alle betroffenen Benutzer finden:

SELECT user_id, user_name FROM user WHERE user_name REGEXP '^[a-z]' ORDER BY user_id;

Impressum | Datenschutz