PHP cURL peut-il utiliser l'IP du visiteur ?
Expliquez quelle machine ouvre une connexion cURL côté serveur et ce qu'un proxy devrait changer pour modifier cette route.
Un visiteur clique sur un bouton. Votre serveur PHP appelle une API externe. L'API voit la connexion sortante du serveur, ou la sortie du proxy configuré pour cette connexion. Le navigateur du visiteur gère une connexion distincte vers votre site.
Copier l'adresse du visiteur dans un en-tête ne peut pas déplacer la connexion PHP sur le réseau du visiteur. Les en-têtes sont des données envoyées sur une connexion déjà établie. Une destination peut utiliser un en-tête de transfert de confiance dans sa propre logique applicative, mais cela ne transforme pas la valeur de l'en-tête en adresse source de la connexion.
Un proxy doit accepter la connexion
Pour envoyer PHP cURL via une autre machine, cette machine doit offrir un service proxy joignable avec l'autorisation de transporter la requête. Le processus PHP doit pouvoir s'y connecter. La session de navigateur ordinaire d'un visiteur ne fournit à votre serveur aucun point de terminaison proxy à usage général.
L'option proxy de libcurl sélectionne le service auquel cURL se connecte. Elle ne peut pas demander à un navigateur quelconque d'émettre la requête à sa place.
Une requête depuis le navigateur est une autre conception
Pour certaines API, le navigateur peut appeler directement la destination. Cela place la requête sur le chemin réseau de l'utilisateur, selon sa propre configuration proxy. Cela exige aussi une API conçue pour les clients navigateur. L'accès entre origines suit CORS, et les identifiants envoyés au code du navigateur deviennent disponibles pour ce client.
Décidez à qui appartient la requête avant de choisir une option proxy. Gardez les identifiants du serveur sur le serveur ; utilisez une intégration navigateur documentée lorsque le service en propose une. Aucune des deux conceptions n'offre de raccourci fiable pour qu'une requête serveur hérite de l'identité réseau d'un visiteur.