Der Proxy trägt die Anfrage. Die Cookie-Engine von PHP cURL entscheidet, welche Ziel-Cookies der Client sendet. Konfigurieren Sie beides an dem Handle, das die Übertragung ausführt. Die HTTP-Proxy-Liste liefert Kandidaten für die Route, wenn diese Aufgabe öffentliche Vermittler nutzen darf:

curl_setopt($handle, CURLOPT_PROXY, 'http://203.0.113.10:8080');
curl_setopt($handle, CURLOPT_COOKIEFILE, '');

Der leere COOKIEFILE-Wert aktiviert die Cookie-Engine, ohne eine anfängliche Cookie-Datei zu laden. Nachfolgende Anfragen an diesem Handle können passende Cookies senden, die vom Ziel empfangen wurden.

Für Persistenz über getrennt erstellte Handles oder Prozesse hinweg verwenden Sie eine bewusste Cookie-Datei-Richtlinie. COOKIEFILE liest Cookies; COOKIEJAR schreibt die von libcurl behaltenen Cookies. COOKIEJAR einen Pfad zu geben liest ihn nicht ebenfalls.

Halten Sie Cookie-Dateien nach der vorgesehenen Sitzung oder dem vorgesehenen Konto der Anwendung getrennt. Eine gemeinsam genutzte Datei, die von parallelen Jobs verwendet wird, kann Zustand unabhängig davon vermischen, welchen Proxy jeder Job wählt. Schützen Sie die Datei, denn ein Sitzungs-Cookie kann Zugriff gewähren, obwohl es nicht als Passwort gekennzeichnet ist.

Wenn der Workflow den aktuellen Cookie-Zustand vor der Bereinigung geschrieben haben muss, prüfen Sie die dokumentierten Cookie-Befehle von libcurl. Verlassen Sie sich nicht auf den curl_close-Aufruf eines veralteten PHP-Beispiels als einzige Erklärung dafür, wann Zustand geschrieben wird.

Eine geänderte Proxy-IP lässt die Cookie-Richtlinie unverändert, sofern die Anwendung sie nicht ändert. Diagnostizieren Sie eine abgelehnte Sitzung als Antwort des Ziels, statt anzunehmen, der Proxy müsse die Anmeldung speichern.

Ähnliche Artikel