Private CMS-Seiten - Inhalte nur für Mitglieder, nach Kundengruppe, mit Weiterleitung und versteckten Links

Eine Tabelle, und Ihre privaten Seiten sind privat

Jede CMS-Seite Ihres Shops erscheint als Zeile. Jede Kundengruppe erscheint als Spalte mit Checkboxen. Haken Sie an, wer hinein darf, klicken Sie auf Zugriffsregeln speichern, fertig. Es gibt keinen zweiten Bildschirm, keinen Einstellungs-Tab, den Sie pro Seite suchen müssten, und nichts, was synchron gehalten werden will.

Die Liste ist durchsuchbar, jede Zeile trägt ein aktuelles Kennzeichen Alle oder Nur angehakte Gruppen, sodass Sie den Status auf einen Blick sehen, und zu jeder Seite gibt es einen Vorschaulink.

Öffentlich, solange Sie nichts anderes sagen

Genau darauf kommt es an, wenn Sie in einigen Monaten neue Seiten anlegen. Eine Seite ohne angehakte Gruppe ist öffentlich. Neue CMS-Seiten, die Sie später erstellen, sind automatisch öffentlich — sie müssen nicht erst im Modul registriert werden, und sie verschwinden nicht stillschweigend aus Ihrem Shop, weil Sie einen Schritt vergessen haben. Löschen Sie eine Seite, bleibt ihre Regel einfach ungenutzt. Es gibt keine Synchronisationstabelle, und nichts muss jemals neu aufgebaut werden.

Leiten Sie Besucher dorthin, wo es weitergeht — nicht ins Leere

Wählen Sie die URL, auf der Menschen ohne Zugriff landen sollen, und fügen Sie sie ein. Lassen Sie das Feld leer, geht es stattdessen zu Ihrer Startseite. Sinnvoll ist eine kurze öffentliche Seite — "Diese Inhalte sind nur für Mitglieder" — die erklärt, wie man Zugang bekommt, und die Weiterleitung genau dorthin zu schicken.

Eine Weiterleitungsschleife ist ausgeschlossen. Das Modul verweigert beim Speichern eine geschützte Seite als Weiterleitungsziel, warnt Sie auf der Konfigurationsseite, wenn eine bereits gewählte Seite später geschützt wird, und fällt zur Laufzeit auf Ihre Startseite zurück, falls es doch einmal dazu kommt. Drei getrennte Sicherungen für einen einzigen Fehler — weil dieser Fehler Menschen aus dem Shop aussperrt.

Anmelden — und genau dort landen, wo man hinwollte

Ein Besucher klickt auf eine private Seite, wird weitergeleitet und meldet sich an. Die meisten Umsetzungen setzen ihn danach auf der Startseite ab und lassen ihn den Weg zurück selbst suchen. Dieses Modul merkt sich die angeforderte Seite und bringt ihn direkt dorthin, sobald er sich mit einem berechtigten Konto anmeldet.

Gehört das Konto, mit dem er sich angemeldet hat, nicht zu einer berechtigten Gruppe, landet er auf Ihrer Startseite, statt auf eine Seite zurückgeworfen zu werden, die er weiterhin nicht öffnen kann. Und eine Anmeldung, die direkt im Bestellvorgang stattfindet, bleibt bewusst unangetastet — niemand wird aus dem Checkout gerissen, weil er zwanzig Minuten zuvor auf eine CMS-Seite geklickt hat.

Versteckte Links, auf dem Server berechnet

Aktivieren Sie Links zu geschützten Seiten ausblenden, und Links zu Seiten, die ein Besucher nicht öffnen kann, verschwinden aus Menüs, Fußzeilen und CMS-Kategorielisten. Ein Link auf eine CMS-Kategorie verschwindet erst dann, wenn jede aktive Seite darin für diesen Besucher privat ist — Sie verlieren also keinen ganzen Menüpunkt wegen einer einzigen geschützten Seite.

Die geschützten IDs werden serverseitig und pro Besucher ermittelt und in ein kleines, abhängigkeitsfreies Skript eingebettet. Der Browser sendet dafür keine einzige Anfrage — weder eine pro Link noch überhaupt eine.

Seien Sie sich dabei über eines im Klaren: Ausblenden ist Kosmetik, der eigentliche Schutz ist die Weiterleitung. Ein ausgeblendeter Link steht weiterhin im HTML der Seite. Das ist unerheblich, denn die Seite dahinter lässt sich so oder so nicht öffnen.

Geprüft wird auf der Seite, nicht am Link

Wer die URL direkt eintippt oder sie von einer Kollegin zugeschickt bekommt, wird genauso weitergeleitet wie alle anderen. Das gilt auch für eingebettete ?content_only=1-Ansichten — genau die Hintertür, an der Umsetzungen scheitern, die nur den Link im Frontoffice absichern.

Gruppenzugehörigkeit so, wie man es erwartet

Ein angemeldeter Kunde zählt als Mitglied aller Gruppen, denen er angehört — seiner Standardgruppe plus allen weiteren — direkt aus den Gruppenzuordnungen des Kunden gelesen. Damit funktioniert es auch in Shops korrekt, in denen PrestaShops interner Schalter für die Gruppenfunktion deaktiviert ist — anderswo ein stiller Fehlerfall.

Verschieben Sie einen Kunden unter Kunden → Gruppen in eine berechtigte Gruppe, und jede private Seite dieser Gruppe öffnet sich für ihn sofort. Im Modul muss nichts erneut gespeichert werden.

Besucher, die nicht angemeldet sind, gehören zu PrestaShops Gruppe Besucher. Sie können sie anhaken, um eine geschützte Seite für sie erreichbar zu halten — was allerdings selten gewünscht ist.

Gebaut, um Ihren anderen Modulen nicht in die Quere zu kommen

Keine Core-Overrides. Version 2 nutzt drei Standard-Hooks: actionDispatcherBefore entscheidet über den Zugriff, bevor die Seite ausgeliefert wird, actionFrontControllerSetMedia bindet den Code zum Ausblenden der Links ein, und actionAuthentication übernimmt die Rückkehr nach der Anmeldung. Sonst nichts.

Das wiegt schwerer, als es klingt. Overrides von CMS und CmsController sind genau die Dateien, die auch andere Module überschreiben wollen, und sie sind dafür berüchtigt, nach einer Deinstallation auf der Festplatte liegen zu bleiben. Dieses Modul kann damit nicht kollidieren, weil es sie gar nicht anfasst.

Version 2 hat zwei echte Sicherheitslücken geschlossen

Das gehört klar ausgesprochen, denn es geht um ein Modul, dessen einzige Aufgabe Zugriffskontrolle ist.

Version 1.x lieferte einen Admin-AJAX-Endpunkt aus, der ohne Anmeldung erreichbar war. Seine Token-Prüfung verglich zwei serverseitige Werte, die einander immer gleich waren — die Prüfung ging also für jeden durch. Wer die URL kannte, konnte Ihre Zugriffsregeln lesen oder umschreiben. Ein zweiter öffentlicher Endpunkt (classes/hidecmslink.php) nahm einen Token-Parameter entgegen und prüfte ihn danach überhaupt nicht, und die Seitenliste enthielt einen für SQL-Injection anfälligen Sortierparameter.

Version 2 entfernt all das. Jede Backoffice-Aktion läuft jetzt auf der Konfigurationsseite hinter dem Admin-Token, und das 2.0.0-Update löscht die alten Dateien von der Festplatte, statt sie dort liegen zu lassen.

Was Version 2 sonst noch behoben hat

Die alte Funktion "Links ausblenden" feuerte eine synchrone AJAX-Anfrage pro Link und legte einen weißen Lade-Overlay über die Seite — weshalb die 1.x-Dokumentation stillschweigend davon abriet, sie einzuschalten. Heute ist es ein kleines Skript und null Anfragen.

Neue CMS-Seiten waren für das Modul früher unsichtbar, bis jemand die Konfigurationsseite öffnete, weil erst eine Synchronisationstabelle nachziehen musste. Version 2 speichert nur die geschützten Seiten — neue Seiten sind also automatisch öffentlich und werden automatisch gelistet.

Der Weiterleitungslink war früher Pflicht, und das Modul mahnte so lange, bis er ausgefüllt war — mit einem 1.x-Standardwert, der Ihre Besucher zu prestashop.com schickte. Heute ist er optional, wird validiert, und leer bedeutet schlicht Ihre Startseite.

Und jQuery UI 1.8 samt Tab-Plugins wurde in Ihr Backoffice geladen. Alles verschwunden.

Das Update von 1.x ist ein einziger Schritt

Spielen Sie Version 2 über die alte ein oder nutzen Sie die Update-Schaltfläche des Moduls. Das Update überführt jede gespeicherte Zugriffsregel und Ihre Einstellungen in das neue Format, entfernt die Core-Overrides aus dem Shop, löscht die 1.x-Dateien einschließlich beider unsicherer Endpunkte und verwirft die alte Tabelle cmspages. Es gibt nichts neu einzurichten — öffnen Sie einmal das Panel Seitenzugriff und bestätigen Sie, dass Ihre Regeln angekommen sind.

Version 2.0.2 hat einen Update-Fehler behoben, den man beim Namen nennen sollte: Die Schritte 2.0.0 und 2.0.1 knüpften ihren Erfolg daran, dass registerHook()-Aufrufe true zurückgeben. Ein vorübergehender Fehlschlag — oder ein Hook, der von einem früheren, abgebrochenen Versuch bereits registriert war — ließ damit den gesamten Schritt als fehlgeschlagen gelten, und PrestaShop deaktivierte das Modul. Hooks werden jetzt idempotent registriert, und jeder Schritt meldet Erfolg.

Kompatibilität und Multistore

PrestaShop 1.7, 8 und 9, in acht Sprachen: Niederländisch, Englisch, Französisch, Deutsch, Italienisch, Polnisch, Spanisch und Türkisch.

Im Multistore-Betrieb sind Zugriffsregeln global — eine von mehreren Shops geteilte CMS-Seite trägt überall dieselbe Regel. Das Panel Seitenzugriff listet die Seiten des Shops, in dem Sie gerade arbeiten, oder alle Seiten im Kontext Alle Shops, und beim Speichern werden nur die Regeln der gelisteten Seiten neu geschrieben.

Beim Deinstallieren werden die Zugriffsregeln und die Einstellungen des Moduls gelöscht. Ihre CMS-Seiten bleiben unberührt — sie werden einfach alle wieder öffentlich.

Häufig gestellte Fragen

Wie mache ich eine Seite privat?

Haken Sie in der Tabelle Seitenzugriff in der Zeile dieser Seite mindestens eine Kundengruppe an und speichern Sie. Jede Seite ohne angehakte Gruppe ist öffentlich — das ist auch die Voreinstellung für jede Seite, die Sie später anlegen.

Wo landen Besucher ohne Zugriff?

Auf der URL, die Sie in den Einstellungen hinterlegt haben, oder auf Ihrer Startseite, wenn Sie das Feld leer lassen. Am besten funktioniert eine kurze öffentliche Seite, die erklärt, wie man Zugang bekommt.

Kann ein Besucher in einer Weiterleitungsschleife hängen bleiben?

Nein. Das Modul verweigert beim Speichern eine geschützte Seite als Weiterleitungsziel, warnt Sie, wenn eine bereits gewählte Seite nachträglich geschützt wird, und fällt zur Laufzeit in jedem Fall auf Ihre Startseite zurück.

Was passiert, wenn jemand die direkte URL hat?

Er wird weitergeleitet. Geprüft wird auf der Seite selbst und nicht an den Links, die auf sie zeigen — und das schließt eingebettete ?content_only=1-Ansichten ein.

Schützt das Ausblenden von Links die Seiten tatsächlich?

Nein, und das Modul behauptet auch nichts anderes. Ausblenden ist Kosmetik — ein ausgeblendeter Link steht weiterhin im HTML. Der eigentliche Schutz ist die Weiterleitung, und die ist immer aktiv, ganz gleich ob Sie das Ausblenden einschalten oder nicht.

Ein Kunde ist der richtigen Gruppe beigetreten. Muss ich irgendetwas neu speichern?

Nein. Verschieben Sie ihn unter Kunden → Gruppen in eine berechtigte Gruppe, und jede Seite dieser Gruppe öffnet sich für ihn sofort.

Überschreibt es PrestaShop-Core-Dateien?

Nein. Drei Standard-Hooks und sonst nichts — es kommt also anderen Modulen nicht in die Quere, die CMS oder CmsController überschreiben, und es übersteht PrestaShop-Updates. Die 1.x-Overrides werden beim Update aus Ihrem Shop entfernt.

Ich steige von Version 1.x um — verliere ich meine Regeln?

Nein. Das Update überführt jede Zugriffsregel und Ihre Einstellungen, entfernt die alten Overrides und die beiden unsicheren 1.x-Endpunkte und verwirft die veraltete Tabelle. Öffnen Sie danach einmal das Panel Seitenzugriff zur Bestätigung.