WBCE CMS – Way Better Content Editing.
You are not logged in.
Hallo in die Runde,
ich greife hier das Thema, welches ich bereits auf Github (https://github.com/WBCE/WBCE_CMS/issues/419) angerissen hatte, nochmals auf.
Zusammenfassung der Diskussion auf Github:
Ich hatte angeregt, dass Seiten mit der Sichtbarkeit "keine" einen HTTP-Status-Code 404 (Not Found) zurückliefern sollten, anstatt eine Seite mit der Meldung "Sie haben keine Leserechte für diese Inhalte" und Status-Code 200 (OK) anzuzeigen. Die Gründe warum das sinnvoll ist, habe ich auf Github (siehe o.g. Link) aufgeführt. Colinax wieß in der Diskussion darauf hin, dass dies bereits in Master branch umgesetzt sei, danach wurde der Issue geschlossen und ich auf das Forum für die Fortsetzung der Diskussion verweisen. Und hier bin ich
Aktuelle Umsetzung:
Soweit ich das in den von ihm genannten Änderungen nachvollziehen konnte, wurde das durch das Löschen des Access Files für Seiten mit der Sichtbarkeit "keine" (none) realisiert.
Vorschlag zur Verbesserung:
Ich halte es für eine unnötig komplizierte Lösung, das Senden eines 404 für Seiten mit der Sichtbarkeit "keine" durch das Löschen des zugehörigen Access Files zu lösen. Wenn z.B. später die Sichtbarkeit der Seite wieder auf "öffentlich" gestellt wird, muss geprüft werden ob inzwischen nicht bereits eine andere Datei mit dem gleichen Namen wie das nun wieder anzulegende Access File exisitiert.
Einfacher wäre es doch den 404 Status Code per PHP abzusetzen, direkt in der index.php von WBCE.
Hier eine funktionierende Umsetzung:
[== PHP ==]
// Send 404 status code if access for page is denied
if($wb->page_access_denied){
http_response_code(404);
die;
}
$wb->page_access_denied ist nämlich true wenn die Site die Sichtbarkeit "none" oder "deleted" besitzt und eignet sich daher sehr gut für den Anwendungszweck.
In der Diskussion auf Github hatte ich auch vorgeschlagen, selbiges Verhalten auf Seiten mit der Sichtbarkeit "privat" und "registriert" anzuwenden – dass also Nutzer, die NICHT angemeldet sind oder keine Berechtigung für die betroffene Seite haben, einen 404 zurück erhalten. Denn wie ich im Issue auf Github aufführte kann u.U. bereits die URL Aufschluss über den eigentlich verborgenden Inhalt geben und somit wäre es besser gleich so zu tun, als gäbe es diese Seite nicht.
Bei der Recherche für die o.g. Lösung für Seiten mit Sichtbarkeit "keine", bin ich aber darauf gestoßen dass die Methode get_page_details() der WB-Frontend-Klasse Seiten (in /framework/class.frontend.php) die Sichtbarkeit "private" und "registered" bereits extra behandelt indem nicht-angemeldete Nutzer auf die Login-Seite umgeleitet werden. Und sofern Frontend-Login deaktiviert ist (was, glaube ich inzwischen die Default-Einstellung ist) geht es von dort aus per 302-Redirect weiter auf die Startseite. Hier wären also zusätzliche Änderungen an der get_page_details() Methode notwendig.
Das Senden eines 404 bei Seite mit Sichtbarket "keine" ist aber wie oben gezeigt sehr viel einfach machbar, als das Access File zu löschen.
Was meint ihr?
Beste Grüße
André
Last edited by florian (19.12.2019 10:28:10)
Offline
Hallo André,
danke für die Ideen.
Ich glaube, es ist grade ein kleines zeitliches Problem da, deswegen hatte keiner noch richtig Zeit, auf Deine Überlegungen richtig einzugehen.
Wie ist Dein Umgang mit GitHub? Kennst Du Dich damit ein wenig aus?
Hättest Du Lust, die Ideen auf einem Fork umzusetzen und dann einen PullRequest zu machen?
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Hallo Christian,
ich könnte schon einen Pull Request mit der vorgeschlagenen Lösung in der index.php erstellen - da aber bereits die Lösung mit dem Löschen des Access Files im Master branch ist, wäre das dann eine damit konkurierende Umsetzung. Damit die oben vorgeschlagene Lösung in der index.php überhaupt zum Tragen kommt, müsste ich somit erst die Access-File-Löschen-Lösung wieder ausbauen. Und daran wollte ich mich jetzt nicht "vergreifen", da ich nicht einschätzen kann, ob das irgendwelche unerwünschten Seiteneffekte nach sich zieht.
Ich sag mal so: Wenn die bereits im master branch vorhandene Access-File-Löschen-Lösung robust genug ist, dass auch beim späteren Ändern der Sichtbarkeit von "none" auf einen anderen Wert das Access File wieder korrekt hergestellt wird, ohne z.B. eine zwischenzeitlich anderweitig stellte Datei mit gleichem Namen zu überschreiben, dann ist das auch okay. Zwar komplexer als nötig aber am Ende zählt ja das Ergebniss und vielleicht hat diese Lösung mit dem Löschen des Access Files ja noch einen anderen Mehrwert, den ich gerade nicht auf dem Schirm habe.
Vielleicht könnte der Autor der Access-File-Löschen-Lösung (@WebDesignWorx) mal drüber schauen und seine Einschätzung mitteilen? Vielleicht habe ich ja tatsächlich einen Fakt übersehen und er hat sich ganz bewusst für eben diese Lösung entschieden. Wenn es tatsächlich nur um das Senden eines 404 geht, wäre die von mir vorgeschlagene Lösung mit deutlich weniger Code und ohne Eingriffe im Dateisystem sicher die elegantere. Aber wie gesagt, damit mag ich auch falsch liegen.
Beste Grüße
André
Offline
stefanek
Hallo André,
ich (WebDesignWorx) habe es so (access file löschen und wieder erstellen) umgesetzt, weil es so gewünscht war.
Was die anderen Stati (privat und registriert) angeht, persönlich finde ich, dass es gar keine schlechte Idee ist.
Vielleicht könnte sich Florian dazu äußern?
Wegen GitHub und Fork und dass es dann eine konkurrierende Umsetzung wäre: das ist insofern kein Problem, als dass wir ja Deinen PullRequest anschauen/testen können, bevor er integriert würde.
Ich sag mal so: Wenn die bereits im master branch vorhandene Access-File-Löschen-Lösung robust genug ist, dass auch beim späteren Ändern der Sichtbarkeit von "none" auf einen anderen Wert das Access File wieder korrekt hergestellt wird, ohne z.B. eine zwischenzeitlich anderweitig stellte Datei mit gleichem Namen zu überschreiben, dann ist das auch okay.
Ich denke das funktioniert ganz OK und das System lässt es nicht zu, dass neue Seiten mit der selben URL angelegt werden.
Oder ist ein Test bei Dir negativ ausgefallen?
Gruß,
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
Ist es denn mit dem fiktiven 404 auch möglich, Zugriffe auf die betreffenden URLs umzuleiten (ErrorDocument-Anweisung in der htaccess) bzw. Module wie 404/404plus zu verwenden?
Was steht anschließend in der URL-Zeile im Browser beim Aufruf einer nicht-existenten Seite?
Die Nutzung für private/registrierte Seiten halte ich für nicht sinnvoll. Das aktuelle Verhalten, dass nicht-angemeldete Nutzer beim Aufruf einer solchen URL auf die Anmeldeseite geführt werden, erscheint mir besser und auch "ehrlicher", faktisch ist es ja ein 403 und kein 404.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Hallo Florian und Christian,
besten Dank für eure kompetenten Antworten! Es ist schön zu sehen, wie lebendig die WBCE-Comunity ist und das hier Vorschläge auf einer sachlichen und professionellene Ebene diskutiert werden können.
@Florian:
Ich habe das mal getestet und es sieht tatsächlich so aus, also würde nach dem Senden eines Response-Codes durch PHP die Kontrolle nicht mehr zurück an den Apache übergeben werden – so dass ErrorDocument-Anweisungen in der .htaccess wirklungslos bleiben. DAS ist offen gestanden eine K.O.-Argument gegen die von mir vorgeschlagene Lösung. Da hattest Du also die richtige Eingebung.
@Christian:
Je länger ich darüber nachdenke, desto sinvoller halte ich Deine Lösung mit dem Löschen des Access Files – mal ganz abgesehen von der o.g. Implikation in Sachen Apache/ErrorDocument. Denn im "professionellen" Kontext nutzt man ja schon hin und wieder mal unsichtbare Seiten als "Daten-Silo" für z.B. zusätzliche Texte in der Sidebar oder im Footer des Templates. In diesen Fällen ist es dann auch überssichtlicher, wenn es kein Access File zur unsichtbaren Seite gibt.
Was das Wiederherstellen des Access Files angeht: Das wird ja vermutlich von der bereits seit langem im Core vorhanden Funktion übernommen, die auch anderweitig verloren gegangene Access-Files beim Speichern der Seiten-Einstellungen neu anlegt oder umbenennt? Da habe ich gerade mal unter WBCE 1.3.3 getestet und es scheint so, als würde diese nicht auf eine bereits vorhandene Datei gleichen Namens prüfen!
Schritte zum Reproduzieren:
leere Datei "lorem.php" in /pages ablegen
die Einstellungen einer vorhandenen Seite öffnen und den Dateinamen auf "lorem.php" ändern
(die zuvor leere lorem.php enthält jetzt Access File Code, wurde also ohne Warnung überschrieben)
Also: Das Löschen des Access Files für Seiten mit der Sichtbarkeit "keine" erscheint mir inzwischen eine gute Lösung und sorgt auch für das von mir gewünschte Senden eines 404. Jedoch müsste die Funktion zum Ändern / Wiederherstellen des Access Files um eine Prüfung auf bereits vorhandene Dateien gleichen Namens erweitert werden.
Beste Grüße
André
Last edited by digitalbricks (06.05.2019 15:02:17)
Offline
florian, bernd, stefanek
Was das Wiederherstellen des Access Files angeht: Das wird ja vermutlich von der bereits seit langem im Core vorhanden Funktion übernommen, die auch anderweitig verloren gegangene Access-Files beim Speichern der Seiten-Einstellungen neu anlegt oder umbenennt? Da habe ich gerade mal unter WBCE 1.3.3 getestet und es scheint so, als würde diese nicht auf eine bereits vorhandene Datei gleichen Namens prüfen!
Schritte zum Reproduzieren:
leere Datei "lorem.php" in /pages ablegen
die Einstellungen einer vorhandenen Seite öffnen und den Dateinamen auf "lorem.php" ändern
(die zuvor leere lorem.php enthält jetzt Access File Code, wurde also ohne Warnung überschrieben)
Also: Das Löschen des Access Files für Seiten mit der Sichtbarkeit "keine" erscheint mir inzwischen eine gute Lösung und sorgt auch für das von mir gewünschte Senden eines 404. Jedoch müsste die Funktion zum Ändern / Wiederherstellen des Access Files um eine Prüfung auf bereits vorhandene Dateien gleichen Namens erweitert werden.
Hallo André,
ja, aber in der Praxis ist es nicht unbedingt vorgesehen, Dateien im /pages Verzeichnis über FTP hochzuladen. (?)
Solch ein Szenario ist eher unwahrscheinlich.
Soweit ich mich erinnern kann, wird vorm Anlegen einer Seite auf einer bestimmten Ebene unterhalb einer Seite (oder unterhalb vom Root) geschaut, ob eine Datei mit dem selben Namen in der Datenbank bereits geschrieben steht. Nicht also in dem Pages Ordner wird geschaut, sondern in der DB.
Du wirst sehen, dass wenn Du eine Seite auf `none`setzt oder sie in den Papierkorb (`deleted`) verschiebst, kannst Du keiner neuen Seite den gleichen Namen vergeben.
Es ist schön zu sehen, wie lebendig die WBCE-Comunity ist und das hier Vorschläge auf einer sachlichen und professionellene Ebene diskutiert werden können.
Lebendig schon, etwas mehr Zeit hätten wir wahrscheinlich schon gerne. :-)
Wenn gute Vorschläge kommen, kann man auch gerne darüber sprechen.
Aus Zeitgründen lässt sich nicht alles gleich umsetzen, aber wenn was wirklich Sinnvolles dabei ist und vor allem mit der Bereitschaft mit anzupacken... kann man sich auf jeden Fall näher anschauen.
In diesem Sinne...
Christian
“Success is the progressive realization of a worthy ideal.” ― Earl Nightingale
Offline
mrbaseman
Hallo Christian,
danke für Deine Erläuterungen!
Ok - sieht also so aus, als wäre mein Punkt hier auf dem Wunschzettel bereits im brauchbarer Form umgesetzt. Das ist super, denn diese etwas sinnarme Meldung bei Seiten mit der Sichtbarkeit "keine" fand ich jedes Mal nervig, wenn ich darauf stieß (offenbar allerdings nicht nervig genug, um das schon mal früher bemängelt zu haben ).
Vielen Dank für eure Antworten und natürlich für die Zeit, die ihr in WBCE investiert!
Beste Grüße
André
Offline
stefanek, bernd, mrbaseman
Ist in 1.4.1 umgesetzt.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
stvis