WBCE CMS – Way Better Content Editing.
You are not logged in.
Mehrere der von mir betreuten Schulhomepages haben interne Bereiche für die Eltern. Die sollen nur ein Passwort eingeben müssen und nicht auch den Loginnamen, außerdem dürfen sie natürlich nicht die persönlichen Einstellungen des Elternzugangs ändern können. Dazu sind einige Eingriffe in den Dateien notwendig, welche bei jedem Update wieder überschrieben werden und sich teils auch geändert haben. Hier im Forumsarchiv dazu mehr. Funktioniert, aber ich habe dadurch kaum Lust, die Updates mal schnell draufzubügeln und schiebe die notwendigen Anpassungen vor mir her. Ich brauchte also eine andere Lösung, die den Core nicht tangiert, und mit Hilfe der KI habe ich diese gefunden und gebaut:
SimplyPWPage – Ein einfacher Passwortschutz für Seiteninhalte
Zweck:
SimplyPWPage schützt Inhalte einer Seite über ein einfaches Passwort, ohne dass in WBCE Benutzerkonten oder Gruppen angelegt werden müssen. Das Modul arbeitet als Page-Modul und steuert über eine Session, ob eine Seite „freigeschaltet“ ist. Das eigentliche Verstecken der Inhalte erfolgt über das Template:
Template-Integration:
Um eine Seite mit SimplyPWPage zu schützen, wird im Template ein zusätzlicher
page_content()-Block eingefügt, z.B. Block 42:
[== HTML ==]
<div class="content-main"><!-- Layoutblock / Spalte -->
<?php
// 1. „Schlüssel“-Block: SimplyPWPage (Block 42)
page_content(42);
// 2. Nur wenn freigeschaltet, geschützten Inhalt (Block 1) ausgeben
global $simplypwpage_unlocked, $page_id;
$is_unlocked = true;
if (isset($simplypwpage_unlocked) && is_array($simplypwpage_unlocked)
&& isset($page_id)
&& array_key_exists($page_id, $simplypwpage_unlocked)) {
$is_unlocked = ($simplypwpage_unlocked[$page_id] === true);
}
if ($is_unlocked) {
page_content(1);
}
?>
</div>Wichtig:
Wenn SimplyPWPage nicht installiert oder auf der Seite nicht verwendet wird, bleibt $simplypwpage_unlocked undefiniert → $is_unlocked bleibt true → Block 1 wird ganz normal angezeigt (volle Kompatibilität).
Wird eine SimplyPWPage-Section in Block 42 verwendet und ist dort ein Passwortschutz konfiguriert, setzt view.php $simplypwpage_unlocked[$page_id] auf:
- false: solange noch kein gültiges Passwort eingegeben wurde
- true : nach erfolgreicher Passworteingabe
Ist zwar eine SimplyPWPage-Section vorhanden, aber weder eine gültige lokale noch eine gültige globale Kombination konfiguriert, gibt das Modul im Frontend keinerlei Ausgabe aus und $simplypwpage_unlocked[$page_id] bleibt/steht auf true → die Seite verhält sich wie ungeschützt.
Benutzung im Backend
1. Auf der gewünschten Seite eine neue Section anlegen und als Modul „SimplyPWPage“ auswählen.
2. Dieser Section im Seiten-Layout/Backend den Block 42 zuweisen (oder den Block, den das Template für SimplyPWPage vorsieht).
3. In der Modify-Ansicht der Section:
- Checkbox
„Passwortschutz für diese Seite aktivieren“ aktiviert bzw. deaktiviert den Schutz für diese Seite. Ist der Schutz deaktiviert, werden keine Einstellungen gespeichert und die SimplyPWPage-Section hat keinen Einfluss auf das Frontend.
- Auswahl der Kombination (Radio-Buttons):
* „Nur lokale Kombination für diese Seite verwenden“
→ Es wird ausschließlich ein lokales Passwort für diese Seite genutzt.
* „Nur globale Kombination für diese Seite verwenden (falls aktiviert)“
→ Es wird ausschließlich die globale Kombination verwendet, sofern sie im unteren Bereich aktiviert und mit Passwort versehen ist.
- Lokale Kombination:
* Passwortfeld mit Platzhaltern
- „Noch kein Passwort gesetzt“ (wenn noch kein Hash vorhanden ist)
- „Passwort vorhanden – zum Ändern neu eingeben“ (wenn bereits ein Passwort gesetzt ist)
* Bezeichnung für „Eingeloggt als …“ (z.B. „Testgruppe“, „Elternbeirat“).
- Buttons:
* „Einstellungen speichern“ speichert alle lokalen und globalen Einstellungen.
* „Passwort löschen“
löscht – je nach aktueller Auswahl:
- bei „Nur lokale Kombination …“ das lokale Passwort dieser Seite,
- bei „Nur globale Kombination …“ das globale Passwort.
Vor dem Löschen erscheint jeweils ein Bestätigungsdialog.
Hinweis:
- Lokales und globales Passwort können parallel existieren.
- Welche Kombination tatsächlich für diese Seite verwendet wird, entscheidet ausschließlich die Auswahl „Nur lokale Kombination …“ /„Nur globale Kombination …“.
- Ein global gesetztes Passwort ersetzt das lokale nicht automatisch und umgekehrt – die Auswahl legt fest, welche Kombination für diese Seite gültig ist.
Globale Kombination
Im unteren Bereich der Modify-Ansicht kann eine globale Kombination gepflegt werden:
- „Globale Kombination aktivieren“ schaltet die globale Variante frei.
- „Globales Passwort“ + „Globale Bezeichnung“ werden in einer separaten Tabelle gespeichert.
- Seiten, die in der oberen Auswahl auf „Nur globale Kombination für diese Seite verwenden (falls aktiviert)“ stehen, nutzen dieses Passwort und Label.
- Seiten, die auf „Nur lokale Kombination …“ stehen, verwenden ausschließlich ihr eigenes lokales Passwort und ignorieren die globale Kombination.
Verhalten im Frontend
Solange die Seite noch nicht freigeschaltet ist:
- Text: „Dieser Inhalt ist nur nach Eingabe eines gültigen Passwortes sichtbar.“
- Passwortfeld + Button „Freischalten“
- Bei falschem Passwort erscheint eine Fehlermeldung.
Nach erfolgreicher Passworteingabe:
- Anzeige: „Eingeloggt als XY“ (XY = lokale oder globale Bezeichnung)
- Logout-Button, der die Freischaltung wieder aufhebt
- $simplypwpage_unlocked[$page_id] = true
→ der geschützte Block wird im Template ausgegeben.
Wird der Schutz für diese Seite im Backend deaktiviert oder ist die gewählte Kombination (lokal oder global) nicht vollständig konfiguriert (kein Passwort, global nicht aktiviert etc.), gibt das Modul keinerlei Frontend-Ausgabe aus und die Seite bleibt ungeschützt.
Sicherheit
- Alle Datenbankoperationen laufen über mysqli-Prepared Statements.
- Alle Formulare (Backend und Frontend) sind mit FTAN (CSRF-Schutz) über getFTAN()/checkFTAN() abgesichert.
- Eingaben werden mit filter_var() und intval() gefiltert.
- Ausgaben werden mit htmlspecialchars(..., ENT_QUOTES, 'UTF-8') geescaped.
- Passwörter werden mit password_hash() und password_verify() verarbeitet.
- Policy (leicht anpassbar): mindestens 8 Zeichen, mindestens 1 Buchstabe, mindestens 1 Ziffer, mindestens 1 Sonderzeichen
Das war jetzt sehr viel Text. Nun viel Spaß beim ausprobieren!
Last edited by pfreud01 (05.01.2026 16:50:44)
Offline
beach, jean, berny
Du haust ja eins nach dem andren raus. Respekt....
Habe es mal getestet. Aber irgendwie klappt das nicht wie ich gedacht habe.
Habe eine neue Seite angelegt als simplyPWPage. (ID 8 )
Dann habe ich einen neuen Abschnitt hinzugefügt als WYSIWYG (ID 9)
Habe im Template in der index.php den Code eingefügt den du oben gepostet hast. Aus deiner 42 wurde meine ID8 und aus deiner 1 wurde meine ID9
Passwortschutz aktiviert, nur lokale Kombination... Passwort vergeben.
Einen Text im WYSIWYG Editor eingegeben.
Wenn ich nun das Frontend aufrufe, dann kommt dein Login, und darunter wird ebenfalls der Text aus dem 2. Abschnitt (ID 9) gezeigt (von dem ich erwartet habe das er geschützt ist.)
Dein Login funktioniert. Ich werde nach der Eingabe des Passwort "Eingeloggt als: abc" angezeigt. Der Text aus dem 2. Abschnitt wird ebenfalls wieder angezeigt.
Irgendetwas habe ich scheinbar falsch umgesetzt bzw falsch verstanden.
Last edited by beach (02.12.2025 20:27:51)
Offline
Du darfst nicht deine Sections mit den page_content verwechseln. Im Template muss der zusätzliche Block für SimplePWPage angelegt werden und unter Abschnitte verwalten muss das Modul in „seinen“ Block, der normale zu schützende Inhalt in den normalen Contentblock. Es geht nicht um die Abschnitts-ID, sondern um die Blöcke, die in der info.php des Templates definiert sind.
Offline
Coole Sache.
So ganz trivial ist die Einrichtung nicht - man muss die index.php des Templates anpassen und den zusätzlichen Block in der info.php des Templates definieren.
In den meisten neueren Templates wird übrigens mit mehreren Blöcken gearbeitet, die bereits in einen Array (üblicherweise $block) eingelesen sind. Siehe exemplarisch wbcezon:
// Blöcke laden. Es werden nur Blöcke mit Inhalt angezeigt. Ist kein Inhalt in Block 2 vorhanden, geht Block 1 über die gesamte Breite neben der seitlichen Navigation, sonst Aufteilung 6:3
// fetch blocks. No empty blocks will be displayed. If block 2 has no content, block 1 uses the whole width beneath the aside menu, otherwise the blocks are displayed in 6:3 ratio.
require_once __DIR__.'/info.php';
foreach($block as $k=>$v){
ob_start();
page_content($k);
$block[$k] = ob_get_clean();
}
if(defined('MODULES_BLOCK2') AND MODULES_BLOCK2 != '') {
$block[2] .= MODULES_BLOCK2;
}In dem Falle muss dann der Code, der in die index.php des Templates eingefügt wird, geringfügig angepasst werden:
// 1. „Schlüssel“-Block: SimplyPWPage (Block 42)
echo $block[42];
...usw....Und der Code muss dann sinnvoll im Template platziert werden, damit die Eingabemaske im Frontend an der richtigen Position erscheint - bei WBCEZon z.B. nach
<!-- MAIN CONTENT AND OPTIONAL BLOCKS -->
<div class="s-12 l-9 maincontent"> Vielleicht wäre es sinnvoll, das hinterlegte Passwort im Backend im Klartext anzuzeigen. Also nicht nur bei der Eingabe, sondern auch im Nachhinein noch - man kann doch förmlich darauf warten, dass ein Elter™ anruft ("Wie lautet noch gleich wieder das Passwort? Ich wollte mir Valeria-Chantals Noten anschauen, und jetzt komme ich nicht auf die Seite" usw.)
Last edited by florian (03.12.2025 08:17:52)
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Das hinterlegte Passwort im Backend im Klartext anzeigen zu lassen, geht schlicht nicht, da es ja als Hash in der DB abgelegt wird. Man müsste es dann auch im Klartext dort speichern, und das halte ich für nicht sicher. Ich habe deswegen im Passwortfeld ausgeben lassen, dass bereits ein Passwort abgelegt ist bzw. anfangs eben, dass noch keines da ist. Gerade das globale PW muss man als Backenduser ja dann nicht immer neu eingeben, wenn man nur am Inhalt der Seite arbeitet.
Im schulischen Umfeld gibt es für die Eltern ein sich jährlich 1x änderndes Elternpasswort. Für spezielle Unterseiten (Elternbeirat o.ä.) wäre das lokale PW denkbar. Lehrkräfte loggen sich normal mit Zugangsdaten von WBCE ein. Das war der gedankliche Hintergrund der Aktion.
Offline
Danke florian, ich glaube nun habe ich es so halbwegs verstanden. Mal schauen ob ich es damit hinbekomme.
@pfreud01: Nur mal als dumme Frage meinerseits. Wäre es nicht einfacher gewesen wenn dein Modul ein Passwort abfragt und nur wenn das richtig ist, dann Content ausliefert?
Oder warum hast du dich für diesen Weg entschieden?
Offline
So ganz verstehe ich deine Frage nicht. Genau das macht das Modul ja. Es fragt ein Passwort ab und gibt, wenn richtig, den Content aus.
Ich bin ja beileibe kein Programmierer und weiß es nicht besser, aber ChatGPT war sich sicher, dass das nur auf diesem Weg funktioniert, ohne dass der Content schon im Quelltext sichtbar wäre. Und ist das Template mal vorbereitet (muss man ja nur einmal machen), funktioniert es auch ganz fluffig. Wie gesagt, es sollte am Core nichts angepasst werden müssen. 
Last edited by pfreud01 (04.12.2025 15:49:24)
Offline
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
pfreud01, beach, byteworker, berny
Kleines Update auf v1.0.2 im ersten Post:
Leerzeichen entfernt: "Eingeloggt als : Geheimgruppe" wird zu "Eingeloggt als: Geheimgruppe"
Neue Standardfarben der Eingeloggt-Meldung (grün, klein, rechtsbündig) und der Nicht-Eingeloggt-Meldung (rot, deutlicherer Rahmen)
Ansonsten läuft das ganze jetzt fehlerfrei produktiv und hat mein Update nicht gestört. Zweck erfüllt! ![]()
Last edited by pfreud01 (05.01.2026 16:56:00)
Offline
mk70, florian
Pages: 1