Hallo zusammen, gibt es ein Plugin das die Anfragen/Antworten per REST-API speichert? Wo kann man am besten eine LOG-Funktion(Speichern in eine Datei) einfügen? Oder wie kann man am besten Schnittstellenprobleme analysieren? Grüße Ludwig
Hi, du kannst dich einfach auf Enlight_Controller_Action_PreDispatch_Api registrieren, dann wirst du vor jedem Request “benachrichtigt”. Dort könntest du dir dann auch alle Anfrage-Daten aus $args->getSubject()->Request()->getParams() oder ->getPost() ziehen. Zum Loggen einfach den Monologger nehmen: https://developers.shopware.com/develop … g/#monolog Gruß, Daniel
1 „Gefällt mir“
Hallo Daniel, prima, danke für die schnelle Antwort. Gibt es auch eine Möglichkeit die Antwort zu dem Request zu speichern? Grüße Ludwig
Dafür müsstest du dich beim PostDispatch einhooken und via $args->getSubject()->View()->getAssign() die Daten holen
1 „Gefällt mir“
@Shyim: Danke für die Info. Hätt ich mit RTFM auch rausfinden können.:oops: Wird der Controller auch aufgerufen wenn die Authentifizierung per HTTP-Request nicht erfolgreich war? Kann ich so herausfinden ob jemand mit falschen Zugangsdaten zugreifen wollte, bzw. wenn die Authentifizierung per Auth-Digest nicht korrekt übermittelt wird? Grüße Ludwig
Nein, der Controller wird nicht aufgerufen, wenn die Authentifizierung per HTTP-Request nicht erfolgreich war bzw es wird der die invalidAction() des Controllers api/Index aufgerufen
Was mich hier etwas verwirrt ist der Zugang zur API. Ich habe den Beipielcode für das PHP-Interface genutzt und erfolgreich eine Verbindung zum Shop aufgebaut. Im Code sehe ich: public function \_\_construct($apiUrl, $username, $apiKey) { $this-\>apiUrl = rtrim($apiUrl, '/') . '/'; //Initializes the cURL instance $this-\>cURL = curl\_init(); curl\_setopt($this-\>cURL, CURLOPT\_RETURNTRANSFER, true); curl\_setopt($this-\>cURL, CURLOPT\_FOLLOWLOCATION, true); curl\_setopt($this-\>cURL, CURLOPT\_HTTPAUTH, CURLAUTH\_DIGEST); curl\_setopt($this-\>cURL, CURLOPT\_USERPWD, $username . ':' . $apiKey); curl\_setopt($this-\>cURL, CURLOPT\_HTTPHEADER, array( 'Content-Type: application/json; charset=utf-8', )); } Also steht hier was von CURLAUTH_DIGEST. Oder sehe ich das falsch? Wenn ich nun zum Gegenstück in Shopware grabe lande ich bei: \engine\library\Zend\Http\Client.php public static function encodeAuthHeader($user, $password, $type = self::AUTH\_BASIC) { $authHeader = null; switch ($type) { case self::AUTH\_BASIC: // In basic authentication, the user name cannot contain ":" if (strpos($user, ':') !== false) { /\*\* @see Zend\_Http\_Client\_Exception \*/ require\_once 'Zend/Http/Client/Exception.php'; throw new Zend\_Http\_Client\_Exception("The user name cannot contain ':' in 'Basic' HTTP authentication"); } $authHeader = 'Basic ' . base64\_encode($user . ':' . $password); break; //case self::AUTH\_DIGEST: /\*\* \* @todo Implement digest authentication \*/ // break; default: /\*\* @see Zend\_Http\_Client\_Exception \*/ require\_once 'Zend/Http/Client/Exception.php'; throw new Zend\_Http\_Client\_Exception("Not a supported HTTP authentication type: '$type'"); } return $authHeader; } Hier steht es funktioniert nur Basic und kein Digest. Bin ich da an der falschen Stelle? Wo wird die Authentifizierung gemacht? Grüße Ludwig
OK, habs selbst gefunden. Anscheinend wird das nun in \engine\library\Zend\Auth\Adapter\Http\http.php gemacht. Ich hätte gerne den Fehler bei der Authentifizierung per Mail zugeschickt. Vermutlich muss ich das für Tests hart in die Source einfügen. Oder hat da jemand eine Idee? Grüße Ludwig
Hi, dass die Authentifizierung nicht erfolgreich war, siehst du an der Meldung: {"success":false,"message":"Invalid or missing auth"} Von daher brauchst du so tief in das System gar nicht einsteigen. Daniel
Hallo Daniel, danke für die Info. Wenn ich das richtig verstehe besteht doch der Beginn der Kommunikation, per HTTP-Request mit DIGEST gesichert, mit „GET /api/version“ und wird mit 401 vom Server quittiert und quasi abgelehnt. Dann wird die Abfrage erneut gesendet und nach Erfolg mit 200 und den Versionsinfos quittiert oder nach z.B. falschem Passwort mit der Nachricht die Du geschrieben hast und erneut 401. Wir haben bei einem REST-Client den Fall das der zweite Request nicht gesendet wird. Da tappe ich gerade im Dunkeln warum. Leider habe ich keinen Zugriff auf den REST-Client sondern sitze am Webserver und somit nur auf der Shopware-Seite. Hast Du eine Idee was ich da prüfen kann? Ich wollte auf der unteren Kommunikationsebene sehen was da überhaupt im ersten Request ankommt. Da gibt es ja nebem dem Login und dem Kennwort noch andere Parameter. Vielleicht passt da was nicht. Hat jemand eine andere Idee? Grüße Ludwig