Doku zum access_control Plugin
Kurzbeschreibung
Dieses Plugin erweitert das CMS um ein Mehrbenutzer-Loginsystem mit benutzerabhängigem Menü- und Seitenumfang.
Es werden folgende Funktionen bereitgestellt:
- Anmelden und Abmelden von verschiedenen registrierten Benutzern mit Benutzername und Passwort über ein Loginformular mit Anzeige des aktuell angemeldeten Benutzers
(Info: beim Passwort wird auf Groß-/Kleinschreibung geachtet, beim Benutzernamen nicht)
- Festlegung der Login-Gültigkeitsdauer entweder gemäß Webserver-Session-Timeout oder individuell für jeden Benutzer mit Hilfe von Cookies
- Beschränkung ganzer Kategorien oder auch nur bestimmter Seiten innerhalb einer Kategorie entsprechend der Rechte des angemeldeten Benutzers
- Einfache Verwaltung der Benutzer, Passwörter und Zugangsbereiche über das Plugin-Backend
- Gebookmarkte geschützte Seiten werden unmittelbar nach Login geladen, ohne Login erscheint die Standard-Startseite
- Das Anmeldeformular kann entweder analog zur Seiten-Suche im Layout-Template oder in einer beliebigen Inhaltsseite eingefügt werden.
Soll das Loginformular nur "Insidern" zugänglich sein, so kann man es auch in eine versteckte Inhaltsseite einfügen, welche nur dem entsprechenden Besucherkreis bekannt ist.
- Die Zugangsbeschränkung basiert darauf, dass dem CMS nicht erlaubte Seiten bereits beim Einlesen des Dateisystems vorenthalten werden.
Daher greift die Beschränkung auch für Funktionen wie Suche oder Sitemap.
Zur Ermöglichung dieses tiefen Eingriffs wird bei Aktivierung des Plugins die Haupt-index.php gepached.
- Der Admin kann für jeden Benutzer festlegen, ob dieser sein Passwort (via Formular im Frontend) selbst ändern darf oder nicht.
- Optional werden Anmeldeversuche protokolliert, wiederum optional zusätzlich Benachrichtigungs-Emails verschickt
- Das ganze sollte auch mit mod_rewrite zusammenarbeiten
- Die Login-Logik inkl. Benutzerverwaltung kann einfach auch für andere Plugins mitgenutzt werden (s.u.).
Voraussetzungen
- Auf dem Rechner der Webseiten-Besucher müssen Cookies zugelassen sein, ansonsten funktionieren nicht einmal Sessions.
- Das Plugin wurde unter PHP5 getestet, die Funktion unter PHP4 wurde vom Autor nicht getestet (rolinux hat aber im Forum für v1.0 ein positives Feedback bzgl. PHP4 gegeben).
- Das Plugin wurde bislang unter Mozilo 1.12.beta3 getestet. Prinzipiell sollte es mit Folgeversionen funktionieren, wenn die Schlüsselstellen für den Patch noch vorhanden sind und sich an der grundlegenden Arbeitsweise von moziloCMS nichts ändert.
Einschränkungen
- Es handelt sich im Gegensatz zum Verzeichnis-/Dateischutz mittels .htaccess um einen "weichen" Zugangsschutz. Es besteht weiterhin die Möglichkeit, durch Aufruf der Inhaltsseiten-Textdateien an den Inhalt der Seite zu kommen, wenn man denn den vollständigen Dateinamen kennt.
- Werden viele Seiten geschützt, so muss für jede Seite überprüft werden, ob der Benutzer die nötigen Berechtigungen hat. Diese Überprüfung erfolgt programmtechnisch bedingt mehrmals bei jedem Seitenaufbau.
Da hinter Mozilo eine plain-text-Datenbank liegt, sind andere Funktionen des CMS ebenfalls nicht übermäßig performant. Für überschaubare Webprojekte ist mozilo aber unschlagbar genial und die evtl. Performanceeinbußen gegenüber einem SQL-System sind für den Besucher nicht merkbar...
- Es wird empfohlen, eher wenige Benutzergruppen als viele Einzelbenutzer anzulegen.
Installation
- Optional: Die Haupt-index.php des CMS sichern (diese wird bei Aktivierung automatisch gepached). Wurde index.php nicht manuell modifiziert, so kann das Backup entfallen und im Bedarfsfall wieder die originale index.php verwendet werden.
- Das Verzeichnis access_control (= dieses Plugin) in das plugins-Verzeichnis kopieren
- Entweder:
In das HTML-Template im verwendeten Layout mit {access_control|loginform} ein Login-Formular analog zum Standard-Suchformular einbinden.
Es kann sogar analog zum Such-Formular in einen <div class="search">-Bereich eingebettet werden.
Oder:
Das Login-Formular mit {access_control|loginform} in eine beliebige Inhaltsseite einbinden.
- Auf der Plugin-Konfigurationsseite in der Admin-Ansicht das Plugin aktivieren. Damit wird die Haupt-index.php an drei Stellen (davon einmal nur ein Kommentar) gepached.
Es werden nur (wenige) zusätzliche Zeilen eingefügt, diese Zeilen sind am Zeilenanfang jeweils mit /*AC*/ gekennzeichnet.
Info: Der Patch wird rückggängig gemacht, wenn das Plugin wieder deaktiviert wird.
- Dringend empfohlen: access_control-Verzeichnis via .htaccess schützen, sodass die Konfigurations- und Logdatei nicht von extern abgerufen werden können
- Optional: Alle .txt-Dateien im kategorien-Verzeichnis via .htaccess schützen (bislang nicht getestet).
- Kategorien/Seiten schützen, indem als letztes Zeichen des Namens ein ' (Hochkomma) angegeben wird. Solange die index.php gepached ist, werden derartig benannte Kategorien/Seiten grundsätzlich erst einmal nicht angezeigt und überprüft, ob der aktuell angemeldete Benutzer über entsprechende Zugriffrechte verfügt.
Alle Seiten ohne ' sind vom Plugin nicht betroffen. Für Direktlinks sind untenstehende Hinweise hilfreich.
- Plugin im Plugin-Backend konfigurieren (Benutzer anlegen und ihnen Rechte zuweisen)
Verwendung
Eine Übersicht inkl. Kurzbeschreibung aller verfügbaren Funktionen sowie eine Beschreibung der Plugin-Einstellungen ist im Backend zu finden.
Direktlinks im Menü
Ein Schutz von Kategorien oder Inhaltsseiten, die lediglich einen Menü-Direktlink enthalten, ist nicht möglich, da der Datei- bzw. Verzeichnisname nicht mit dem Kategorie-/Seitennamen und damit nicht mit dem Hochkomma endet.
Hierfür gibt es z.B. den Workaround, dass in die erste Seite einer Kategorie bzw. in eine beliebige Standard-Inhaltsseite ein Redirect eingefügt wird.
Dafür kann man z.B. das folgende benutzerdefinierte Syntaxelement verwenden:
redirect = <META HTTP-EQUIV="refresh" CONTENT="0; URL={VALUE}" target="_blank">Weiter zu [link={VALUE}|{VALUE}...]
Verwendung in der Inhaltsseite: [redirect|http://www.xyz.de]
API - Mitbenutzung der Login-Logik und Benutzerverwaltung in anderen Plugins
Hierfür existieren im wesentlichen zwei Alternativen:
- Durch {access_control|current_user} wird der verifizierte Name des aktuell angemeldeten Benutzers zurückgegeben.
"Verifiziert" bedeutet, dass Cookie-Tweaking etwas erschwert wurde.
Der obige Aufruf kann einfach im Argument eines anderen Plugins enthalten sein, sodass diesem zur Weiterverarbeitung der Name des aktuell angemeldeten Benutzers übergeben wird.
- In der function getContent($value) der Plugin-index.php kann einfach ein GLOBAL $AC_CURRENT_USER; eingefügt werden und dann der Benutzername aus der betreffenden Variable ausgelesen werden.
Patch-Philosopie - musste das sein?
Dieses Plugin wäre ohne Patch der index.php nicht in dieser Form realisierbar.
Durch Eingriff in die index.php erstreckt sich die Kontrolle auch auf Funktionen wie Suche oder Sitemap.
Auch das Standardverhalten, dass durch den Zugangsschutz für manche Benutzer "leergewordene" Kategorien gar nicht erst angezeit werden oder dass bei "Nichtvorhandensein" einer Inhaltsseite einfach die Standard-Inhaltsseite der entsprechenden Kategorie angezeigt wird, wird dadurch genutzt.
Die Einbindung der eigentlichen Login-Logik wäre prinpzipiell auch innerhalb der index.php des Plugins möglich (wie dies z.B. bei den Funktionen {access_control|md5helper} oder {access_control|passwordchangeform} realisiert ist), die Auswertung darf in diesem speziellen Fall aber nicht erst bei Einbindung des Plugins oder Einlesen des Templates erfolgen, sondern die Benutzer- und Zugriffsinfos müssen schon früher bekannt sein.
Der Patch arbeitet bis auf die Stelle, an der die Kategorien und Seiten aus der Verzeichnisstruktur bestimmt und gefiltert werden, trotz zweier Include-Dateien in die index.php für sich alleine, auch Variablennamen sind meist mit vorangestelltem ac_, um sie eindeutig zu halten.
Nichtsdestotrotz empfiehlt es sich, den Patch bei der Fehlersuche an anderen Baustellen oder bei Erstellung eines neuen Problemthreads im Forum nicht völlig ausser Betracht zu lassen!
Tritt der Fehler trotz deaktiviertem Plugin auf, dann ist access_control höchstwahrscheinlich nicht der Schuldige.
Versions-Historie
Version 1.0 / 19.11.2010 / M. Hauser (mhsob)
- Erstausgabe des Mehrbenutzer-Loginsystems als Plugin
Version 2.0 / 27.11.2010 / M. Hauser (mhsob)
- Bugfix: vergessenes {access_control|doku} aus Plugin-Dropdown-Liste bei Inhaltsseitenbearbeitung
gelöscht
- Performance verbessert (merkt man wahrscheinlich eh nicht...)
Die accesslist wird für aktuellen Benutzer am Anfang gleich auf die für ihn freigeschalteten
Kategorien/Inhaltsseiten gekürzt -> 1x etwas mehr Verarbeitungsaufwand, bei den wiederholten
Folgeaufrufen ist dann deutlich weniger Stringsuche nötig
- Wird für eine Seite der Benutzer "any_login" angegeben, so muss fuer die Anzeige der Seite
einfach nur irgendein registrierter Benutzer angemeldet sein.
- Plugin-Funktion zur Rückgabe des verifizierten aktuell angemeldeten Benutzers implementiert
Der Name kann auf einer Seite ausgegeben werden oder über als Teil des Aufrufs an andere Plugins
übergeben werden.
- Implementierung einer sehr einfachen "API", welche die Verwendung des aktuell angemeldeten
Benutzers in anderen Plugins ermöglicht.
- Erweiterung der Befehlssyntax um ein Formular zur Änderung des Benutzerpassworts im Frontend
(vom Admin für jeden Benutzer extra freischaltbar)
- Erweiterung der Befehlssyntax um ein kleines Formular zur MD5-Codierung von Passwörtern
- Erweiterung der Doku im Backend und Aufnahme der Dokus für die Benutzer- und Zugriffsliste
in den Plugin-Beschreibungstext (kann in Version 1.1 aus den eigentlichen Eingabefeldern gelöscht
werden)
- Im Vergleich zu v1.0 muss nicht mehr für einen Benutzer eine Kategorie alleine extra freigegeben
werden, wenn er für die betreffende Kategorie inkl. einer Unterseite freigeschaltet ist.
- UPDATE-EMPFEHLUNG:
* Alles vom neuen access_control Plugin Verzeichnis überschreiben, nur die plugin.conf belassen
* Aus der plugin.conf können bei Benutzer- und Zugriffsliste die Kommentarzeilen größtenteils
über das Backend entfernt werden, da die Doku jetzt in der Beschreibung im Backend enthalten
ist
Version 2.0.1 / 03.12.2010 / M. Hauser (mhsob)
- Anpassung der Patch-Routine an stefanbe's beta3 Rev. 801 (aus dem Forum)
-> funktioniert jetzt mit .beta3 und mit der neuen Spielversion