'n Vennoot-API kan vereis dat versoeke van 'n bekende bron-IP kom, terwyl die Heroku-program wat dit oproep op wisselende dynos draai. 'n Bestaande Proximo-integrasie bied 'n uitgaande pad deur 'n toegewysde statiese adres.

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

Die toegewysde egress-adres is wat in die vennoot se bron-toelaatlys hoort. PROXIMO_URL identifiseer die proxy-eindpunt en geloofsbriewe wat die program gebruik om daardie pad te betree; dit is nie die program se openbare webwerf-URL nie.

Pas die roete toe op die proses wat die oproep doen

'n Webproses en 'n agtergrondwerker kan afsonderlike API-versoeke doen. Konfigureer elke vereiste verbruiker deur sy ondersteunde proxy-integrasie. Om een proses te roeteer bewys nie dat elke ander proses die poort gebruik nie.

Vir 'n JVM-program, gebruik 'n toepaslike inheemse HTTP- of SOCKS-kliëntkonfigurasie en die verskaffer se ondersteunde verifikasiereëling. Moenie Java-versoenbaarheid aflei uit 'n wrapper-voorbeeld wat vir 'n ander runtime geskryf is nie.

Hou inkomende versoeke op die program se roete

Proximo se Heroku-dokumentasie sê uitdruklik dat dit nie inkomende toegang tot die program bied nie. Kliënte wat die webprogram bereik, gebruik steeds sy gekonfigureerde Heroku-gasheernaam en roetering.

Gebruik die program-URL om inkomende webtoegang te kontroleer. Gebruik bewyse uit die versoeke wat die vennoot ontvang het om die uitgaande bronadres te kontroleer. Om te verwag dat die statiese proxy-IP die program bedien, kombineer daardie twee rigtings tot 'n funksie wat die uitgaande diens nie bied nie.

Verwante artikels