In partner-API kin easkje dat fersiken fan in bekend boarne-IP komme, wylst de Heroku-applikaasje dy't it oanropt op feroarjende dynos draait. In besteande Proximo-ynjefbraak biedt in útgeand paad fia in tawiisd statysk adres.

dyno’s API client → Proximo gateway → partner API
                         assigned source IP

It tawiisde egress-adres is wat yn 'e boarne-tastieningslist fan 'e partner heart. PROXIMO_URL identifisearret it proxy-einpunt en de oanmeldgegevens dy't de applikaasje brûkt om dat paad yn te gean; it is net de iepenbiere website-URL fan 'e applikaasje.

Pas de rûte ta op it proses dat de oprop docht

In webproses en in eftergrûnwurker kinne aparte API-fersiken dwaan. Konfigurearje elke fereaske brûker fia syn stipe proxy-ynjefbraak. It rûtsjen fan ien proses bewiist net dat elk oar proses de gateway brûkt.

Brûk foar in JVM-applikaasje in passende native HTTP- of SOCKS-klantkonfiguraasje en de troch de provider stipe autentikaasjeregeling. Lûk gjin Java-kompatibiliteit ôf fan in wrapper-foarbyld dat foar in oare runtime skreaun is.

Hâld ynkommende fersiken op 'e rûte fan 'e applikaasje

Proximo's Heroku-dokumintaasje seit dúdlik dat it gjin ynkommende tagong ta de applikaasje biedt. Klanten dy't de webapplikaasje berikke, brûke noch hieltyd de konfigurearre Heroku-hostnamme en rûtelegging.

Brûk de app-URL om ynkommende webtagong te kontrolearjen. Brûk bewiis út 'e fersiken dy't de partner ûntfong om it útgeande boarne-adres te kontrolearjen. Ferwachtsje dat it statyske proxy-IP de app tsjinnet, ferbynt dy beide rjochtingen ta in funksje dy't de útgeande tsjinst net biedt.

Relatearre artikelen