differenziertere Error 40x, Erweiterung der default Errorsite bei nicht Online/gesperrt Einstellungen

[STam]

Ich wünsche mir eine differenziertere Auswahl des Error 40x für bei Seiten
die gesperrt sind, jeweils im Fall das der User 'nobody' ist oder angemeldet.

Nach folgendem Schema:
Seite offline => 404
Seite online + gesperrt und User = 'nobody' (kein Recht) => 401
Seite online + gesperrt und User != 'nobody' (kein Recht) => 403

Das hätte den Vorteil, das zB wenn ein angemeldeter User auf einer geschützten Seite
die Frontend-Session Zeit ablaufen läßt (eg 10Min inaktiv) bekommt beim nächsten Klick
den Error 401. Anderes Beispiel; ein User (angemeldet) hat nicht das Recht eine Seite zu sehen
kennt aber die URL, bei Eingabe der URL von der geschützten Seite bekommt er Error 403.

Schön wäre es wenn diese Error Konfiguration analog zur bestehenden '404 Errorsite UrlRewrite=2.'
gemacht wird, es bleibt also jedem frei über einen Fallback zumindest 404 auszugeben und 401 bzw 403
nicht zu konfigurieren. Zusätzlich könnte für den std. Fall die $cfg_client['errorpage'] per Parameter erweitert werden.

Die Abfrage würde ich in der Datei /cms/inc/frontend.php und /cms/inc/backend.php implementiert sehen.

Gruß

Update:
 patch_error404.zip ( 8.76KB ) Anzahl der Downloads: 29
- Patch implementation

Edit: Anleitung hinzugefügt

1.
Im Zipfile sind fertig gepatchte .php Dateien:
- backend.php
- frontend.php
die man, wenn ein ungepatchtes System vorliegt (also an diesen Dateien nix verändert wurde),
einfach austauscht. Wenn allerdings schon gepatchte Dateien vorliegen kann man
die .patch Dateien benutzen um die Dateien zu Patchen (die Dateien enthalten nur die nötigen Änderungen im Diff-Format).
2.
Die .sql Datei am besten mit PhpMyAdmin auf dem Server ausführen.
3.
Die xxx_update_lang.php bringt die nun (neuen) nötigen Langstrings mit (nur de).
Diese einfach in die Datei 'backend/tpl/standard/lang/de/lang_clients_config.php' einpflegen.
4.
Nun kann man in dem SF-Projekt unter 'Projekt konfigurieren' die neuen Error-Sites (mit der entsprechenden IDCATSIDE) konfigurieren.
5.
Danke sagen und fertig

[bjoern]

Habe ich mir jetzt angeschaut. Kann ich in die Bugfixversion nicht rein nehmen. Ein Schlüssel des $cfg_client Arrays wird bei dem Patch geändert. Dadurch werden alle Module nicht mehr korrekt funktionieren, welche mit diesem Schlüssel arbeiten.

[FireFlyer]

Habe ich mir jetzt angeschaut. Kann ich in die Bugfixversion nicht rein nehmen. Ein Schlüssel des $cfg_client Arrays wird bei dem Patch geändert. Dadurch werden alle Module nicht mehr korrekt funktionieren, welche mit diesem Schlüssel arbeiten.

Ich wollte es bloß mal wieder nach oben schieben, da es meiner Meinung sehr wichtig ist bei der Fehleranalyse.
Was macht denn da Probleme? Müssen die Module umgeschrieben werden? Welche?

Irgendwann müssten wir das aber schon rein bringen und spätestens dann müssen die Module geändert werden!

oder gibt es einen Workaround?