Ĉu PHP cURL povas uzi la IP de la vizitanto?
Klarigu, kiu maŝino malfermas servflankan cURL-konekton kaj kion prokuro devus ŝanĝi tiun vojon.
Vizitanto alklakas butonon. Via PHP-servilo vokas eksteran API-on. La API vidas la elirantan konekton de la servilo, aŭ la eliron de la prokuro agordita por tiu konekto. La retumilo de la vizitanto traktas apartan konekton al via retejo.
Kopii la adreson de la vizitanto en kaplinion ne povas movi la PHP-konekton en la reton de la vizitanto. Kaplinioj estas datumoj senditaj super jam establita konekto. Celopaĝo povas uzi fidatan plusendan kaplinion en sia propra aplikaĵa logiko, sed tio ne igas la kaplinian valoron la fontadreso de la konekto.
Prokuro devas akcepti la konekton
Por sendi PHP cURL tra alia maŝino, tiu maŝino devas oferti atingeblan prokuran servon kun permeso porti la peton. La PHP-procezo devu povi konektiĝi al ĝi. Ordinara retuma seanco de vizitanto donas al via servilo nenian tian ĝeneraluzan prokuran finpunkton.
La prokura opcio de libcurl elektas la servon al kiu cURL konektiĝas. Ĝi ne povas peti arbitran retumilon originigi la peton anstataŭ ĝi.
Retuma peto estas alia dezajno
Por iuj API-oj, la retumilo povas voki la celon rekte. Tio metas la peton sur la retan vojon de la uzanto, laŭ ilia propra prokura agordo. Ĝi ankaŭ postulas API-on desegnitan por retumaj klientoj. Transdevena aliro sekvas CORS, kaj akreditaĵoj senditaj al retuma kodo fariĝas haveblaj al tiu kliento.
Decidu, kien la peto apartenas antaŭ ol elekti prokuran opcion. Konservu servilajn akreditaĵojn sur la servilo; uzu dokumentitan retuman integriĝon kiam la servo subtenas ĝin. Neniu dezajno ofertas fidindan fulmon por igi servilan peton heredi la retan identecon de vizitanto.