Spaß mit MediaWiki
26. Mai 2020 um 20:15 Uhr von Atari-Frosch
Ein ziemlich altes Mediawiki (Version 1.22.x oder so) lag seit ca. 2,5 Jahren auf Eis und sollte wiederbelebt werden. Was bisher geschah:
- Installation MediaWiki 1.34.1 (von der Mediawiki-Website)
- Datenbank in MariaDB angelegt
- SQL-Dump der alten Datenbank eingelesen, alles OK
- nginx konfiguriert
- Wiki im Browser aufgerufen
- Konfigurationsanweisungen befolgt, dabei Admin-Account angelegt
- LocalConfiguration.php erzeugt, runtergeladen, plaziert
- Wiki aufgerufen, Login mit dem vorher erzeugten Admin-Account; Paßwort nicht akzeptiert
- Option „Paßwort vergessen“ angeklickt; Mail taucht im mail.log nicht auf und kommt natürlich auch nicht an
- in der Wiki-Benutzerübersicht nachgesehen: Der Account existiert nicht;
- die Datenbank ist auch dieser Meinung.
Und so ging's weiter:
Die Benutzerübersicht im Wiki zeigte außerdem an, daß nur zwei Accounts Admin-Rechte haben: Der Account-Inhaber des einen ist seit mehreren Jahren tot, der andere Account hat einen generischen Namen und ist gesperrt. Account-Inhaber, die ich erreichen könnte, haben den Admin-Status nicht.
So. Meine erste Idee war jetzt, meinen Admin-Account händisch in die Datenbank zu inserten (ja, ich tendiere dazu, die komplizierteste Variante als erstes zu testen 😉). Also hab ich mir die entsprechende Tabelle mal angesehen:
MariaDB [mediawiki]> show columns from user; +--------------------------+------------------+------+-----+----------------------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------------------+------------------+------+-----+----------------------------------+----------------+ | user_id | int(10) unsigned | NO | PRI | NULL | auto_increment | | user_name | varbinary(255) | NO | UNI | | | | user_real_name | varbinary(255) | NO | | | | | user_password | tinyblob | NO | | NULL | | | user_newpassword | tinyblob | NO | | NULL | | | user_newpass_time | binary(14) | YES | | NULL | | | user_email | tinyblob | NO | MUL | NULL | | | user_touched | binary(14) | NO | | | | | user_token | binary(32) | NO | | | | | user_email_authenticated | binary(14) | YES | | NULL | | | user_email_token | binary(32) | YES | MUL | NULL | | | user_email_token_expires | binary(14) | YES | | NULL | | | user_registration | binary(14) | YES | | NULL | | | user_editcount | int(11) | YES | | NULL | | | user_password_expires | varbinary(14) | YES | | NULL | | +--------------------------+------------------+------+-----+----------------------------------+----------------+
Wer denkt sich sowas aus? 🤦♀️ Überall, wo binary(14) drinsteht, gehört eigentlich ein datetime hin … und was soll das tinyblob für das Paßwort?
„Einfach mal so händisch“ ist also eher nicht drin. Dann durchsuchte ich das MediaWiki-Verzeichnis nach dem Script, das User-Accounts anlegt. Das ist dann wohl /maintenance/createAndPromote.php. Nächstes Problem: Händisch kann ich diese Datei vermutlich nicht einfach so starten, und PHP lesen kann ich auch nicht so wirklich. Das Script legt auch nicht einfach so Accounts an, es stehen nämlich keine SQL-Befehle drin. Das geht offenbar über Klassen, die aber nicht im Script selbst definiert werden. Puh.
Nächste Idee: Den gesperrten Account mit dem generischen Namen, der Admin-Rechte hat, entsperren. Nur: Wie?
Irgendwo (leider nicht notiert) fand ich den Hinweis, daß ein Account dann gesperrt sei, wenn er kein Paßwort hat. Und tatsächlich: Der Account hatte keins. Allerdings hat auch ein anderer Account kein erkennbares Paßwort und ist nicht als gesperrt markiert. Hm. Also mal testen.
Auf einer Seite von Inmotionhosting fand ich folgenden Hinweis:
Navigate to your MediaWiki maintenance directory. For example:
cd /home/userna5/public_html/mediawiki/maintenance
Run the following bash command (Supplement the admin with your username and the pass1234 with the password you want to change to).
php changePassword.php --user=admin --password=pass1234
Das wurde auch anstandslos ausgeführt, allerdings wurde mir der Account danach immer noch als gesperrt angezeigt. Das allein genügt also offenbar nicht – was ja bereits zu vermuten war.
Trotzdem loggte ich mich mit dem neu gesetzten Paßwort ein. Bei dem Versuch, etwas zu editieren, wurde mir jedoch, wie zu erwarten war, angezeigt, daß ich das nicht dürfe, weil der Account ja gesperrt sei. Ich solle den Menschen kontaktieren, der die Sperre gesetzt hat. Kleiner Haken dabei: Der ist da schon lange nicht mehr aktiv und es ist anzunehmen, daß er sein Paßwort nicht mehr weiß.
Als nächstes setzte ich für den Account eine neue Mailadresse. Daraufhin bekam ich an diese Adresse eine Mail mit einem Bestätigungslink. Und Bingo! Danach konnte ich den Account im Interface selbst entsperren, mir einen eigenen Account anlegen und diesem Admin-Rechte geben. Dann loggte ich mich aus, loggte mich mit meinem neuen Account wieder ein und sperrte den generischen wieder.
Von hinten durch die Brust ins Auge, aber mit Volltreffer. 😉