Druckversion des Themas

Geschrieben von: STam Thu. 31. May 2007, 09:05

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 ) : 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 http://en.wikipedia.org/wiki/Diff).
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

Geschrieben von: amk Thu. 31. May 2007, 12:56

grundsätzlich ist es wünschenswert wenn auf einer website überhaupt keine error-seiten erscheinen

Geschrieben von: feniweb Thu. 31. May 2007, 13:21

Solch eine Lösung ist dringendst nötig.

Z.B. hat vor kurzem ein Kunde die Startseite offline geschallten.

Es kam nicht mal eine Fehlermeldung oder Ersatzseite.

Da ich ihn nicht mit eingeschränkten rechten bevormunden wollte.

Gruss

Geschrieben von: STam Thu. 31. May 2007, 14:31

Polemik:

... das kommt auf den Blickwinkel an

@feniweb,

eine implementation habe schon fertig, kannst du haben -> PM.

Gruß

Geschrieben von: fo.x Thu. 31. May 2007, 15:17

Michhintenanstell

Geschrieben von: Tiggr Thu. 31. May 2007, 15:20

Ich würds auch toll finden! User mit abgelaufener Session kommen wieder zum Login, andere Fehler auf die echte 404er-Seite!

Tiggr

Geschrieben von: amk Thu. 31. May 2007, 15:32

rechte zu vergeben ist keine bevormundung sondern eine notwendige maßnahme zur verhinderung von unverhersehbaren zwischenfällen ... natürlich muss man dem kunden mitteilen dass, wenn die startseite offline ist, seine seite offline ist.

ich fänds gut wenn bei fehlender startseite, der nächste ordner "angefahren" würde.

doof ist auch das es keine leeren ordner in welchem wiederum ordner mit seiten sind geben kann - also nicht automatisch der nächste ordner mit seite innerhalb eines ordners angesprungen wird. man muss immer ne leere weiterleitungsseite erstellen, in so einem fall.

aber natürlich sind differenzierte fehlerseiten keine schlechte sache.

Geschrieben von: alexander Thu. 31. May 2007, 15:44

dafür gibt es ja in den projekteinstellungen die optionen 404 Fehlerseite bei UrlRewrite=2. bzw 404 Fehlerseite bei nicht existierender idcatside/ idcat. dort muss man halt eine seite definieren auf welche der kunden nicht das recht hat sie offline zu schalten (für was auch) und dann hast du deine ersatzseite.

Geschrieben von: STam Thu. 31. May 2007, 17:00

Patch-Download hinzugefügt.

Gruß

Geschrieben von: MoinMoin Thu. 22. November 2007, 18:39

Moin,

mal als konkrete Frage an Björn: Findet dieser Patch seinen Weg in die neue Sefrengo-Version?

Gruß,
Nils

Geschrieben von: bjoern Fri. 23. November 2007, 13:12

Ich habe mir den Patch angeschaut und denke, das können wir machen. Eventuell gibt es noch ein paar Änderungen im Code.

Geschrieben von: saschapi Thu. 10. July 2008, 17:34

Nachdem ich das etwas verpennt hab, würd ich gern wissen ob das in der nächsten Version drin ist

Geschrieben von: bjoern Thu. 10. July 2008, 19:36

Wenn es keine Komplikationen dadurch gibt, ist die Erweiterung drin.

Geschrieben von: saschapi Thu. 10. July 2008, 21:32

jupieh

Geschrieben von: bjoern Sun. 27. July 2008, 15:33

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.

Geschrieben von: FireFlyer Thu. 6. November 2008, 18:06

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?

Geschrieben von: bjoern Fri. 7. November 2008, 12:08

Das Problem dürften die zig Module sein, die individuell programmiert sind. In ein Bugfixrelease gehört so etwas nicht rein. Für das nächste Mainrelease stehen die Chancen nicht schlecht.