Unendliche Weiterleitungen bei contact_us Seite

[hbauer]

Also aus meiner Sicht ist das Problem für mich "gelöst". Die Konfiguration muss ich eh für meinen Shop anpassen und die Templates funktionieren dann ohne Anpassung.

Das Problem ist auf die contact_us Seite beschränkt und tritt wo anders nicht auf.

Habe ich etwas übersehen?

[hpzeller]

Wegen folgendem Code in der Datei includes/application_top.php

Code: PHP  [Auswählen]

// set the type of request (secure or not)
if (file_exists(DIR_WS_INCLUDES.'request_type.php')) {
  include_once (DIR_WS_INCLUDES.'request_type.php');
} else {
  $request_type = 'NONSSL';
}

die Frage, fehlt in deinem Shop eventuell die Datei includes/request_type.php ?

Gruss
Hanspeter

[noRiddle (revilonetz)]

Daran anlehnend:
Nun, ich denke, daß der springende Punkt $request_type ist, wie in meiner Antwort #13 angedeutet. Ich würde empfehlen sich den mal ausgeben zu lassen, wie in zitiertem Post angeregt. Evtl. kommen wir da ja auch einem, wenn auch in seltenen Server-Konfigurationen auftretenden, Bug auf die Spur.
Ich kann mir einen unendlichen Loop mom. nur dann vorstellen wenn $request_type fälschlicherweise NONSSL ist, weil es dann trotz

Code: PHP  [Auswählen]

$link = $connection == 'SSL' && (ENABLE_SSL || $request_type == 'SSL') ? HTTPS_SERVER : HTTP_SERVER;

aus der /inc//inc/xtc_href_link.inc.php und verwendet in diesem Code in der /shop_content.php

Code: PHP  [Auswählen]

if (ENABLE_SSL == true && $request_type == 'NONSSL' && !isset($_GET['action']) && $_GET['coID'] == '7') {
  xtc_redirect(xtc_href_link(FILENAME_CONTENT, 'coID='.(int) $_GET['coID'], 'SSL'));
}

zu einem unendlichen Loop führt, weil die Condition bei ENABLE_SSL true und $REQUEST_TYPE NONSSL dann immer wieder zutrifft und der Redirect dann immer wieder durchgeführt wird.

Gruß,
noRiddle

[GTB]

Das sehe ich auch so noRiddle.
Ich habe Hagen bereits per Mail nach dem $_SERVER Array gefragt.

Gruss Gerhard

[noRiddle (revilonetz)]

Okay, dann seid Ihr dem Problem ja auf der Spur und werdet es lösen. Bin gespannt.

Gruß,
noRiddle

[hbauer]

die Frage, fehlt in deinem Shop eventuell die Datei includes/request_type.php ?

ist da

Code: PHP  [Auswählen]

find . -name request_type.php
./includes/request_type.php
 

[hbauer]

Also der request_type steht immer auf NONSSL

[noRiddle (revilonetz)]

Na dann hätten wir es doch, dann pasiert genau das was ich in Antwort #17 gechrieben habe.

Gerhard klärt das aber ja mit dir, wenn ich richtig verstanden habe.

Gruß,
noRiddle

[hbauer]

Ich habe einen Verdacht. Bei mir liegt der Shop mit dem Apache hinter einem Nginx.

Nginx macht https://. Eine Proxy configuration geht intern auf den Apache mit http://

[noRiddle (revilonetz)]

:gelöscht: war Quatsch, ein Versehen, sorry.

Gruß,
noRiddle

[hbauer]

also ich glaube inzwischen zu verstehen woran es liegt. Es liegt aus meiner Sicht auch kein Fehler vor.

Noch mal zusammengefasst die Konfiguration bei mir

Frontend: Nginx mit https://www und Proxy auf Backend
Backend: Apache mit http://

Damit die URL für einen https Betrieb gebaut werden braucht es

Code: PHP  [Auswählen]

 defined('HTTP_SERVER') or define('HTTP_SERVER', 'https://www.'); // eg, http://localhost - should not be empty for productive servers
  defined('HTTPS_SERVER') or define('HTTPS_SERVER', 'https://www.'); // eg, https://localhost - should not be empty for productive servers
 

Dann gibt es noch die Einstellung die dem Shop sagen soll ob zwischen http und https umgeschaltet werden soll wenn es in den checkout geht

Code: PHP  [Auswählen]

defined('ENABLE_SSL') or define('ENABLE_SSL', true)

Das war früher mal richtig ist aber aus meiner Sicht nicht mehr zeitgemäß. Ich glaube kaum das heute diese Unterscheidung zwischen http und https noch gemacht wird, aber sei es drum.

Jetzt gibt es für das Contact_us Formular eine ganz besondere Abfrage die in meiner Konfiguration aus meiner Sicht überflüssig ist. Sie ist vermutlich eingeführt worden da man beim diesem Formal auf https umschalten wollte aber die Abfragen aus dem Checkout nicht greifen (Vermutung)

Code: PHP  [Auswählen]

f (ENABLE_SSL == true && $request_type == 'NONSSL' && !isset($_GET['action']) && $_GET['coID'] == '7') {
  xtc_redirect(xtc_href_link(FILENAME_CONTENT, 'coID='.(int) $_GET['coID'], 'SSL'));
}
 

Da aber der Shop glaubt er wäre mit http aufgerufen gibt "request_type" natürlich NONSSL aus und wir laufen in diese Dauerumleitung.

In meiner Konfiguration müsste also

Code: PHP  [Auswählen]

defined('ENABLE_SSL') or define('ENABLE_SSL', false)

gesetzt werden denn die Umschaltung des Shops beim Checkout ist ja nicht notwendig da ja eh alles über https läuft.

Hab ich was übesehen?

[Timm]

Moin

Ich denke dein Server ist falsch konfiguriert. Oder du hast irgendwo im Shop eine Weiterleitung die sich auf die coID 7 bezieht. Deshalb auch mein Tipp mal testweise die coid des Kontaktformulars zu ändern. Wenn es dann nicht mehr auftritt, hätte ich ein Backup des Shops nach dem Wert 7 durchsucht, ob es noch eine weitere Stelle als die in der shop_content.php gibt. Zb durch ein fehlerhaftes Shopupdate.

Ich hatte auch einen nginx mit dahintergeschaltetem apache bis vor einer Weile genutzt und mit den empfohlenen Einstellungen (beide Serverpfade mit https und enable ssl auf true) keinerlei Probleme mit dem Kontaktformular gehabt.

Gruss Timm

[hbauer]

ah. gut zu wissen.

Dann müsste es also einen Weg geben dem Shop beim Zugriff mit http vorzugauckeln das es kein NOSSL request type ist. Ich werde mal prüfen ob die nginx proxy konfiguration so etwas ermöglicht. proxy_set_header X-Forwarded-Proto https scheint ein Kandidat zu sein. Werde ich mal testen

[noRiddle (revilonetz)]

Ich dachte die Sache wäre geklärt. Ich hatte doch erklärt wie der Loop zustande kommt wenn $request_type NONSSL zurückgibt.
GTB weiß das mit ENABLE_SSL und ist natürlich auch der Meinung, daß das abgeschafft gehört.
Es wird jedoch an vielen Stellen im Code abgefragt und es muß sichergestellt sein, daß nichts übersehen wird wenn man das rauswirft, ist also aufwändig.

Was ich nicht verstehe ist dies:

...
Frontend: Nginx mit https://www und Proxy auf Backend
Backend: Apache mit http://
...

Wieso Backend ohne SSL ?

@FräuleinGarn
Natürlich bezieht sich der Loop auf coID 7, den Code dazu aus der /shop_content.php und auch die Zusammenhänge habe ich doch nun wirklich bereits dreimal dargelegt. Klar liegt es auch an Zusammenhängen aber hauptsächlich am $request_type der NONSSL zurückgibt wo er SSL zurückgeben sollte.

Ich denke die Sache ist klar und ja, ENABLE_SSL ist obsolet, wie an anderer Stelle auch bereits von GTB bestätigt.
Nun lasst uns alle unsere Arbeit machen... .

Gruß,
noRiddle

[hbauer]

Was ich nicht verstehe ist dies:

...
Frontend: Nginx mit https://www und Proxy auf Backend
Backend: Apache mit http://
...

Wieso Backend ohne SSL ?

Ich kenne keinen Grund warum ich auf meinem Server den speicher internen http Verkehr verschlüsseln sollte und möchte mir den Aufwand sparen dafür ein Zerifikat zu pflegen (auch wenn es wenig aufwand ist)