Ein Besucher klickt auf eine Schaltfläche. Ihr PHP-Server ruft eine externe API auf. Die API sieht die ausgehende Verbindung des Servers oder den Ausgang des für diese Verbindung konfigurierten Proxys. Der Browser des Besuchers unterhält eine separate Verbindung zu Ihrer Website.

Das Kopieren der Besucheradresse in einen Header kann die PHP-Verbindung nicht in das Netzwerk des Besuchers verlagern. Header sind Daten, die über eine bereits aufgebaute Verbindung gesendet werden. Ein Ziel kann in seiner eigenen Anwendungslogik einen vertrauenswürdigen Weiterleitungs-Header verwenden, aber das macht den Header-Wert nicht zur Quelladresse der Verbindung.

Ein Proxy muss die Verbindung annehmen

Um PHP cURL über eine andere Maschine zu senden, muss diese Maschine einen erreichbaren Proxydienst mit der Berechtigung anbieten, die Anfrage zu transportieren. Der PHP-Prozess muss sich mit ihm verbinden können. Die gewöhnliche Browsersitzung eines Besuchers gibt Ihrem Server keinen solchen universellen Proxy-Endpunkt.

Die libcurl-Proxyoption wählt den Dienst aus, mit dem cURL sich verbindet. Sie kann keinen beliebigen Browser bitten, die Anfrage in seinem Namen zu erzeugen.

Eine Browseranfrage ist ein anderes Design

Bei manchen APIs kann der Browser das Ziel direkt aufrufen. Das legt die Anfrage auf den Netzwerkpfad des Benutzers, abhängig von dessen eigener Proxykonfiguration. Es erfordert außerdem eine API, die für Browserclients entwickelt wurde. Ursprungsübergreifender Zugriff folgt CORS, und Anmeldeinformationen, die an Browsercode gesendet werden, werden für diesen Client verfügbar.

Entscheiden Sie, wohin die Anfrage gehört, bevor Sie eine Proxyoption wählen. Bewahren Sie Server-Anmeldeinformationen auf dem Server auf; nutzen Sie eine dokumentierte Browserintegration, wenn der Dienst eine unterstützt. Keines der beiden Designs bietet eine zuverlässige Abkürzung, damit eine Serveranfrage die Netzwerkidentität eines Besuchers übernimmt.

Ähnliche Artikel