Ein besøkande klikkar på ein knapp. PHP-tenaren din kallar eit eksternt API. API-et ser den utgåande tilkoplinga til tenaren, eller utgangen til proxyen som er sett opp for den tilkoplinga. Nettlesaren til den besøkande handterer ei eiga tilkopling til nettstaden din.

Å kopiere adressa til den besøkande inn i ein header kan ikkje flytte PHP-tilkoplinga over til nettet til den besøkande. Headers er data som vert sende over ei tilkopling som alt er oppretta. Ein mottakar kan bruke ein klarert vidaresendingsheader i sin eigen applikasjonslogikk, men det gjer ikkje headerverdien til kjeldeadressa til tilkoplinga.

Proxyen må godta tilkoplinga

For å sende PHP cURL gjennom ein annan maskin må den maskinen tilby ein tilgjengeleg proxy-teneste med løyve til å føre førespurnaden. PHP-prosessen må kunne kople til han. Ei vanleg nettlesarøkt hos den besøkande gjev ikkje tenaren din eit slikt allment proxy-endepunkt.

libcurl-proxyvalet vel tenesta cURL koplar til. Det kan ikkje be ein vilkårleg nettlesar om å opprette førespurnaden på eigne vegner.

Ein nettlesarførespurnad er ein annan konstruksjon

For nokre API kan nettlesaren kalle destinasjonen direkte. Det plasserer førespurnaden på nettverksstien til brukaren, avhengig av deira eigen proxykonfigurasjon. Det krev òg eit API laga for nettlesarklientar. Tverrorigin-tilgang følgjer CORS, og legitimasjon som vert send til nettlesarkode vert tilgjengeleg for den klienten.

Avgjer kvar førespurnaden høyrer heime før du vel proxyval. Hald serverlegitimasjon på tenaren; bruk ein dokumentert nettlesarintegrasjon når tenesta støttar det. Ingen av konstruksjonane gjev ein påliteleg snarveg for å la ein tenarførespurnad arve nettverksidentiteten til den besøkande.

Relaterte artiklar