Der Aufruf einer API auf einer Magento-basierten Website funktioniert nach der Umstellung auf http / https-Weiterleitung nicht mehr

586
wobits

Ein Kunde bat mich, ein tls-Zertifikat auf seinem Webserver zu installieren und die http-> https-Umleitung vorzunehmen. Nachdem das Zertifikat installiert und die Umschreibungsregeln wie folgt angepasst wurden, schien alles gut zu funktionieren:

 RewriteEngine on  RewriteCond % !^www\. [NC] [OR] RewriteCond % off  RewriteRule (.*) https://www.example.com% [R=301,L]   ############################################ ## rewrite API2 calls to api.php (by now it is REST only)  RewriteRule ^api/rest api.php?type=rest [QSA,L]  ############################################ ## workaround for HTTP authorization ## in CGI environment  RewriteRule .* - [E=HTTP_AUTHORIZATION:%]  ############################################ ## TRACE and TRACK HTTP methods disabled to prevent XSS attacks  RewriteCond % ^TRAC[EK] RewriteRule .* - [L,R=405] <IfModule mod_setenvif.c> <IfModule mod_headers.c>  ############################################ # X-Content-Type-Options: nosniff disable content-type sniffing on some browsers. Header set X-Content-Type-Options: nosniff  ############################################ # This header forces to enables the Cross-site scripting (XSS) filter in browsers (if disabled) BrowserMatch \bMSIE\s8 ie8 Header set X-XSS-Protection: "1; mode=block" env=!ie8  </IfModule> </IfModule>  ############################################ ## always send 404 on missing files in these folders  RewriteCond % !^/(media|skin|js)/  ############################################ ## never rewrite for existing files, directories and links  RewriteCond % !-f RewriteCond % !-d RewriteCond % !-l  ############################################ ## rewrite everything else to index.php  RewriteRule .* index.php [L] 

ABER: Über das Webmin-Panel wurde ein Cron-Job installiert, der vor der Installation der http-> https-Umleitung so aussah:

wget -O /dev/null http://example.com/some_api 

Leider weiß der Kunde nicht viel über die API und ich kann die Dokumentation nicht lesen, da ich die Sprache, in der sie geschrieben wird, nicht beherrscht.

Was ich herausfand, war, dass der obige Aufruf einen Synchronisierungsprozess (Produktdaten) zwischen dem (Magento) -Shop und der im System installierten Mongo-Datenbank auslöst.

Ich habe versucht, den obigen Aufruf mit der folgenden neuen Befehlszeile an die http-> https-Umleitung anzupassen:

wget -O /dev/null --ca-directory /home/user https://www.example.com/some_api 

aber jetzt funktioniert die sync nicht mehr (ich musste das "www" dem ursprünglich verwendeten hostnamen voranstellen, da die anfrage andernfalls für ewig hänge).

Beim manuellen Start von webmin aus erhalte ich folgende Ausgabe:

--2018-09-28 18:00:32-- https://www.example.com/some_api Resolving www.example.com (www.example.com)... 46.xxx.yyy.zzz Connecting to www.example.com (www.example.com)|46.xxx.yyy.zzz|:443... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://example.com/ [following] --2018-09-28 18:00:32-- https://example.com/ Resolving example.com (example.com)... 46.xxx.yyy.zzz Connecting to example.com (example.com)|46.xxx.yyy.zzz|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `/dev/null'  0K .......... .......... .......... .......... .......... 57.4M 50K .......... .......... .......... ........ 4.50M=0.009s  2018-09-28 18:00:33 (9.40 MB/s) - `/dev/null' saved [90479] 

Offensichtlich wird die Anforderung in das DocumentRoot-Verzeichnis (mit der Datei index.php) umgeleitet, aber die Synchronisierung wird nicht ausgeführt.

Von diesem Punkt an kann ich nicht weiter vorgehen, da mein Know-how über APIs und ihr Verhalten unter den genannten Bedingungen rar ist. Vielleicht reicht schon ein richtiges Umschreiben der URL aus.

Meine Frage ist also: Wie kann ich den API-Aufruf wieder funktionieren lassen?

1

0 Antworten auf die Frage