Neu Installationsproblem bei Oxid 4.10.2 (Connector 1.2): Response:<empty> core.connector.auth

[a1x]

Hallo,

ich habe gerade versucht, den Connector zu installieren. Leider erfolglos. WaWi meldet beim Einrichten der Verbindung immer einen Fehler: "Exception bei core.connector.auth: core.connector.auth hat keine Daten zurückgegeben. Response:<Empty>".
Im global-*. log auf dem Server steht: "global.ERROR: Exception: SessionException - File: phar:///home/sites/siteXX/web/ shop/modules/jtl-connector/jtlconnector.php/vendor/jtl/connector/src/jtl/Connector/Application/Application.php - Line: 571 [] []"

Wenn ich die Connector-URL von Hand aufrufe, erhalte ich die erwartete "Invalid Request" JSON-Ausgabe. Im Backend ist das Modul aktiv, alle Checks sind grün, Passwort wird angezeigt, PHP Version ist 5.6.30. Bei der Installation bin ich nach https://guide.jtl-software.de/Fall_1:_Daten_von_Oxid_zu_JTL-Wawi_übertragen vorgegangen.

An das Apache Error Log komme ich leider gerade nicht heran (versuche ich über den Hoster zu bekommen), im Access-Log sind 3 Requests:
"GET /shop/jtlconnector//dbeS/mytest.php/ HTTP/1.1" 404 20460 "-" "JTL-Wawi" 195 13068
"POST /shop/jtlconnector/ HTTP/1.1" 200 303 "-" "-" 1054 4578
"POST /shop/jtlconnector/ HTTP/1.1" 200 - "-" "-" 519 367

Weiß jemand Rat ? Muss der erste Request mit dem mytest.php 404en ?

Alex

 

[a1x]

Ich könnte mir vorstellen, woran das liegt, aber weiss leider nicht, wie man das beheben kann. Ich habe mal testweise SSL ausgemacht und nach dem Klick auf "Testen" an der Leitung gelauscht. Da geht zuerst ein POST-Request an diese mytest.php (ohne / am Ende), den ich oben im Access- Log wohl übersehen habe. Da ist auch die Anmeldung drin. In der Oxid .htaccess steht nun aber

RewriteCond %{REQUEST_URI} !(\/admin\/|\/core\/|\/application\/|\/export\/|\/modules\/|\/out\/|\/setup\/|\/tmp\/|\/views\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !(\.html|\/|\.jpg|\.css|\.pdf|\.doc|\.gif|\.png|\.js|\.htc|\.svg)$ %{REQUEST_URI}/ [R=301,L]

drin, so dass ich denke, dass die Daten nie an Connector ankommen, da vorher Apache schon direkt einen Redirect auf mytest.php/ macht. Das der dann im folgenden keine gültige Session hat, ist dann verständlich, da in dem Request das Passwort drin war. Die .htaccess ist aber die vom Shop, die habe ich dort nicht verändert.

 

[daniel.jtl]

Mit dem Call auf mytest wird seitens der Wawi geprüft ob noch ein Connector der ganz alten Generation läuft.
Das dieser ins Leere läuft ist somit nicht weiter tragisch.

Wenn die Authentifizierung schon fehlschlägt, liegt das zu 90% an fehlenden Schreibrechte des db-Folders bzw. der darin enthaltenen Dateien.

 

[a1x]

Im Error- Log des Apache ist kein Eintrag, Berechtigungen auf die DB-Datei und das DB-Verzeichnis sind richtig (mehrfach geprüft, auch neu hochgeladen und Rechte neu gesetzt, außerdem gehören die dem Webserver).
Nach dem myTest sagt Wireshark (etwas gekürzt):

POST / shop/jtlconnector/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded

jtlrpc=%7b%0d%0a++%22method%22%3a+%22connector.identify%22%2c%0d%0a++%22params%22%3a+null%2c%0d%0a++%22jtlrpc%22%3a+%222.0%22%2c%0d%0a++%22id%22%3a+%2296b784ac1e16400997444b14a77e8064%22%0d%0a%7d

HTTP/1.1 200 OK
Content-Type: application/json

{"result":null,"error":{"code":0,"message":"No session","data":"Exception: SessionException - File: phar:\/\/\/home\/sites\/site60\/web\/shop\/modules\/ jtl-connector\/jtlconnector.php\/vendor\/jtl\/connector\/src\/jtl\/Connector\/Application\/Application.php - Line: 571"},"jtlrpc":"2.0","id":"unknown"}

POST /shop/jtlconnector/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 252

jtlrpc=%7b%0d%0a++%22method%22%3a+%22core.connector.auth%22%2c%0d%0a++%22params%22%3a+%7b%0d%0a++++%22token%22%3a+%22XXXXXkl%22%0d%0a++%7d%2c%0d%0a++%22jtlrpc%22%3a+%222.0%22%2c%0d%0a++%22id%22%3a+%22b404e4a87aea46c886530bfbb7a28a59%22%0d%0a%7d

HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8


Bekommt man das irgendwie eingestellt, dass der einen Stack Trace mit speichert ? In der Zeile 571 wird ja nur die SessionException geworfen, die Methode muss aso schon mit null als Session aufgerufen worden sein...

 

[daniel.jtl]

Ist in jedem Fall eindeutig ein Datenbank/Session-Problem. Der Server hat beim nächsten Aufruf offenbar bereits die Session-Daten verloren.
Wenn du selber nicht dahinter kommst, sollte sich das dein Hoster oder ein Servicepartner angucken...

 

[a1x]

Die Session mag er ja, so wie ich das vermute, gar nicht erst anlegen. Blöd ist nur, dass da kein Stacktrace dabei ist, damit man sehen könnte, wo der versucht, die Session einzutragen. Kann man das Logging hochdrehen ? Ich hatte in der Zeile 571 mal nachgeschaut, aber die Methode muss schon mit null als Session aufgerufen worden sein, damit da der Fehler kommt. Ich werde später mal versichen, die sqlite-DB per Testscript zu öffnen, um zu sehen, ob es da einen Fehler gibt, der nicht ausgegeben wird. Ohne Anhaltspunkte ist es mir dann doch zu kompliziert, direkt in den vielen Klassen der Phar zu suchen...
Die PHP Sessionverwaltung kann es eigentlich nicht sein, da auf dem Server noch jede Menge Zeug läuft, was die auch benutzt.

 

[daniel.jtl]

Du musst auch nicht in unserem Code suchen. Ich kann dir versichern dass es an deiner Server-Konfiguration liegt, und nicht an unserem Code.
Die Session-Verwaltung ist direkt im Connector-Core, welcher in sämtlichen Connectoren zum Einsatz kommt. Also somit nicht nur Oxid, sondern auch Presta, Shopware, Gambio, Modified, WooCommerce und alle anderen Systeme.
Wäre da ein Fehler, wären somit tausende User betroffen und bei niemandem würde es funktionieren.

 

[a1x]

Ich will mit dem Test eigentlich auch ausschließen, das das sqlite Modul bei dem Hoster einen Schuss weg hat... ich habe leider nix anderes dort, was sqlite benutzt, daher wollte ich da mal ein Testscript bauen. Irgendwo dran muss es ja liegen.Ich wollte auf keinen Fall damit sagen, dass es an eurem Code des Connectors liegt, wollte aber halt nachschauen, was der genau macht, um zu sehen, was da außer PHP Sessions und sqllite auf dem Server noch so kaputt sein kann. Weiss aber noch nicht, wann ich dazu komme, das ist bei mir nur ein Nebenjob...

 

[daniel.jtl]

In dem Fall nimmst du vor allem aber auch besser den richtigen Source der ja öffentlich verfügbar ist.
In einem Phar zu arbeiten ist zum einen vollkommen unübersichtlich, zum anderen ja auch nicht vorgesehen und fehleranfällig...

 

[a1x]

Am SQLite3 liegt es nicht, ich kann problemlos die DB anschauen und auch Daten in die DB schreiben, dort kein Problem (die DB-Datei in dem Connector-Download könnte aber mal ein VACUUM vertragen ).
Den Schalter "SetEnv APPLICATION_ENV development" habe ich mittlerweile auch gefunden, und in der session-*. log steht:
[2018-01-22 22:39:28] session.DEBUG: Open session with savePath (/home/sites/site60/tmp/) and sessionName (jtlConnector) [] []
[2018-01-22 22:39:28] session.DEBUG: Read session with id (5n0iope91ashfbdhd7vkc7tn54) [] []
[2018-01-22 22:39:28] session.DEBUG: Session started with id (5n0iope91ashfbdhd7vkc7tn54) [] []

Die rpc-*.log dazu:
[2018-01-22 22:39:27] rpc.DEBUG: RequestPacket: {"method":"connector.identify","params":null,"jtlrpc":"2.0","id":"dff5dc5e17db44c490c1c1ed5bb5bbf0"} [] []
[2018-01-22 22:39:27] rpc.DEBUG: {"result":null,"error":{"code":0,"message":"No session","data":"Exception: SessionException - File: phar:\/\/\/home\/sites\/site60\/web\/ shop\/modules\/jtl-connector\/jtlconnector.php\/vendor\/jtl\/connector\/src\/jtl\/Connector\/Application\/Application.php - Line: 571"},"jtlrpc":"2.0","id":"unknown"} [] []
[2018-01-22 22:39:28] rpc.DEBUG: RequestPacket: {"method":"core.connector.auth","params":"{\"token\":\"XXXX\"}","jtlrpc":"2.0","id":"7149ac19cd7d4ff3a610486ac4424698"} [] []
[2018-01-22 22:39:28] rpc.DEBUG: Params: {"token":"XXXX"} [] []

Kein write, kein close in der session.log. Komisch. Aber das dann nichts in der DB stehen kann, wenn kein write aufgerufen wurde, ist logisch. Wieso schreibt der die Session am Ende nicht ? Am Code liegt es vermutlich nicht, da wird session_write_close als shutdown_function registriert, nur aus irgendeinem Grund mag PHP (5.6.30, falls das hilft) das nicht ausführen, oder aber bei der Ausführung geht was schief, was dann aber nicht mehr protokolliert wird.
Memory Limit ist auf 256M, in dem Check-Script steht 128M, sollte passen. Außerdem steht nichts von "Memory exceeded" im Apache Error-Log (immernoch leer), aus dem Grund hat er also auch nicht abgebrochen.
Wieso es überhaupt (der Zeit nach) nur für den 2. Request Einträge in der session.log gibt weiss ich auch nicht, könnte aber mit dem Problem zusammenhängen.

 

[daniel.jtl]

Ich würde ich dir generell mal raten deine PHP Version zu wechseln. In Verbindung speziell mit 5.6.30 sind diverse Probleme bekannt, abgesehen davon ist 5.6 ja bereits lange veraltet und offiziell in der End of Life Phase. Selbst PHP 7.0 ist ja schon vorbei...

 

[a1x]

Probiert habe ich das (mit 7.1), aber da tut der Shop nicht mehr. Und den neu aufzusetzen mit 6 ist zeitlich nicht drin wegen etlicher Anpassungen am Shop. Wenn das die einzige Lösung ist, muss ich mal schuen, ob man die 4.10 vom Shop patchen kann, damit die mit 7.1 läuft.

 

[itratosTeam]

Hallo a1x,

wir könnten uns das gerne mal anschauen, haben einige Kunden mit php5.6 und OXID bis 4.10.x.
Sende mir auch mal eine php:info