Benutzer:Christian/Neue Benutzerrechte: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
KKeine Bearbeitungszusammenfassung |
||
Zeile 184: | Zeile 184: | ||
# [https://www.mediawiki.org/wiki/Extension:UserPageEditProtection Extension:UserPageEditProtection] installieren und einrichten | # [https://www.mediawiki.org/wiki/Extension:UserPageEditProtection Extension:UserPageEditProtection] installieren und einrichten | ||
# Editieren nur mit bestätigter Email-Adresse <pre>$wgEmailConfirmToEdit = true; $wgEmailAuthentication = true;</pre> | # Editieren nur mit bestätigter Email-Adresse <pre>$wgEmailConfirmToEdit = true; $wgEmailAuthentication = true;</pre> | ||
# edit Berechtigung für <code>user</code> Gruppe entfernen<pre>$wgGroupPermissions['user']['edit'] = false;</pre> | # edit Berechtigung für <code>user</code> Gruppe entfernen<pre>$wgGroupPermissions['user']['edit'] = false;</pre> | ||
#'''Meilenstein''' Jetzt können wir die Registrierung öffnen | #'''Meilenstein''' Jetzt können wir die Registrierung öffnen |
Version vom 5. Mai 2024, 19:51 Uhr
Wie migrieren wir zu dem neuen Benutzerschema?
Beachtenswert
- Die Nutzergruppe user gibt es nicht in echt
- Sie ist virtuell im Code von MediaWiki und wird jedem angemeldeten Benutzer zugewiesen.
- Bestimmte Extensions verändern die Gruppenrechte, nachdem die LocalSettings.php bereits evaluiert wurde. Siehe
$wgExtensionFunctions[]
- Manche Namensräume sind durch spezielle Rechte geschützt, z.B. die Talk-Namensräume durch createtalk statt createpage
- Das erschwert das Nachdenken im Zusammenspiel mit
$wgNamespaceProtection
- Das erschwert das Nachdenken im Zusammenspiel mit
- Manche Rechte sind Fähigkeiten, z.B. autopatrol
$wgNamespaceProtection
funktioniert auf folgende Weise:- Man kann damit Namespaces schützen, indem man vorgibt, dass ein Nutzer ein bestimmtes Recht erst haben muss, bevor er editieren kann.
- Man kann Lese-Rechte damit nicht entziehen
- Unklar: Vermutlich können Extension-spezifische Sonderrechte damit nicht per Namensraum entfernt werden
Aktuelles Schema
- Anmerkung
- Diese Aufzählung ist nicht vollständig, sondern nur in Bezug auf das neue Schema bezogen.
anonym | angemeldet | sysops + co | Anmerkung | |
---|---|---|---|---|
Lesen bestimmter Seiten | ✅ | ✅ | ✅ | |
Lesen im Haupt-NS | ✅ | ✅ | ✅ | |
Schreiben im Haupt-NS | ❌ | ✅ | ✅ | |
Diskussionseiten sehen | ❌ | ✅ | ✅ | unklar ob das nur per UI gemacht ist |
Diskussionseiten bearbeiten | ❌ | ✅ | ✅ | unklar ob das nur per UI gemacht ist |
Editier-Knopf sichtbar | ❌ | ✅ | ✅ | |
Replacetext nutzen | ❌ | ✅ | ✅ | eigenartig, eigentlich sollten das nur SysOps dürfen |
Seiten Löschen | ❌ | ✅ | ✅ | |
Schreiben im Vorlagen-NS | ❌ | ✴️
(Gruppe: lernpfadprofi) |
✅ | via $wgNamespaceProtection
|
PageForms bearbeiten | ❌ | ❌ | ✅ | unklar, wird eigentlich nicht verwendet
außer auf den Profilseiten, und dort macht es Probleme |
Nutzer registrieren | ❌ | ❌ | ✅ |
Aktuelle Umsetzung
- Template Namensraum Editieren ist speziell geschützt
$wgNamespaceProtection[NS_TEMPLATE] = array( 'edit-template' );
Hinweise
- Anonyme Besucher
- können NICHT schreiben
$wgGroupPermissions['*']['edit'] = false;
- können NICHT registrieren
$wgGroupPermissions['*']['createaccount'] = false;
- können NICHT den Editierenknopf sehen
$wgGroupPermissions['*']['viewedittab'] = false;
- können lesen
$wgGroupPermissions['*']['read'] = true;
- können ein paar spezielle Seiten anschauen
$wgWhitelistRead = array( $wgMetaNamespace.':Datenschutz', $wgMetaNamespace.':Über '.$wgSitename, $wgMetaNamespace.':Impressum' );
- können NICHT schreiben
- Angemeldete Benutzer
- können lesen _Christian: unklar warum das gebraucht wird; sollte ja durch
['*']['read'] = true;
bereits erledigt sein_$wgGroupPermissions['user']['read'] = rue;
- können editieren _Christian: unklar warum das gebraucht wird. Ich vermute für VE_
$wgGroupPermissions['user']['writeapi'] = true;
- können replacetext verwenden _Christian: das scheint mir nicht so schlau_
$wgGroupPermissions['user']['replacetext'] = true;
- kann Seiten löschen _Christian: eigenartig_
$wgGroupPermissions['user']['delete'] = true; $wgGroupPermissions['user']['import'] = true; $wgGroupPermissions['user']['importupload'] = true;
- können lesen _Christian: unklar warum das gebraucht wird; sollte ja durch
- Lernpfadprofi
- kann Template Namensraum editieren
$wgGroupPermissions['lernpfadprofi']['edit-template'] = true;
- kann Template Namensraum editieren
- Sysops und Co
- kann Template Namensraum editieren
$wgGroupPermissions['sysop']['edit-template'] = true;
- kann Template Namensraum editieren
Neues Schema
- Anonyme Besucher
- kann sich selber registrieren
- Angemeldete Nutzer + verifizierte E-Mail
- kann nur eigene Benutzerseite bearbeiten
- kann Diskussionsseiten bearbeiten
- ZUM-Unterrichten Helfer
- Schüler sind ausgeschlossen
- ZUM-Unterrichten Autor
- Autorencheck
anonym | angemeldet | Helfer | Autor | sysops + co | Anmerkung | |
---|---|---|---|---|---|---|
Lesen bestimmter Seiten | ✅ | ✅ | ✅ | ✅ | ✅ | |
Lesen im Haupt-NS | ✅ | ✅ | ✅ | ✅ | ✅ | |
Lesen im Benutzer-NS | ✅ | ✅ | ✅ | ✅ | ✅ | |
Kann Seitenbewertung lesen | ✅ | ✅ | ✅ | ✅ | ✅ | z.B. Extension:VoteNY |
Schreiben im Benutzer-NS | ❌ | ✅ | ✅ | ✅ | ✅ | nur die eigene Benutzerseite
evtl. via Extension:UserPageEditProtection |
Diskussionseiten sehen | ❌ | ✅ | ✅ | ✅ | ✅ | |
Diskussionseiten bearbeiten | ❌ | ✅ | ✅ | ✅ | ✅ | |
Kann Ideen lesen | ❌ | ❌ | ✅ | ✅ | ✅ | z.B. Extension:InlineComments |
Kann Ideen posten | ❌ | ❌ | ✅ | ✅ | ✅ | z.B. Extension:InlineComments |
Kann Seitenbewertung abgeben | ❌ | ❌ | ✅ | ✅ | ✅ | z.B. Extension:VoteNY |
Schreiben im Vorlagen-NS | ❌ | ❌ | ❌ | ✅ | ✅ | via $wgNamespaceProtection
|
Schreiben im Haupt-NS | ❌ | ❌ | ❌ | ✅ | ✅ | via $wgNamespaceProtection
|
Seiten Löschen | ❌ | ❌ | ❌ | ✅ | ✅ | |
PageForms bearbeiten | ❌ | ❌ | ❌ | ❌ | ✅ | |
Nutzer registrieren | ❌ | ❌ | ❌ | ❌ | ✅ | |
Editier-Knopf sichtbar | ❌ | ❌ | ❌ | ❌ | ✅ | |
Replacetext nutzen | ❌ | ❌ | ❌ | ❌ | ✅ |
Problem: jeder Namensräume (auch durch Extensions neu hinzumkommende) müssen wir erstmal schützen mittels $wgNamespaceProtect
und dann die Gruppen zum-helfer und zum-autor berechtigen darauf zuzugreifen.
Mögliches Vorgehen
Das größte Hindernis ist, die Tatsache, dass standardmäßig nahezu alle Namensräume von der Gruppe user
editierbar sind und jeder angemeldete Nutzer immer in der Gruppe user
ist und auch nicht aus ihr entfernt werden kann. Ziel der Änderungen ist es daher, die meisten Namensräume mittels $wgNamespaceProtect
mit neuen Rechten (zum-permission-*
) zu schützen und diese neuen Rechte an neue Gruppen (zum-group-*
) zu vergeben. Diese neuen Gruppen werden dann von den bisherigen Administratoren an die Nutzer vergeben die die jeweiligen Bedingungen erfüllen.
- Das neue Recht
zum-permission-verified
. wird eventuell nicht benötigt, je nachdem wie die Extensions für das Ideensystem und die Seitenbewertung funktionieren.- wird an die neue Gruppe
zum-group-helfer
undzum-group-autor
verliehen, sowie ansysop
. - erlaubt den Zugang zu den Funktionen für das Ideensystem und Seitenbewertungssystem
- Vergabe erfolgt manuell durch bestehende ZUM-Unterrichten Administratoren
- wird an die neue Gruppe
- Das neue Recht
zum-permission-autor
.- wird an die neue Gruppe
zum-group-autor
verliehen, sowie ansysop
. - erlaubt den Editierzugriff auf Haupt- und Vorlagennamensraum (TBD)
- Vergabe erfolgt manuell durch bestehende ZUM-Unterrichten Administratoren
- entspricht den Berechtigungen die im alten System der Gruppe
user
zustanden
- wird an die neue Gruppe
- Zusätzlich wird E-Mail Bestätigung Pflicht bevor editierrechte ausgeübt werden können
- Zusätzlich werden Editierberechtigungen im Benutzernamensraum auf die eigene Benutzerseite beschränkt
- Absehbar ist, eine weitere Berechtigung für "ZUM-Superautoren" die dann auch andere Benutzerseiten ändern können und evtl. müssen wir das Vorlagenveränderungsrecht auch dort hinschieben.
Ablauf
- Einführung einer neuen Gruppe
zum-group-helfer
- Einführung einer neuen Gruppe
zum-group-autor
- alle existierende Nutzern in die Gruppe
zum-group-helfer
undzum-group-autor
aufnehmen- per API
- Bei der Installation muss an
zum-group-helfer
gedacht werden.# Bei der Installation des Ideensystems und des Seitenbewertungssystems # die Berechtigungen beachten und nicht einfach der `user` Gruppe überlassen # Wenn die Extension an Gruppen geknüpft werden (weil sie eigene Rechte mitbringen) ## -> die Rechte den zum-group-helfer, zum-group-autor und sysop Gruppen zuweisen und der Gruppe `user` entziehen # Wenn die Extension an Namensräume geknüpft werden ## -> Namensräume mittels $wgNamespaceProtect durch die Berechtigung zum-permission-verified schützen ## das kann keine Leserechte verhindern
- ⁉️ mittels
$wgNamespaceProtect
die Namensräume MAIN, TEMPLATE vor Änderungen schützen mit der Berechtigung (zum-permission-autor
)$wgNamespaceProtect[NS_MAIN][]='zum-permission-autor'; $wgNamespaceProtect[NS_TEMPLATE][]='zum-permission-autor';
- ⁉️ die neue Berechtigung
zum-permission-verified
den Gruppenzum-group-autor
/zum-group-helfer
undsysop
zuweisen.$wgGroupPermission['zum-group-helfer']['zum-permission-verified'] = true; $wgGroupPermission['zum-group-autor']['zum-permission-verified'] = true; $wgGroupPermission['sysop']['zum-permission-verified'] = true;
- ⁉️ die neue Berechtigung
zum-permission-autor
den Gruppenzum-group-autor
undsysop
zuweisen.$wgGroupPermission['zum-group-autor']['zum-permission-autor'] = true; $wgGroupPermission['sysop']['zum-permission-autor'] = true;
- Extension:UserPageEditProtection installieren und einrichten
- Editieren nur mit bestätigter Email-Adresse
$wgEmailConfirmToEdit = true; $wgEmailAuthentication = true;
- edit Berechtigung für
user
Gruppe entfernen$wgGroupPermissions['user']['edit'] = false;
- Meilenstein Jetzt können wir die Registrierung öffnen
- Selbst registrierende Nutzer können nur auf eigener Benutzerseite arbeiten
- bestehende Autoren können weiterhin überall arbeiten
- replacetext wieder auf sysop einschränken
- ❓PageForm aus UserProfile mechanismus entfernen