1. Wenn Ihr uns das erste Mal besucht, lest euch bitte zuerst die Foren-Regeln durch.
    Information ausblenden

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

Dieses Thema im Forum "Oxid-Connector" wurde erstellt von a1x, 21. Januar 2018.

  1. a1x

    a1x Neues Mitglied

    Registriert seit:
    21. Januar 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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
     
  2. a1x

    a1x Neues Mitglied

    Registriert seit:
    21. Januar 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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.
     
  3. daniel.jtl

    daniel.jtl Super-Moderator Mitarbeiter

    Registriert seit:
    12. März 2014
    Beiträge:
    1.235
    Zustimmungen:
    21
    Punkte für Erfolge:
    38
    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.
     
  4. a1x

    a1x Neues Mitglied

    Registriert seit:
    21. Januar 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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...
     
    Zuletzt bearbeitet: 22. Januar 2018
  5. daniel.jtl

    daniel.jtl Super-Moderator Mitarbeiter

    Registriert seit:
    12. März 2014
    Beiträge:
    1.235
    Zustimmungen:
    21
    Punkte für Erfolge:
    38
    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...
     
  6. a1x

    a1x Neues Mitglied

    Registriert seit:
    21. Januar 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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.
     
  7. daniel.jtl

    daniel.jtl Super-Moderator Mitarbeiter

    Registriert seit:
    12. März 2014
    Beiträge:
    1.235
    Zustimmungen:
    21
    Punkte für Erfolge:
    38
    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.
     
  8. a1x

    a1x Neues Mitglied

    Registriert seit:
    21. Januar 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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...
     
  9. daniel.jtl

    daniel.jtl Super-Moderator Mitarbeiter

    Registriert seit:
    12. März 2014
    Beiträge:
    1.235
    Zustimmungen:
    21
    Punkte für Erfolge:
    38
    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...
     
  10. a1x

    a1x Neues Mitglied

    Registriert seit:
    21. Januar 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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.
     
  11. daniel.jtl

    daniel.jtl Super-Moderator Mitarbeiter

    Registriert seit:
    12. März 2014
    Beiträge:
    1.235
    Zustimmungen:
    21
    Punkte für Erfolge:
    38
    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...
     
  12. a1x

    a1x Neues Mitglied

    Registriert seit:
    21. Januar 2018
    Beiträge:
    7
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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.
     
  13. itratosTeam

    itratosTeam Mitglied

    Registriert seit:
    19. April 2007
    Beiträge:
    258
    Zustimmungen:
    8
    Punkte für Erfolge:
    18
    Beruf:
    Director
    Ort:
    Bamberg
    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
     

Diese Seite empfehlen

Verstanden Weitere Informationen

JTL-Software benutzt Cookies, teilweise von Drittanbietern, um Funktionalitäten auf unseren Webseiten zu ermöglichen.