Browserfehler "The page isn't redirecting properly"

[pateng]

Hallo alle,

beim Zugriff auf geschützte Seiten (nach erfolgreichem Login) erhalte ich anstatt der gewünschten Seite von Firefox folgende Fehlermeldung:

The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
* This problem can sometimes be caused by disabling or refusing to accept cookies.

IE bringt mir entsprechend einen Timeout, es handelt sich also wohl nicht um ein browserspezifisches Problem.

Dieser Fehler tauchte zwar schon mal in einem >>anderen Thread auf, dort aber in anderem Zusammenhang. Ausserdem gab es dort weiterführende Fehlermeldungen im error.log, die bei mir fehlen. Deshalb glaube ich, dass hier eine andere Ursache zugrunde liegt, und ich komme nicht weiter.

Die Situation sieht folgendermassen aus:
- Der Benutzer, mit dem ich eingeloggt bin, hat definitiv Zugriff auf die geschützte Seite (selbst mit sysadmin bekomme ich denselben Fehler)
- Contenido-Version: 4.6.8
- installiert auf localhost
- Cookies von localhost werden akzeptiert (ich sehe z.B. ein Cookie "sid_15_6" im "localhost"-Folder des Cookie-Menüs von Firefox)
- keine Fehlermeldungen im error.log
- das Ganze funktioniert problemlos mit Contenido 4.4.5 auf einem Webserver (also nicht localhost)

Nun mache ich folgende merkwürdige Beobachtungen:
- Wenn ich mich ins Backend einlogge, kann ich den entsprechenden, geschützten Artikel im Editor problemlos aufrufen, in der Preview kommt jedoch wieder der Fehler.
- der Unterschied in der aufgerufenen URL liegt anscheinend im URL-Parameter "contenido" (ist das so eine Art session-ID?), der im Edit-Modus mitgegeben wird. Hänge ich den Parameter "&contenido=xxx" an meine URL an, dann funktioniert's, nehme ich ihn weg, kommt wieder der Timeout.
- im access.log sehe ich folgendes:

(Aufruf der Seite)
127.0.0.1 - - [16/Jun/2006:15:28:06 +0200] "POST /cms/front_content.php?idcat=289 HTTP/1.1" 302 16344

(danach erfolgt eine Endlos-Loop mit folgender Meldung:)
127.0.0.1 - - [16/Jun/2006:15:28:06 +0200] "GET /cms/front_content.php?client=15&idcat=0&idart=0&lang=6&error=1 HTTP/1.1" 302 366

Weiss da jemand was?
Vielen Dank!

[HerrB]

Das kann einerseits eine Weiterleitung in einem Artikel sein (-> Artikeleigenschaften). Ansonsten bitte die V4.6.8.5 verwenden (siehe hier im Forum), in der V4.6.8 fehlt eine Komponente zur Berechtigungsprüfung (plugin).

Gruß
HerrB

[pateng]

Nein, eine Weiterleitung gibt es auf den betroffenen Artikeln nicht.

Gibt's denn schon eine V4.6.8.5?
Soweit ich im Bilde bin, ist im Downloadbereich auf www.contenido.de sowie bei sourceforge unter "Latest File Releases" (http://sourceforge.net/project/showfile ... p_id=35885) nur die Version 4.6.8 zu finden.

Und im Forum konnte ich zu 4.6.8.5 leider nix fnden

[MichFress]

prompt ausprobiert - die Suche gibt bei "4.6.8.5" in der Tat keine Treffer aus... ungünstig..

pateng, versuch es also bitte mal mit http://contenido.org/forum/viewtopic.php?t=12026 - ganz deutlich zu finden im Forum "Misc 4.6.x"...

[pateng]

super... vielen Dank!

[pateng]

Ansonsten bitte die V4.6.8.5 verwenden (siehe hier im Forum), in der V4.6.8 fehlt eine Komponente zur Berechtigungsprüfung (plugin).

Ich habe mir jetzt die Version 4.6.8_fix3 (Patchversion) installiert, aber leider ist das Problem immer noch dasselbe.
Könnte es was damit zu tun haben, dass ich das Ganze auf localhost laufen lasse?

[mvf]

Ich habe mir jetzt die Version 4.6.8_fix3 (Patchversion) installiert, ...

hähhhhhhhhh ???

nim doch einfach die, die man dir mehrfach angepriesen hat, 4.6.8.5
http://www.rezeptionist.de/contenidofix ... .6.8.5.zip

und interessant wäre auch noch welche denn die 4.6.8_fix3 (Patchversion) ist und wo du die her hast

[pateng]

Vielleicht hab ich das was falsch verstanden? Habe mich selbst schon gewundert, woher die Bezeichnung "fix3" kommt. Aber laut http://contenido.org/forum/viewtopic.php?t=12026 ist die "fix3"-Version ein Paket, das lediglich die geänderten Files der V4.6.8.5 enthält.
Oder hab ich da völlig falsch gelesen???
Na ja, ich greife dann jetzt halt doch zur Hammermethode und installiere die Vollversion. Mal sehen, ob's was bringt...

[pateng]

Leider, leider, leider.... bringt's auch nix

Habe mir jetzt die kompletten 4.6.8.5-Files installert (d.h. die Files unter htdocs ausgetauscht), neu gestartet usw. ... aber das Problem bleibt.

[mvf]

Leider, leider, leider.... bringt's auch nix

Habe mir jetzt die kompletten 4.6.8.5-Files installert (d.h. die Files unter htdocs ausgetauscht), neu gestartet usw. ... aber das Problem bleibt.

ah I see

allerdings kann ich nicht garantieren, dass die auch weiter gepflegt wurde, darum einfach mal die 4.6.8.5 probieren, die veielicht als separate installation auf den webserver legen, und wenn es dann immernoch probleme gibt, dann kann man wenigstens mal draufschauen, was bei local installs immer schwierig ist

[pateng]

Hab jetzt immerhin mal folgendes rausgefunden:

In der front_content.php ist es die Zeile 691 (header($errsite)), die eine Weiterleitung auf die Fehlerseite front_content.php?client=15&idcat=0&idart=0&lang=6&error=1 bewirkt, die dann wiederum einen HTTP-Error 302 zurückgibt.

Hat jemand ne Ahnung, was hier passiert bzw. warum an dieser Stelle die Variable $allow den Wert false zu haben scheint?

else
{
$allow = false;

$iterator = $_cecRegistry->getIterator("Contenido.Frontend.CategoryAccess");

while ($chainEntry = $iterator->next())
{
$value = $chainEntry->execute($lang, $idcat, $auth->auth["uid"]);

if ($value === true)
{
$allow = true;
break;
}
}

if (!$allow)
{
header($errsite);
}
}

[mvf]

Hab jetzt immerhin mal folgendes rausgefunden:

aber leider noch nicht eine ordentliche installation from the scratch mit der 4.6.8.5

[pateng]

aber leider noch nicht eine ordentliche installation from the scratch mit der 4.6.8.5

Ok, ich vermute jetzt mal, das bedeutet, dass ich...
1.) eine komplette neue 4.6.8-Instanz installieren muss (d.h. die Files auf den Server auspacken)
2.) die kompletten 4.6.8.5-Files in mein htdocs-Verzeichnis kopieren muss
und v.a. 3.) Setup ausführen muss!

Ist das richtig?

Jedenfalls habe ich das nun getan, genaugenommen habe ich den Upgrade von 4.4.5 auf 4.6.8 erneut durchgeführt, diesmal direkt auf Version 4.6.8.5, und zwar folgendermassen:

1.) Ich habe eine Kopie meiner bestehenden (und funktionierenden) 4.4.5-Installation samt Client erzeugt, gestartet und getestet (--> alles fehlerlos) und wieder gestoppt
2.) Ich habe sämtliche 4.6.8.5-Files ins htdocs kopiert
3.) Ich habe Contenido wieder gestartet
4.) Ich habe das Setup ausgeführt, und zwar ohne Fehler, ebenso ohne Einträge im upgrade_log (abgesehen von dem bereits bekannten "MySQL error 1060" den man einem >> anderen Thread zufolge ignorieren kann)

Ergebnis: Meine Seite läuft nach wie vor, aber beim Zugriff auf geschützte Kategorien bekomme ich immer noch denselben Fehler ... also quasi alles beim alten.

Irgendwie verstehe ich die Welt nicht mehr...

Eine Sache fällt mir noch ein: Wie ich sehe, gibt es seit Version 4.6.8 eine Unterscheidung von Backend- und Frontend-Benutzern. Muss ich hier irgendwas beachten/konfigurieren?

Die Benutzer, mit denen ich zugreifen will (z.B. der Client-Administrator) haben allesamt das "Frontend Access"-Flag für die fragliche Kategorie gesetzt, aber vielleicht funktioniert das ja gar nicht mehr so wie in der alten Version???

[HerrB]

Yep.

Erstelle zunächst einen Test-Account und eine Test-Gruppe unter Administration -> Frontend und teste damit alles.

Wenn es geht, findest Du unter Tips & Tricks eine Datei zur Migration der Frontend User-Accounts.

Wenn es bereits mit dem Test-Account nicht funktioniert, bitte PM an mich.

Gruß
HerrB

[pateng]

Ein kleiner Nachtrag:
Ich habe nun mal versucht, die front_content.php ein wenig zu "debuggen", mit folgendem Ergebnis...

Wenn ich meine geschützte Kategorie aufrufe, wird zunächst einmal - wie bereits oben beschrieben - in Zeile 691 ein Redirect auf die $errsite ausgelöst (warum, weiss ich zwar nicht, aber möglicherweise hat der User ja tatsächlich keinen Zugriff):

$allow = false;

$iterator = $_cecRegistry->getIterator("Contenido.Frontend.CategoryAccess");

while ($chainEntry = $iterator->next())
{
$value = $chainEntry->execute($lang, $idcat, $auth->auth["uid"]);

if ($value === true)
{
$allow = true;
break;
}
}

if (!$allow)
{
header($errsite);
}
}

Danach wird's interessant, denn beim Aufrufen der Fehlerseite wird ja erneut front_content.php ausgeführt, diesmal bleibt er aber in Zeile 349 hängen:

$idartlang = getArtLang($idart, $lang);

if ($idartlang === false)
{
header($errsite);
}

Da aus irgendeinem Grund die Variable $idartlang hier false ist, erzeugt das Skript also letztendlich einen Endlos-Redirect auf sich selbst.

der Wert von $errsite ist übrigens Location: front_content.php?client=15&idcat=0&idart=0〈=6&error=1

Hat irgendjemand eine Ahnung, was hier vor sich geht???