Erweiterung:CentralAuth
CentralAuth ermöglicht es, mehrere bestehende getrennte Kontensysteme in ein globales Kontensystem zusammenzufassen.
Installation
Siehe den Abschnitt Einrichtung unten für die Voraussetzungen zur Verwendung von CentralAuth. Folge dann diesen Anweisungen, wenn du bereit bist, CentralAuth zu aktivieren:
- Installiere Erweiterung:AntiSpoof , da es eine erforderliche Abhängigkeit ist.
- Lade den neuesten Snapshot herunter und entpacke ihn in dein
extensions
Verzeichnis. - Pick a database and create the CentralAuth database tables. Du kannst eine bestehende Datenbank verwenden oder eine neue erstellen; die Erweiterung verwendet standardmäßig eine Datenbank namens $1 (siehe $2 unten). (The extension by default uses the wiki's local database, which is convenient for automated testing but doesn't really make sense on a real wiki farm (as it will be different for every wiki, but the point of CentralAuth is sharing data between wikis) so you'll need to reconfigure that; see
$wgVirtualDomainsMapping['virtual-centralauth']
below.) Verwende diese Datenbank und führetables-generated.sql
aus.- Wenn du Erweiterung:AntiSpoof verwendest, musst du eine globale
spoofuser
Tabelle erstellen (um neue Benutzernamen zu sperren, die bestehenden Benutzernamen in einem beliebigen Wiki ähnlich sehen). Eine Möglichkeit, dies zu tun, ist, die Tabellespoofuser
aus der Datenbank des lokalen Wikis zu löschen und in die neue Tabelle$wgVirtualDomainsMapping['virtual-centralauth']
zu importieren.
- Wenn du Erweiterung:AntiSpoof verwendest, musst du eine globale
- Füge
wfLoadExtension( 'CentralAuth' );
bis LocalSettings.php für jedes deiner Wikis hinzu, oder in einer anderen PHP-Datei, die inLocalSettings.php
auf jedem deiner Wikis enthalten ist. - Die Erweiterung sollte jetzt aktiv sein.
Erstellen einer neuen Datenbank
Hier sind Beispiele für Shell- und SQL-Befehle, um die Datenbank centralauth
zu erstellen, die Tabelle spoofuser
dorthin zu kopieren und vorhandene Benutzerdaten dorthin zu migrieren.
Ersetze $wgDBname und $wgDBuser durch die Werte für deine eigene Wiki-Installation.
Erstelle die neue Datenbank (dieser Schritt ist optional, du kannst stattdessen auch eine deiner bestehenden Datenbanken verwenden; in diesem Fall überspringe den Schritt Tabellen erstellen):
$ cd extensions/CentralAuth
$ mysql -u root -p
(Passwort für Root-SQL-Benutzer beigetreten)
CREATE DATABASE centralauth;
USE centralauth;
GRANT all on centralauth.* to '$wgDBuser'@'localhost';
quit
Wartungsskripte ausführen
Im Folgenden wird davon ausgegangen, dass dein aktuelles Arbeitsverzeichnis deine MediaWiki-Installation ist (nicht dein CentralAuth Verzeichnis).
Erstelle die zentralen Auth-Tabellen (am besten mit sql.php
).
php maintenance/run.php sql --wikidb centralauth extensions/CentralAuth/schema/<db_type>/tables-generated.sql
Wenn AntiSpoof installiert ist, erstelle die Tabelle mit (Alternativ kannst du eine bestehende AntiSpoof Tabelle kopieren, wenn du frühere Einträge behalten willst):
php maintenance/run.php sql --wikidb centralauth extensions/AntiSpoof/sql/<db_type>/tables-generated.sql
Ausführen der Benutzermigrationsskripte
$ php maintenance/run.php CentralAuth:migratePass0.php
$ php maintenance/run.php CentralAuth:migratePass1.php
Upgrading
CentralAuth ist für große Wiki-Farmen gedacht, die Datenbank-Updates manuell ausführen, um Upgrades ohne Ausfallzeiten zu ermöglichen. Aus diesem Grund wird die CentralAuth-Datenbank nicht mit dem üblichen Upgrade-Prozess aktualisiert. Von Drittnutzern wird erwartet, dass sie der CentralAuth-Entwicklung folgen und Datenbankmigrationen stattdessen manuell durchführen.
Einrichtung
Zuerst musst du deine Wikifamilie mit $wgConf
konfigurieren, sonst kann CentralAuth nicht für deine Wikifamilie verwendet werden.
Dazu gehört, dass du $wgLocalDatabases
festlegst und ihn $wgConf->wikis
und $wgConf->settings
zuweist (das Minimum sind $wgCanonicalServer
, $wgServer
und $wgArticlePath
).
Befolge die Beispiele sorgfältig.
Wenn du eine neue Wiki-Familie erstellst, solltest du bedenken, dass es einfacher ist, wenn die Datenbanken für die Wikis in jeder Gruppe das gleiche Suffix haben (z.B. haben die hypothetischen Datenbanken enwiki
, dewiki
, frwiki
usw., die zu Wikis derselben Gruppe gehören, alle das Suffix "wiki
").
Nachdem du die Erweiterung installiert hast, musst du einige Daten in der CentralAuth-Datenbank erfassen. Um rückwirkend globale Konten einzurichten, musst du die Skripte migratePass0.php und migratePass1.php ausführen. Die erste speichert Informationen über deine Wikis in der CentralAuth-Datenbank, während die zweite eine automatische Migrationsheuristik verwendet, um globale Accounts zu erstellen. Ein Nutzer kann seine Konten manuell über Special:MergeAccount zusammenführen. Probeläufe können für Testzwecke verwendet werden.
Um globale Gruppen zu aktivieren, musst du einen Eintrag in der Tabelle global_group_permissions
in deiner CentralAuth-Datenbank vornehmen, zusammen mit ggp_group='steward'
und (für den Zugriff auf die Gruppenverwaltungsoberfläche) ggp_permission=globalgrouppermissions
.
Ein Beispiel für eine Abfrage, deren Verwendung empfohlen wird, ist:
INSERT INTO global_group_permissions (ggp_group,ggp_permission) VALUES ('steward','globalgrouppermissions'), ('steward','globalgroupmembership');
Dann befördere einige Nutzer zu Stewards:
INSERT IGNORE INTO global_user_groups (gug_user, gug_group) VALUES ((SELECT gu_id FROM globaluser WHERE gu_name='Admin'), 'steward');
Es existiert eine Reihe von Einstellungen, die du ändern kannst (z.B. ob du eine Einzelanmeldung für eine ganze Domain anbieten willst), die unter CentralAuth.php aufgeführt sind.
Insbesondere solltest du den Standardwert von $wgVirtualDomainsMapping['virtual-centralauth']
überschreiben, wenn deine CentralAuth-Datenbank einen anderen Namen als $2 hat.
Erstelle solche Einstellungen nach der Zeile wfLoadExtension
in LocalSettings.php
, z.B.:
wfLoadExtension( 'CentralAuth' );
$wgVirtualDomainsMapping['virtual-centralauth'] = [ 'db' => 'centralauth' ];
"SUL2"-Verhalten
Im Juli 2013 änderte WMF seine Vorgehensweise bei der Anmeldung von Benutzern in mehreren Wikis.
Wenn CentralAuth für diesen neuen Ansatz konfiguriert ist, leitet es nach erfolgreicher Anmeldung und Kontoerstellung zu Special:CentralLogin/start?token=somevalue
auf ein "zentrales Login-Wiki" um, das Cookies auf diesem Wiki festlegt und dann zurück zu dem eingeloggten Wiki umleitet.
It omits the "login/account creation success" page, instead redirecting back to the "returnto" page that the user was originally on.
It places 1x1 pixel images in the footer of that page, in place of the icons formerly used on the "login/account creation success" page.
Die Einstellungen hierfür sind in etwa,
# Allgemeine CentralAuth Konfiguration
$wgCentralAuthCookies = true;
// default is to use the local wiki database
$wgVirtualDomainsMapping['virtual-centralauth'] = [ 'db' => 'centralauthDatabaseName' ];
$wgCentralAuthAutoMigrate = true;
$wgCentralAuthAutoLoginWikis = [
# Zuordnung von Domänennamen zu Wiki-IDs für die automatische Anmeldung bei anderen Wikis
'enwiki.mediawiki.mwdd.localhost' => 'enwiki',
];
# Aktiviert die Weiterleitung zum "zentralen Login-Wiki".
$wgCentralAuthLoginWiki = 'WikiIdOfLoginWiki';
$wgCentralAuthLoginWiki
ist die ID (normalerweise der Datenbankname) des Wikis, zu dem CentralAuth bei der Anmeldung und beim Anlegen eines Kontos umleitet.
Cache-Probleme
Für beste Ergebnisse wird empfohlen, Memcached zu verwenden.
Wenn du nur einen einzigen Server hast, können zudem Beschleuniger-Caches (CACHE_ACCEL
) wie APCu funktionieren, die du jedoch nicht verwenden solltest, wenn du mehrere Server hast.
Wenn du keinen Cache (d.h. CACHE_NONE
) für $wgMainCacheType
festgelegt hast oder CACHE_DB
verwendest, musst du sicherstellen, dass alle deine Wikis dieselbe Cachetabelle verwenden.
Standardmäßig verwendet jedes Wiki in deiner Wiki-Farm die Tabelle objectcache
in seiner eigenen Datenbank (mit eigenem db-Präfix), wenn $wgMainCacheType
auf CACHE_NONE
oder CACHE_DB
festgelegt ist.
Damit das mit CentralAuth funktioniert, müssen wir den Wikis sagen, dass sie eine zentrale Cache-Tabelle verwenden sollen.
Wenn du eine zentrale Zwischenspeichertabelle in der Datenbank centralauth
erstellen willst (und angenommen, eines deiner bestehenden Wikis hat den Datenbanknamen enwiki
), führe folgenden Code aus, um die Tabelle in deine andere Datenbank zu kopieren:
CREATE TABLE centralauth.objectcache LIKE enwiki.objectcache
Füge dann die folgende Konfiguration zu allen Wikis hinzu, um ihnen zu sagen, dass sie die zentrale Tabelle anstelle ihrer eigenen Tabelle verwenden sollen:
$wgSharedDB = 'centralauth'; // or whatever database you use for central data
$wgSharedTables = [ 'objectcache' ]; // remember to copy the table structure's to the central database first
$wgCentralAuthSessionCacheType = CACHE_DB; // Tell mediawiki to use objectcache database for central auth.
When running PHPUnit tests locally with your wiki farm and do not want them to fail due to an attempt to clone database tables with the shared tables config above, use:
if ( defined( 'MW_PHPUNIT_TEST' ) ) {
$wgSharedTables = [];
} else {
$wgSharedTables = [ 'objectcache' ];
}
HTTP and HTTPS
Seit 2023 unterstützt CentralAuth keine HTTP/HTTPS-Wikis mit gemischten Protokollen mehr, sondern nur reine HTTPS-Wikis (mit $wgForceHTTPS auf true
festgelegt) und reine HTTP-Wikis (hauptsächlich für lokale Tests).
See issue T348852.
Konfiguration
Database Virtual Domains Mapping
Since MediaWiki 1.41, you can configure database virtual domains mapping for CentralAuth, and this replaced $wgCentralAuthDatabase
.
To setup virtual domains mapping with CentralAuth, use:
// 'centralauth' is the name of the your CentralAuth database.
$wgVirtualDomainsMapping['virtual-centralauth'] = [ 'db' => 'centralauth' ];
Parameter | Voreinstellung | Anmerkung |
---|---|---|
(deprecated ) $wgCentralAuthDatabase
|
null
|
Name der Datenbank, in der du die zentralen Zugangsdaten speicherst.
Wenn dies nicht auf der primären Datenbankverbindung ist, vergiss nicht, auch für Um eine Datenbank mit einem Tabellenpräfix zu verwenden, legst du diese Variable auf " NOTE: This setting has been deprecated, use virtual domains mapping as described above. |
$wgCentralAuthAutoMigrate
|
false
|
Bei true werden bestehende unverbundene Konten automatisch migriert, wenn möglich beim ersten Login.
Alle neu erstellten Konten müssen angehängt werden. Wenn |
$wgCentralAuthAutoMigrateNonGlobalAccounts
|
false
|
Wenn true , werden bestehende unverbundene Konten, für die kein globales Konto existiert, verglichen, um zu sehen, ob eine Zusammenführung auf der Grundlage von Passwörtern und E-Mails erstellt werden kann, ohne dass es zu Konflikten kommt (alle Konten werden zusammengeführt).
Dies wurde früher von |
$wgCentralAuthStrict
|
false
|
Wenn true , wird den verbleibenden Konten, die nicht angehängt wurden, das Einloggen untersagt, bis die Probleme gelöst sind.
|
$wgCentralAuthDryRun
|
false
|
Wenn true , ist das Zusammenführen über die Benutzeroberfläche Special:MergeAccount nicht möglich.
|
$wgCentralAuthCookies
|
false
|
Wenn true , werden globale Sitzungs- und Token-Cookies zusammen mit den Sitzungs- und Login-Tokens der einzelnen Wikis festgelegt, wenn sich die Benutzer/innen mit einem globalen Konto anmelden.
So können andere Wikis auf derselben Domain sie transparent anmelden. |
$wgCentralAuthLoginWiki
|
false
|
Datenbankname eines zentralen Login-Wikis. Dies ist eine Alternative zum direkten Festlegen von domänenübergreifenden Cookies für jedes Wiki in $wgCentralAuthAutoLoginWikis . Wenn festgelegt, verwendet ein einzelnes Login-Wiki ein Session/Cookie, um einheitliche Login-Sitzungen in allen Wikis zu verwalten.
Bei der Anmeldung werden die Benutzer/innen auf die Seite Special:CentralLogin/login des Anmeldewikis und dann auf die Seite Special:CentralLogin des Ursprungswikis weitergeleitet. Dabei werden das zentrale Login-Wiki-Cookie und die Sitzung festgelegt. Wenn der/die Nutzer/in auf andere Wikis zugreift, wird das Login-Wiki über JavaScript überprüft, um den Login-Status zu prüfen und die lokale Sitzung und Cookies festzulegen. Dies erfordert |
$wgCentralAuthCookieDomain
|
''
|
Domain, für die globale Cookies festgelegt werden sollen.
Zum Beispiel |
$wgCentralAuthCookiePrefix
|
'centralauth_'
|
Präfix für globale CentralAuth-Authentifizierungs-Cookies. |
$wgCentralAuthCookiePath
|
'/'
|
Pfad für die globalen Authentifizierungs-Cookies von CentralAuth. Lege diese Variable fest, wenn du Cookies auf einen bestimmten Pfad innerhalb der mit $wgCentralAuthCookieDomain angegebenen Domain beschränken willst.
|
$wgCentralAuthAutoLoginWikis
|
[]
|
Liste der Wiki IDs, die beim Login aufgerufen werden sollen, um zu versuchen, Drittanbieter-Cookies für den globalen Sitzungsstatus festzulegen.
Die Wiki ID ist normalerweise der Datenbankname, außer wenn Tabellenpräfixe verwendet werden. In diesem Fall ist es der Datenbankname, ein Bindestrich als Trennzeichen und dann der Tabellenpräfix. So kann eine Farm mit mehreren Second-Level-Domains eine globale Sitzung für alle festlegen, indem sie ein Wiki von jeder Domain (en.wikipedia.org, en.wikinews.org usw.) anklickt. Dies geschieht durch den Zugriff auf Wenn leer, werden keine anderen Wikis getroffen. Der Schlüssel sollte auf den Namen der Cookie-Domäne gesetzt werden. |
$wgCentralAuthAutoCreateWikis
|
[]
|
Liste der Wiki IDs, für die automatisch ein lokales Konto erstellt werden soll, wenn das globale Konto erstellt wird.
Die Wiki ID ist normalerweise der Datenbankname, außer wenn Tabellenpräfixe verwendet werden. In diesem Fall ist es der Datenbankname, ein Bindestrich als Trennzeichen und dann der Tabellenpräfix. |
$wgCentralAuthLoginIcon
|
false
|
Der lokale Dateisystempfad zu dem von Special:CentralAutoLogin zurückgegebenen Icon sollte ein 20x20px PNG sein.
|
$wgCentralAuthPrefsForUIReload
|
[ 'skin', 'language', 'thumbsize', 'underline', 'stubthreshold', 'showhiddencats', 'justify', 'numberheadings', 'editondblclick', 'editsection', 'editsectiononrightclick', 'usenewrc', 'extendwatchlist' ]
|
Benutzereinstellungen, für die wir empfehlen sollen, die Seite nach einer erfolgreichen zentralen Login-Abfrage neu zu laden.
Wenn du etwas Komplizierteres als nur |
$wgCentralAuthRC
|
[]
|
Array mit Einstellungen für das Senden der CentralAuth-Ereignisse an die RC Feeds.
|
$wgCentralAuthWikisPerSuppressJob
|
10
|
Größe der Wikis, die in einem einzigen Unterdrückungsjob bearbeitet werden. Bedenke, dass ein Wiki ~10 Abfragen erfordert.
|
$wgCentralAuthReadOnly
|
false
|
Wie $wgReadOnly ,, um die Erweiterung auf den Nur-Lese-Modus der Datenbank einzustellen.
|
$wgCentralAuthEnableGlobalRenameRequest
|
false
|
Feature-Flagge für Special:GlobalRenameRequest .
|
$wgCentralAuthGlobalPasswordPolicies
|
[]
|
Globale Passwortrichtlinien. Diese werden wie lokale Kennwortrichtlinien angewandt, d.h. die stärkste Richtlinie, die für einen Benutzer gilt, wird verwendet. Richtlinien können entweder für eine lokale Gruppe (wenn der/die Benutzer/in auf einem beliebigen Wiki Mitglied dieser Gruppe ist, gilt die Richtlinie für diesen/diese Benutzer/in) oder für eine globale Gruppe gelten.
|
$wgGlobalRenameDenylist
|
null
|
A list of users who won't be allowed to create new global rename requests through Special:GlobalRenameRequest.
Es existieren zwei Möglichkeiten, es festzulegen:
Du kannst die genauen Namen oder reguläre Ausdrücke verwenden.
|
$wgCentralAuthGlobalBlockInterwikiPrefix
|
"global"
|
Wenn du einen Benutzer global unterdrückst, wird eine Sperre gegen diesen Benutzer in allen Wikis eingefügt. CentralAuth will set the author of theses blocks as $wgCentralAuthGlobalBlockInterwikiPrefix>(user-who-made-the-suppression's nickname) . Zum Beispiel, wenn $wgCentralAuthGlobalBlockInterwikiPrefix = "Admins"; , and Joe suppresses John, all wikis will show in BlockList a block against John made by Admins>Joe .
|
Verwendung
Ermöglicht ein Single-User-Login-System (SUL) unter Verwendung des AuthPlugin-Systems von MediaWiki. Die Benutzererstellung und -anmeldung geschieht global über eine zentrale Benutzertabelle für alle Wikis. Beachte jedoch, dass lokale Benutzerkonten bei der Kontoerstellung/Anmeldung automatisch erstellt werden.
Diese Erweiterung implementiert zudem globale Benutzergruppen, zu denen globale Konten gehören können.
Benutzerrechte
CentralAuth definiert mehrere neue Benutzerrechte:
Benuterrecht | Fähigkeiten | Standardgruppe | Status |
---|---|---|---|
centralauth-createlocal
|
Erstellung eines lokalen Kontos zu einem globalen Benutzerkonto erzwingen | Stewards und Administratoren | Aktiv in MW 1.36+ |
centralauth-lock
|
Verhindere, dass sich Benutzer bei einem beliebigen Wiki anmelden können | Stewards | Aktiv |
centralauth-suppress
|
Globale Konten unterdrücken oder einblenden | Stewards | Aktiv |
centralauth-rename
|
Globale Konten umbenennen | Stewards | Aktiv |
centralauth-unmerge
|
Globale Konten von einem lokalen Konto trennen | Stewards | Aktiv |
centralauth-merge
|
Alle CentralAuth-Konten global zusammenführen | Alle Benutzer | Aktiv; üblicherweise automatisch |
globalgrouppermissions
|
Berechtigungen für globale Gruppen verwalten | Globale Stewards | Aktiv; standardmäßig nicht den lokalen Stewards zugewiesen |
globalgroupmembership
|
Mitgliedschaft in globalen Gruppen bearbeiten | Globale Stewards | Aktiv; standardmäßig nicht den lokalen Stewards zugewiesen |
Funktionen
Einzelbenutzeranmeldung (SUL)
Ein/e Nutzer/in, der/die ein Konto in mehr als einem Wiki hat, kann Special:MergeAccount verwenden, um sein/ihr globales Nutzerkonto zu erstellen, das dann in allen Wikis verwendet werden kann. Benutzer/innen mit der Berechtigung centralauth-unmerge
(die Stewards standardmäßig erhalten) können die Zusammenlegung eines globalen Kontos rückgängig machen, wobei alle Passwörter auf die Einstellung vor der Zusammenlegung zurückgesetzt werden.
Benutzerkonten können nun zudem global umbenannt werden.
Globale Benutzer sperren und ausblenden
Ein globales Konto kann von einem Benutzer mit den Berechtigungen centralauth-lock
bzw. centralauth-suppress
"gesperrt" oder "versteckt" werden, die standardmäßig der "lokalen" Gruppe "Stewards" erteilt werden.
Ein gesperrtes globales Konto wird sofort aus allen Sitzungen in allen Wikis, in denen es gerade angemeldet ist, ausgeloggt.
Der Benutzername eines versteckten globalen Kontos ist in keinem Protokoll außer dem Protokoll des globalen Kontos sichtbar.
Wiki-Sets
Ein Wiki-Set ist eine Gruppe von Wikis, die von einem Benutzer mit dem Recht globalgrouppermissions
festgelegt wurde.
Sets können "opt-in" (Wikis sind standardmäßig nicht drin) oder "opt-out" (Wikis sind drin, wenn sie nicht abgewählt werden) sein.
Globale Benutzergruppen
Wenn du globale Benutzergruppen wie im Abschnitt Installation beschrieben aktiviert hast, kann ein migrierter Steward die Benutzeroberfläche Special:GlobalGroupPermissions verwenden, um globale Benutzergruppen und ihre Rechte zu konfigurieren.
Eine globale Benutzergruppe ist standardmäßig in allen Wikis aktiv (die Benutzer/innen in ihr haben ihre Rechte in allen Wikis), es sei denn, die Gruppe wurde so festgelegt, dass sie nur in einem bestimmten Wiki-Set aktiv ist (die Benutzer/innen in der Gruppe haben die Rechte nur, wenn sie in einem Wiki des Sets sind).
Globale Gruppenberechtigungen werden nicht mit Special:ListUsers, sondern mit Special:GlobalUsers aufgeführt.
Sie werden von einem Benutzer mit der Berechtigung globalgroupmembership
zugewiesen (standardmäßig die globale Gruppe stewards
) und geben dem Benutzer die angegebenen Rechte, auch wenn die durch $wgGroupPermissions
definierten lokalen Rechte dies nicht tun.
Lizenzierung und Downloads
Die Erweiterung ist unter der GNU General Public License 2.0 oder höher verfügbar und kann von Git heruntergeladen oder über den webbasierter Betrachter aufgerufen werden.
Die Software wird so geliefert, wie sie ist. Aktualisierungen werden nach den Bedürfnissen der Wikimedia-Wikis erstellt oder wenn kritische Schwachstellen entdeckt werden.
API
Siehe Extension:CentralAuth/API .
Einzelnachweise
Siehe auch
- Hilfe:Einheitliche Anmeldung auf Meta-Wiki
- Extension:CentralAuth/authentication - CentralAuth Authentifizierungsfunktionen
$wgSharedDB
- User:Legoktm/evil-plans2.txt - 2015 Plan zur Abschaffung von CentralAuth bei WMF
- Global session threat assessment
- Integrated watchlists
- CentralAuth Kontrollfluss
- Stuck global renames
Diese Erweiterung wird in einem oder mehreren Wikis von Wikimedia verwendet. Das bedeutet mit hoher Wahrscheinlichkeit, dass die Erweiterung stabil ist und gut genug funktioniert, um auf solch häufig besuchten Webseiten benutzt zu werden. Suche nach dem Erweiterungs-Namen in den Wikimedia CommonSettings.php und den InitialiseSettings.php-Konfigurations-Dateien, um nachzusehen, wo es installiert ist. Eine vollständige Liste der installierten Erweiterungen in einem bestimmten Wiki wird auf Special:Version im Wiki generiert und angezeigt. |
Diese Erweiterung ist in den folgenden Softwarepaketen enthalten und/oder wird von den folgenden Wiki-Farmen, bzw. Wiki-Hostern verwendet: Dies ist keine maßgebliche Liste. Softwarepakete und/oder Wiki-Farmen, bzw. Wiki-Hoster nutzen diese Erweiterung ggf., obwohl sie nicht in dieser Liste enthalten sind. Prüfe daher stets die Nutzung im verwendeten Softwarepaket und/oder bei der Wiki-Farm, bzw. dem Wiki-Hoster. |