Mehrere Autoren

[beate_r]

Hallo in die Runde,

in meinem derzeitigen Projekt (der ex-Drupal-Site) steht jetzt doch die Frage mehrerer gleichberechtigter Autoren im Raum. Die Security-Anforderungen sind gering, im Prinzip dürfen und sollen alle Autorinnen Admin-Rechte besitzen. Ein KISS-Lösung ist in diesem Fall vollkommen ausreichend.

Zur Debatte stehen folgende Alternativen:

Passwort-Sharing ohne zusätzliche Module. Login funktioniert von mehreren Rechnern aus gleichzeitig.
Aber was geschieht beim Abspeichern der Seiten? Gibt es die Gefahr von Datenverlusten, wenn zwei Autoren unterschiedliche Seiten im CMS bearbeiten und diese dann speichern, besonders in bezug auf den von den anderen Autoren bearbeiteten Code?

Was passiert, wenn eine der Autorinnen sich ausloggt? Bleiben die anderen Sessions erhalten?

Ansonsten benötige ich doch vermutlich das register-Plugin in passender Version, nicht wahr?

Was ich in diesem Fall überhaupt nicht gebrauchen kann, sind unterschiedliche Content-Dateien pro User. Es sollen immer alle auf den gleichen Datenbestand zugreifen, also die content.htm bzw. in Zukunft auch irgendwelche Daten in Blogs oder Gästebüchern.

Danke schon mal für Tipps.

[cmb]

Hallo Beate,

Aber was geschieht beim Abspeichern der Seiten? Gibt es die Gefahr von Datenverlusten, wenn zwei Autoren unterschiedliche Seiten im CMS bearbeiten und diese dann speichern, besonders in bezug auf den von den anderen Autoren bearbeiteten Code?

Gespeichert wird bei CMSimple immer der gesamte Content. Und da liegt schon mal ein großes Problem, wenn mehrere Autoren gleichzeitig am Werk sind. A ruft eine Seite zur Bearbeitung auf, dann B eine andere. A speichert zuerst ab, dann B. Und schwupps sind die Änderungen von A völlig überschrieben. Noch heikler kann es werden, wenn A und B quasi zeitgleich speichern. CMSimple setzt keinen File-Lock, und was dann am Ende bei rauskommt kann evtl. ein total korrumpiertes content.htm sein. Auf jeden Fall sind dann auch Probleme mit der pagedata.php zu befürchten (evtl. content.htm von A und pagedata.php von B).

Um davor zu schützen, wird schon seit einer Weile ein sog. Login-Lock-Plugin entwickelt. Allerdings wurde es noch nicht veröffentlicht.

Was passiert, wenn eine der Autorinnen sich ausloggt? Bleiben die anderen Sessions erhalten?

Ja, das ist kein Problem, da die Anmeldeinfos entweder als Cookie gespeichert werden, oder per WWW-Authenticate immer wieder vom jeweiligen Browser übermittelt werden.

Was ich in diesem Fall überhaupt nicht gebrauchen kann, sind unterschiedliche Content-Dateien pro User.

Schade, denn dann hätte man es wohl recht praktikabel mit dem Subsite-Feature von XH 1.5 abbilden können.

Ansonsten benötige ich doch vermutlich das register-Plugin in passender Version, nicht wahr?

Mit Register bzw. Memberpages können nur einzelne Seiten des Front-Ends für verschiedene User zugänglich gemacht oder gesperrt werden. Die Bearbeitung von Seiten ist damit aber nicht möglich. Das kann man prinzipiell mit simpleMultiUser v. 1.1 oder Subadmin machen. Die Lösungen scheiden in Deinem Fall aber aus, da die Redakteure keinen Back-End Zugriff haben.

Die einzige Lösung, die ich für die genannten Anforderungen sehe, ist also allen Redakteuren das Admin-Kennwort zu geben, und den gleichzeitigen Zugriff per Login-Lock-Plugin zu verhindern.

Daher @Martin: ist der Login-Lock bereits so weit, dass er veröffentlicht werden könnte? Ich warte nämlich auch schon sehnsüchtig darauf.

Christoph

[beate_r]

Hallo Christoph,

es ist also genau so, wie ich es erwartet habe.

Nach einem kurzen Blick auf die Plugin-Beschreibungen werden mir das weder Subadmin noch SMU helfen, weil beide Module separaten Content pro User verwenden. Ich benötige jedoch, dass alle (drei) Autorinnen auf alles Zugriff haben.

Bleibt also intelligentes Locking und ggf. ein überarbeiter Algorithmus beim Schreiben, der sicherstellt, dass der Inhalt, der sich gerade im Editor befindet, in die jeweils aktuelle content.htm eingefügt wird und diese während der Aktualisierung für das Schreiben lockt. Außerdem würde noch ein seitenspezifischer Schreib-Lock-benötigt, wenn Nutzer eine Seite in den Editor lädt.

Wenn das CMS auf irgendwann einmal diese Weise erweitert würde, sollte das m.E. Plugin bleiben, um das System für den allegemeinen Einsatz nicht übermäßig aufzublähen. Das, was mich momentan ein wenig stört, ist ja eine der Stärken, die das CMS in seinem klassischen Einsatzgebieten hat. Simple and smart.

Anyway - jede Form von Locking wäre schon mal ein großer Fortschritt. Weil wir eine Trennung in Entwicklungs- und Produktivsystem haben werden, könnte ich ein derartiges Plugin auf ersterem auch in Ruhe testen.

Beate

die im übrigen im Lauf dieses Jahres u.U. noch zwei weitere Seiten in CMSimple erstellen könnte. Eine ebenfalls als Multiuser... und wenn das nicht klappen sollte, würde ich dann allerdings ein größeres CMS benötigen.

[cmb]

Hallo Beate,

weil beide Module separaten Content pro User verwenden

Der Subadmin schreibt schon direkt in die gemeinsame content.htm. Allerdings ist Subadmin nicht speziell auf CMSimple_XH ausgelegt (ich weiß nicht, ob dann auch die Pagedata passend synchronisiert wird, wenn z.B. Seiten neu erstellt werden). Und ich weiß nicht, ob beim Subadmin ein entsprechendes Locking implementiert wurde.

Bleibt also intelligentes Locking und ggf. ein überarbeiter Algorithmus beim Schreiben, der sicherstellt, dass der Inhalt, der sich gerade im Editor befindet, in die jeweils aktuelle content.htm eingefügt wird und diese während der Aktualisierung für das Schreiben lockt. Außerdem würde noch ein seitenspezifischer Schreib-Lock-benötigt, wenn Nutzer eine Seite in den Editor lädt.

Das sollte prinzipiell funktionieren. Aber da gibt es bei CMSimple das große Problem, dass Seiten keine ID haben, sondern einfach forlaufend nummeriert werden. Lädt nun A Seite 3 zum Bearbeiten, und in der Zwischenzeit löscht B Seite 2, gibt's schon Probleme. Das ließe sich wohl nur lösen, wenn im Content für jede Seite eine ID mitgeführt wird, die sich nie ändert. Das, und auch manches weitere, ließe sich aber nicht durch ein Plugin lösen; da müsste bereits der Core entsprechende Möglichkeiten anbieten. Aber auch dann dürfte es Probleme mit Plugins geben, die den Content selbst bearbeiten (Menumanager, Pagemanager und sicher noch das ein oder andere mehr); diese müssten zumindest angepasst werden. Aber selbst wenn das alles passierte, so blieben vermutlich doch noch weitere Probleme:

1. Alsbald wird dann vermutlich der Ruf nach einem (einfachen) Rollensystem mit Rechtevergabe aufkommen.
2. Wenn mehrere Redakteure am gleichen Content arbeiten, wird dieser in der Regel umfangreicher sein, als wenn es nur ein einzelner tut. Und da gibt es bei CMSimple ja gewisse Grenzen: wenige MByte content.htm sind sicherlich kein Problem, aber dann wird es allmählich problematisch, was die Performance angeht (die Suche kann dann schnell mal 30 sec dauern)
3. Auch andere Dateien müssten per Lock gesichert werden (z.B. config.php und Sprachdateien, auch von Plugins). Und ein Locking ist mit PHP auch nicht ganz so einfach. flock() ist zwar im Sprachkern verankert und ist leicht nutzbar, klappt aber z.B. bei multithreaded IIS nicht.

Ich denke, eine allgemeine Multiuserfähigkeit passt daher nicht zu CMSimple (und vermutlich allgemein nicht für flat-file basierte CMS).

Der Login-Lock ist bei mehreren Admins sicher ein gangbarer Weg, wenn diese eben nicht parallel arbeiten müssen. Ansonsten kann SMU ja prinzipiell schon jetzt als eine Art Redaktoren-System angesehen werden. Der Redakteur schreibt seinen eigenen Content, und wenn der Chefredakteur (nur dieser hat Adminrechte) es für gut befindet, kann er den Artikel in den Content übernehmen. Derzeit nur per Copy&Paste, aber da ließe sich vermutlich etwas machen.

Christoph

[beate_r]

Hallo Christoph

Ich denke, eine allgemeine Multiuserfähigkeit passt daher nicht zu CMSimple

Das sehe ich im Grunde genauso. Deshalb habe ich oben ja auch so gut es ging den Konjunktiv verwendet. CMSimple ist für einen bestimmten Einsatzzweck ideal - und wenn die Anforderungen andere sind, muss man sich halt irgendwie helfen oder ein anderes CMS verwenden. Weil ich mich auch mal ein wenig mit UBB beschäftigt habe (einem flatfile-basierten Forum), will ich auch gar nicht, dass CMSimple allzu stark in Richtung Multiuser aufgebohrt werden sollte.

Für mich war daher zuallererst einmal die Bestätigung meiner Einschätzung wichtig, dass es zu Datenverlusten kommen kann, wenn mehrere Nutzer gleichzeitig in die content.htm schreiben wollen. Das konnte ich kommunizieren. Als erste Hilfe haben wir gerade "Locking per email-Benachrichtigung" verabredet.

Der Login-Lock ist bei mehreren Admins sicher ein gangbarer Weg, wenn diese eben nicht parallel arbeiten müssen.

Und das wird bei dieser Seite organisatorisch leicht zu realisieren sein. Ein bewusst einfach gehaltener technischer Schreib-Lock wäre allerdings hilfreich - Du weisst, der Teufel ist ein Eichhörnchen...

[beate_r]

Darf ich das nochmal aufgreifen und direkt nach dem oben erwähnten Stand einer Implementierung von Locking fragen?

Nach meinem Verständnis kann das eigentlich kaum von einem Plugin geleistet werden, sondern es muss in den Core.

Jetzt, aus der Erfahrung im Umgang mit dem Notbehelf heraus kann ich sagen, dass das zwar als Notlösung funktioniert, aber unschön ist. Ein Schreib-Lock, der beispielsweise an eine beim Login erzeugte Session geknüpft ist, wäre eine schöne Sache.

Ach so, die Situation, dass mehrere Leute Schreibzugriff auf eine Webseite haben, ist wohl gar nicht sooo selten. Ich habe zur Zeit drei Seiten, in denen das der Fall ist. Sie tritt immer dann auf, wenn man seinen Auftraggeber in die Lage versetzt, seine Inhalte selbst änern zu können, ohne dies vollständig zu delegieren.

LG

Beate

[cmb]

Hallo Beate,

Nach meinem Verständnis kann das eigentlich kaum von einem Plugin geleistet werden

Das besagte Login-Lock-Plugin verrichtet testweise seit einigen Monaten seinen Dienst auf http://cmsimple-xh.com/roadmap/. Und das klappt sehr gut. Natürlich herrscht dort kein reges Treiben, aber tatsächlich wurden schon Login-Versuche abgewiesen, wenn bereits ein anderer dort eingeloggt war. Kürzlich wurde ein kleiner Bug gefunden und gefixt, der wohl nur beim Chrome auftritt. Das Plugin wird wohl in den nächsten Tagen veröffentlicht werden.

Wie es genau funktioniert, kann ich nicht sagen, aber im Prinzip läuft es so: ist erst mal ein User eingeloggt, kann sich kein anderer anmelden. Bleibt aber der eingeloggte User für eine bestimmte Zeit inaktiv (weil er vielleicht einfach vergessen hat, sich abzumelden), "flieg er raus". Ab dann kann sich dann wieder ein anderer einloggen.

Und wenn das korrekt implementiert ist, wovon ich ausgehe, da Martin ein sehr fähiger Entwickler ist, der sich darüber hinaus sehr gut mit CMSimple auskennt, halte ich das für eine saubere und sichere Lösung.

Das einzige Manko: es kann eben immer nur Admin aktiv sein.

Ein Schreib-Lock, der beispielsweise an eine beim Login erzeugte Session geknüpft ist, wäre eine schöne Sache.

Das Problem ist derzeit, dass der CMSimple-Core keine Session eröffnen darf! Zunächst einmal muss der Plugin-Loader die required_classes der Plugins include()n, damit in der Session abgelegte Objekte auch korrekt initialisiert werden können. Das ist auch das eigentliche Problem, warum wir die Login-Sicherheit noch nicht wirklich verbessern konnten (auch dafür wäre der Session-Start beim Login, also bevor der Pluginloader dran ist, erforderlich). Um das zu ermöglichen muss also der Pluginloader, zumindest teilweise, in den Core integriert werden. Und das kostet Entwicklungszeit, die wir bisher noch nicht aufbringen konnten. Und für XH 1.5.x ist das auch nicht mehr vorgesehen, weil solch umfangreiche Änderungen erst gründlich getestet werden müssten, und weitere "x" (also Patches) nur noch Bugs beheben sollen. Diese Änderung wird also erst mit der nächsten Version erfolgen können.

Bis dahin muss das Login-Lock-Plugin genügen. Natürlich kann das nicht absolut perfekt sein: zwischen Login und Plugin-Aufruf vergehen ein paar Millisekunden, in denen theoretisch ein weiteres Login erfolgen könnte: aber die Wahrscheinlichkeit dessen ist zumindest extrem gering. Und selbst wenn der Lock direkt nach dem Login erfolgen würde, blieben noch einige Mikrosekunden, in denen der Lock umgangen werden könnte. Ein Problem, das in der Praxis aber wohl vernachlässigt werden kann/muss.

Und um die naheliegende Frage "warum wurde statt einer verbesserten Login-Sicherheit, der Wechsel zu einem anderen Editor (inkl. neuem Editor-Filebrowser-Interface) vorgezogen" schon mal vorab zu beantworten: der alte "FCKeditor" funktioniert leider nicht mehr unter IE9. Die Alternativen (also tinyMCE und CKeditor) stellen keinen Filebrowser unter GPL (oder anderweitig kompatibler Lizenz) zur Verfügung. Und das war eben leider das dringlichere Problem, das viel Zeit gekostet hat, zumal wir uns nicht wieder auf einen Editor festlegen wollten, den dann vielleicht das gleiche Schicksal ereilt.

Und ganz ehrlich: das CMSimple_XH-Team besteht aus gerade mal 5 Leuten (+ Holger, der kräftig mithilft), die aber allesamt damit direkt kein Geld verdienen, so dass die Weiterentwicklung eben leider in der Freizeit erfolgen muss. Also erwartet bitte nicht, dass wir all die kleinen Schwächen von CMSimple in relativ kurzer Zeit beheben können.

@all: wer also mithelfen möchte ist herzlich Willkommen! (Dokumentation, Übersetzungen, Programmierung, und und und)

Christoph

[beate_r]

Daher @Martin: ist der Login-Lock bereits so weit, dass er veröffentlicht werden könnte? Ich warte nämlich auch schon sehnsüchtig darauf.

Oder zumindest zum Testen zur Verfügung gestellt werden?

Die von Christoph als stabil funktionierend geschilderte Funktionalität wäre ja bereits ein Gewinn. Im Fall der Fälle kann ich mir wohl ganz gut selbst helfen, und ggf. auch von außen ins System eingreifen, wenn eine Reparatur notwendig werden sollte.

Beate

[Martin]

Hallo,

hier mal ein Link zu einer Beta-Version des Loginlockers: http://zeichenkombinat.de/loginlocker.zip.

Was er tut (oder tun soll):

• Sobald sich ein Admin anmeldet, wird der Backendzugriff für alle anderen gesperrt. Sie werden auf den Grund dieser Sperre hingewiesen.
• Für den Fall, dass der Admin das Abmelden vergisst, wird er nach einer konfigurierbaren Zeit der Untätigkeit wieder automatisch abgemeldet.
• Für den Fall, dass der Admin gar nicht "untätig" ist, vielleicht lange an einem Text feilt oder sonstwie nachdenkt ohne mit der Server zu kommunizieren, wird er (eine einstellbare Zeit) vorher darauf hingewiesen, ein Countdown startet und er hat die Chance seine Sitzung zu verlängern.

Technisch funktioniert es im Prinzip so: Im Plugin-Verzeichnis liegt eine Datei "lock.txt". Sobald eine Admin angemeldet ist, wird sie bei jedem Seitenaufruf angesprochen (touch()). Andere können sich erst wieder einloggen, wenn diese letzte "Berührung" länger als die erlaubte Zeit der Untätigkeit zurückliegt oder in der Datei "logged-out" steht, was beim Ausloggen hineingeschrieben wird.

Für diese Datei müssen also Schreibrechte gesetzt werden. Der Rest der "Installation" ist das CMSimple-Übliche.

LG

Martin

[cmb]

Hallo Martin,

hier mal ein Link zu einer Beta-Version des Loginlockers

Ich teste gerne mal mit (dürfte ja mit verschiedenen Browsern funktionieren).

Für diese Datei sollten also Schreibrechte gesetzt werden. (Wenn nicht, ist es wahrscheinlich auch nicht schlimm. Die anderen müssen nur ein bisschen länger warten.)

Braucht nicht auch touch() Schreibrechte?

Christoph