Neu Shop abgleich funktioniert nicht, Lösungsansätze gesucht

[Indy1]

Hallo !
Ich habe einen Hauptshop, und 5 SFE´s (alle unter 500 Artikel). Alle haben mit dem Multishop-Modul bis vor wenigen Wochen einwandfrei funktioniert.

Die 6 Shops sind auf 3 Webspaces (unterschiedliche Server) aufgeteilt. 2 davon funktionieren, die anderen 4, die alle auf dem gleichen Server liegen funktionieren nicht.
Da bekomme ich schon beim Verbindungstest einen Fehler ("forbidden").

Mittlerweile wurden alle Shops (da waren noch Shop4 dabei) auf die aktuellste Version upgedated, ohne Erfolg, der Fehler bleibt.

Mein Provider meint es wurde von seiner Seite nichts geändert, JTL meint ein forbidden kann nur vom Server kommen.

Jetzt sitze ich mit 4 nicht funktionierenden Shops zwischen den Stühlen und habe keine Ahnung was ich meinem Provider geben kann damit er den Fehler (der ja wohl bei Ihm sein muss) finden kann.
Gibt es irgendwelche Tips die ich meinem Provider geben kann ? Oder Erfahrungswerte ?
Was genau passiert denn bei dieser Abfrage - was wird da wo hin geschickt, oder was sollte als Antwort kommen ?

Vielen Dank !

lg, Karl Indra

 

[Rainer S]

Hallo, was sagt denn der Hoster zu den im Ticket bereits gegebenen Informationen?

Entweder eine Firewall die den Zugriff blockiert oder ein Securitymodul. Das kann einzig und alleine nur Ihr Hoster helfen.
Als Hoster sollte dieser doch schon selbst schauen können anhand der Logs was genau passiert auf dem eigenen Server.

 

[Indy1]

Hallo, was sagt denn der Hoster zu den im Ticket bereits gegebenen Informationen?

Entweder eine Firewall die den Zugriff blockiert oder ein Securitymodul. Das kann einzig und alleine nur Ihr Hoster helfen.
Als Hoster sollte dieser doch schon selbst schauen können anhand der Logs was genau passiert auf dem eigenen Server.

Der Hoster meint es läge weder an Mod_Security, noch an falschen SSL-Zertifikaten oder so.
Er beharrt darauf das Sie nichts geändert hätten und wollen von mir wissen welche Abfragen von der Wawi wohin geschickt werden, damit Sie das prüfen können...

Die Zugriffe von der Adresse "212.186.183.11" führen serverseitig zu einer Redirect-Loop. Haben Sie eine Idee, weshalb es zu diesen Weiterleitungen in der Applikation kommt?

[Wed Oct 23 17:45:34.284490 2024] [core:error] [pid 747556:tid 747605] [client 212.186.183.11:55046] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
[Wed Oct 23 17:45:55.876250 2024] [core:error] [pid 751254:tid 751290] [client 212.186.183.11:55052] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

Keine Ahnung was da von wo wohin geht - ich weiß nur das es komisch ist das von 2 Servern die Zugriffe funktionieren und vom dritten nicht - natürlich genau der auf dem die meisten der Shops liegen.
Die seiten inkl. der dazugehörigen Domains auf einen der beiden funktionierenden Server übersiedeln Sie nur kostenpflichtig (ohne einen Preis zu nennen) da ja "der Fehler nicht bei Ihnen liegt"....

_Und solange Sie nicht übersiedeln und dann feststellen das es dort geht (so hoffe ich jedenfalls) geht das hin- und her...

Die Shops sind mittlerweile alle im Wartungsmodus, da ja keine Bestellungen abgeholt werden, was extrem unbefriedigend ist...

 

[Rainer S]

Der Hoster meint es läge weder an Mod_Security,

Sorry, aber hat er es wirklich mal deaktiviert, und Firewall geprüft. Ich würde gerne mehr helfen aber das Problem ist der Hoster.

 

[Rainer S]

Request exceeded the limit of 10 internal redirects

Noch als nachtrag, prüfe mal ob die Shop URL wirklich 100% korrekt hinterlegt ist. also jenachdem ob der Shop mit oder ohne www. installiert ist und auch https:// in der Wawi eingetragen ist und nicht nur http://

 

[css-umsetzung]

Das hört sich ja so an als wenn JTL selbst schon draufgeschaut hat?
Wenn nicht dann wäre das die beste Lösung, andernfalls sollte ein SP dir auch helfen können.

Hast du schon probiert von dem Server wo der Abgleich gestartet wird, einen direkten Aufruf auf /dbeS/mytest.php durchzuführen?

 

[Rainer S]

Das hört sich ja so an als wenn JTL selbst schon draufgeschaut hat?

ja wir haben drauf geschaut deshalb tätige ich hier auch die gleiche aussage wie im Ticket. Das nur um Missverständnisse zu vermeiden.

mytest.php aufruf geht von aussen deshalb kann es nur sein das der Client ausgeschlossen wird durch eine Firewall oder mod Security. Der Hoster streitet es aber wehement ab wie es ausschaut.

 

[css-umsetzung]

Aha.
Den Loop finde ich recht merkwürdig

ob mod_security aktiv ist könnte man ja theoretisch über die htaccess prüfen.

 

[Indy1]

Hallo !
Erstmal vielen Dank für eure Hilfe !
Das ist die letzte Antwort die ich bekommen habe vom Hoster:
"danke für die Rückinfos!

Ich würde es gerne genauer Debuggen, dazu müsste ich es jedoch irgendwie reproduzieren können. Wie sieht der Request aus, den die Warenwirtschaft absendet? Sehen Sie, was zurückgeliefert wird? Gibt es eine Möglichkeit, wie wir diesen Request nachstellen können?"

Ich werde ihn jetzt mal auffordern mod:security mal komplett zu deaktivieren - richtig ?

Danke !
lg, Karl

 

[css-umsetzung]

Ich werde ihn jetzt mal auffordern mod:security mal komplett zu deaktivieren - richtig ?

Ja das ist das beste

 

[Indy1]

Hi !
Ich bekomme nach wie vor keine, oder Antworten mit denen ich mangels technischem Hintergrund nichts anfangen kann...

wegen mod:security:

"Hallo Herr Indra,
bezüglich Mod_Security: dies wurde als Ursache schon ausgeschlossen. Es wäre zudem auch bei den anderen Webspaces in Verwendung.
Falls ich es irgendwie reproduzieren könnte, würde ich es gerne näher im Detail prüfen."

dann habe ich geschrieben das sowohl im Shop, als auch in der htaccess soweit ich sie gefunden habe alle Umleitungen deaktiviert sind, die Seite dennoch abhängig von der Schreibweise umgeleitet wird...
Ich habe im Shopsystem und in der htAccess sämtliche Umleitungen auskommentiert bzw. deaktiviert.

Trotzdem wird hier mehrfach umgeleitet.

Eventuell kommt es hier (wo auch immer diese Umleitungen eingetragen sind) zu dieser Endlosschliefe ?

+ http://sockenwolle-online.at - 503 Service Unavailable - http://sockenwolle-online.at/ - 200 OK
+ https://sockenwolle-online.at - https://sockenwolle-online.at/ - 200 OK
+ http://www.sockenwolle-online.at - 302 Found - http://sockenwolle-online.at/ - 200 OK
+ https://www.sockenwolle-online.at - https://sockenwolle-online.at/ - 200 OK

..und das habe ich als Antwort bekommen...

Bezüglich der Weiterleitungen: serverseitig sind hier keine Weiterleitungen eingerichtet, diese müssen demnach von der Applikation kommen.
Falls Sie eine Möglichkeit haben, wie wir die externen Requests nachstellen können, prüfen wir es gerne weiter im Detail.

Wo könnte ich feststellen ob und welche Umleitungen eingetragen sind, bzw. welche Umleitungen greifen denn wo ein ?
Und - wie schauen diese externen Requests aus die da scheinbar in eine unendlich-Schleife geschickt werden ?

Langsam wird das echt mühsam...

Mittlerweile bin ich auch draufgekommen das in dem jetzt auf die aktuellste Version upgedatetem Shop viele Seiten nicht funktionieren...
Wenn ich z.B. auf "Bestellungen" gehe, oder auf Zahlungsarten, Versandarten... überall nur eine weiße Seite

Danke !
lg, Karl

 

[css-umsetzung]

Dann lasse endlich jemanden draufschauen der weiß was er tut und das richtig debuggen, bzw. mit deinem Hoster tachless reden kann wenn er schuld ist.

Aber wenn du bei vielen Dingen eine weiße Seite hast, dann ist wohl eher der Shop das Problem.

Also nimm Geld in die Hand, lehn dich zurück und lass das Leute machen die das können.

 

[Indy1]

Dann lasse endlich jemanden draufschauen der weiß was er tut und das richtig debuggen, bzw. mit deinem Hoster tachless reden kann wenn er schuld ist.

Aber wenn du bei vielen Dingen eine weiße Seite hast, dann ist wohl eher der Shop das Problem.

Also nimm Geld in die Hand, lehn dich zurück und lass das Leute machen die das können.

Hi !
Du kannst mir gerne ein Angebot machen was mich das kosten würde....
Wenn der Hoster schuld ist werde ich ihm diesen Aufwand eh weiterverrechnen... wenn das vom Shop kommt werde ich auch hier meine Rückschlüsse ziehen müssen...

Zuerst werden die Pakete von JTL geändert und der Preis vervielfacht sich... dann sind plötzlich 4 Shops nicht mehr erreichbar.
"Zu alt und nicht supportet", dann nach dem update auf die aktuellste Version funktionieren Sie gar nicht mehr und jetzt soll der Hoster und/oder der Shop daran schuld sein obwohl von meiner Seite nie etwas geändert wurde (bis zu dem Zeitpunkt wo alles schlecht, falsch, zu alt war...)

Also - ich warte gerne auf ein Angebot zu den Kosten einer Fehlerbehebung...

lg, Karl

 

[John]

Du kannst mir gerne ein Angebot machen was mich das kosten würde....
Also - ich warte gerne auf ein Angebot zu den Kosten einer Fehlerbehebung...

Die Anfrage ist unseriös.

Du kannst einen Stundensatz erfragen und dann dauert es so lange wie es dauert. Oder Du buchts eine Stunde und schaust, wie weit jemand kommt.
Niemand repariert irgendwas zum (fairen) Festpreis, ohne Details zu kennen.

 

[css-umsetzung]

Die Anfrage ist unseriös.

Ja ist sie

Man verhandelt das auch nicht öffentlich, in der Regel scheibt der Auftraggeber den Auftragnehmer an.

Mein Stundensatz beträgt 120,-
Ich gehe aber davon aus, dass nach einer Stunde klar ist, was das eigentliche Problem ist.

Das kann aber bestimmt auch jeder andere SP der sich mit Shops beschäftigt erledigen.

 

[Indy1]

Entschuldigt bitte meine unseriöse herangehensweise....
Ich finde es ebenfalls unseriös wie ein funktionierendes System auf einmal von einer oder mehreren Seiten geändert wird und man dann alleine im Regen stehen lassen wird, aber das ist ein anderes Thema.

Da ich bereits "Kunde" bei Hrn. Petermann bin werde ich mich hier mal auf offiziellen Wegen melden.

Ich danke für eure Antworten soweit und bitte nochmals um Entschuldigung für meine ungewollte unseriöse herangehensweise.

lg, Karl

 

[css-umsetzung]

Zur Info:
das Problem mit der weißen Seite kam durch ein altes 4er PayPal Plugin was noch installiert war.

Das Problem, dass die Wawi sich nicht mit dem Shop Verbinden kann liegt zu 99% daran, weil die WAWI keinen User-Agenten mehr sendet.
Der Server blockt Requests, wenn der User-Agent nicht gesendet wird.

Ich gehe davon aus, dass der Serverbetreiber meine Vermutung bestätigen wird, denn wenn ich einen Curl Aufruf ohne Agenten mache, werde ich auch gesperrt.

mode_security ist auf dem Server nicht aktiv, das habe ich getestet.

 

[NoOne]

Welche Wawi-Version sendet denn keinen User-Agent? Das würde mich noch interessieren. 1.8 und 1.9 senden definitiv generell einen. Das müsste dann ja ein Bug in einer Minor-/Patch-Version sein.

 

[css-umsetzung]

Nein, auch die 1.7er sendet keinen Useragenten, jedenfalls nicht, wenn es um den Test der Anbindung geht.
Der Worker sendet einen wie es scheint.

Das hier ein Auszug aus meinem Log, aus meinem Testshop, das kommt von meiner IP

Ich war zu dieser Zeit nicht am Rechner

00:13:32    93.209.90.126                JTL-Wawi/1.9.5.0 (Windows NT 6.2.9200.0; .NET 4.8 (CLR 3.6.51653.92701); x86_64)
/shop/dbeS/mytest.php
Array
(
    [id] => mytest
    [userID] => ****
    [userPWD] => *******
    [uID] => *****
    [uPWD] => *****
    [kKunde] => 10
    [kBestellung] => 198
    [kLieferadresse] => 0
    [kZahlungseingang] => 0
    [wawiversion] => 195000
)

---------------------------------------------------------------------------------
00:13:32    93.209.90.126                unknown
/shop/dbeS/mytest.php
Array
(
    [id] => mytest
    [uID] => *****
    [uPWD] => *****
    [kKunde] => 10
    [kBestellung] => 198
    [kLieferadresse] => 0
    [kZahlungseingang] => 0
    [wawiversion] => 1950000000
)

---------------------------------------------------------------------------------
00:13:32    93.209.90.126                unknown
/shop/dbeS/Brocken_xml.php
Array
(
    [id] => Brocken_xml
    [userID] => *****
    [userPWD] => *****
    [b] => ODBhY2MzNDdlWndrWXRnQUFKUE5CSjBTZmNPdEZ2ZEJ0OFFWWE9LOTNKSGpMS0dQT0c2aldRUTR0UVMwd25KRDAwa0NrODlOeE9FVUVOZ01rWGhVSHY2Qm41aXE5emhqcG1yVyt2LytJTEJ4dHVEdjUydElraE5jZkxXRUhtYVlKSXZCQ3pXT1ZlOEJoRVRocXNjUT1hYzNlYTlhN2MzNQ==
)

 

[NoOne]

Okay, an den Verbindungstest hab ich da nicht gedacht, nur an den Abgleich an sich. Well, gut zu wissen.