differenziertere Error 40x, Erweiterung der default Errorsite bei nicht Online/gesperrt |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
differenziertere Error 40x, Erweiterung der default Errorsite bei nicht Online/gesperrt |
Thu. 31. May 2007, 09:05
Beitrag
#1
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
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 |
|
|
Thu. 31. May 2007, 12:56
Beitrag
#2
|
|
TRAIL AND ERROR SPECIALIST Gruppe: AdvancedMembers Beiträge: 1.708 Mitglied seit: 27.06.2006 Wohnort: Hansestadt Rostock, Deutschland Mitglieds-Nr.: 9 |
grundsätzlich ist es wünschenswert wenn auf einer website überhaupt keine error-seiten erscheinen
-------------------- cheers, Alex
|
|
|
Thu. 31. May 2007, 13:21
Beitrag
#3
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 627 Mitglied seit: 30.06.2006 Mitglieds-Nr.: 25 |
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 -------------------- feniweb
_____________________________________________________________________________ Wer kämpft, kann verlieren. Wer nicht kämpft, hat schon verloren. (Bertolt Brecht) |
|
|
Thu. 31. May 2007, 14:31
Beitrag
#4
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
Polemik:
ZITAT grundsätzlich ist es wünschenswert wenn auf einer website überhaupt keine error-seiten erscheinen ... das kommt auf den Blickwinkel an @feniweb, eine implementation habe schon fertig, kannst du haben -> PM. Gruß |
|
|
Thu. 31. May 2007, 15:17
Beitrag
#5
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 102 Mitglied seit: 24.07.2006 Mitglieds-Nr.: 159 |
ZITAT @feniweb, eine implementation habe schon fertig, kannst du haben -> PM. Michhintenanstell -------------------- grüsse fo.x
|
|
|
Thu. 31. May 2007, 15:20
Beitrag
#6
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
Ich würds auch toll finden! User mit abgelaufener Session kommen wieder zum Login, andere Fehler auf die echte 404er-Seite!
Tiggr -------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Thu. 31. May 2007, 15:32
Beitrag
#7
|
|
TRAIL AND ERROR SPECIALIST Gruppe: AdvancedMembers Beiträge: 1.708 Mitglied seit: 27.06.2006 Wohnort: Hansestadt Rostock, Deutschland Mitglieds-Nr.: 9 |
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 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. -------------------- cheers, Alex
|
|
|
Thu. 31. May 2007, 15:44
Beitrag
#8
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 853 Mitglied seit: 16.06.2006 Wohnort: Wien / Österreich Mitglieds-Nr.: 2 |
Z.B. hat vor kurzem ein Kunde die Startseite offline geschallten. Es kam nicht mal eine Fehlermeldung oder Ersatzseite 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. -------------------- SEFRENGO | a free choice ... again!
|
|
|
Thu. 31. May 2007, 17:00
Beitrag
#9
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
Patch-Download hinzugefügt.
Gruß |
|
|
Thu. 22. November 2007, 18:39
Beitrag
#10
|
|
Member Gruppe: Members Beiträge: 35 Mitglied seit: 15.07.2006 Mitglieds-Nr.: 142 |
Moin,
mal als konkrete Frage an Björn: Findet dieser Patch seinen Weg in die neue Sefrengo-Version? Gruß, Nils |
|
|
Fri. 23. November 2007, 13:12
Beitrag
#11
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
Ich habe mir den Patch angeschaut und denke, das können wir machen. Eventuell gibt es noch ein paar Änderungen im Code.
-------------------- Es wird, es wird...
|
|
|
Thu. 10. July 2008, 17:34
Beitrag
#12
|
|
Advanced Member Gruppe: Moderators Beiträge: 911 Mitglied seit: 26.06.2006 Wohnort: Essen; Ruhrgebiet Mitglieds-Nr.: 4 |
Nachdem ich das etwas verpennt hab, würd ich gern wissen ob das in der nächsten Version drin ist
-------------------- |
|
|
Thu. 10. July 2008, 19:36
Beitrag
#13
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
Wenn es keine Komplikationen dadurch gibt, ist die Erweiterung drin.
-------------------- Es wird, es wird...
|
|
|
Thu. 10. July 2008, 21:32
Beitrag
#14
|
|
Advanced Member Gruppe: Moderators Beiträge: 911 Mitglied seit: 26.06.2006 Wohnort: Essen; Ruhrgebiet Mitglieds-Nr.: 4 |
jupieh
-------------------- |
|
|
Sun. 27. July 2008, 15:33
Beitrag
#15
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
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.
-------------------- Es wird, es wird...
|
|
|
Thu. 6. November 2008, 18:06
Beitrag
#16
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 446 Mitglied seit: 12.09.2006 Wohnort: Bamberg Mitglieds-Nr.: 235 |
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? |
|
|
Fri. 7. November 2008, 12:08
Beitrag
#17
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
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.
-------------------- Es wird, es wird...
|
|
|
Vereinfachte Darstellung | Aktuelles Datum: 26.9.24 - 10:41 |