Статычныя IP выходу для выклікаў Heroku API з Proximo
Выкарыстоўвайце існуючую інтэграцыю Proximo для белага спісу зыходных IP, пакідаючы ўваход прыкладання на вэб-маршруце Heroku.
Партнёрскі API можа патрабаваць, каб запыты прыходзілі з вядомага зыходнага IP, пакуль прыкладанне Heroku, якое яго выклікае, працуе на зменных dynos. Існуючая інтэграцыя Proximo дае зыходны шлях праз прызначаны статычны адрас.
dyno’s API client → Proximo gateway → partner API
assigned source IPПрызначаны адрас выхаду — гэта тое, што павінна быць у белым спісе крыніц партнёра. PROXIMO_URL вызначае канчатковы пункт проксі і ўліковыя даныя, якія прыкладанне выкарыстоўвае для ўваходу ў гэты шлях; гэта не публічны URL вэб-сайта прыкладання.
Прымяніце маршрут да працэсу, які робіць выклік
Вэб-працэс і фонавы працоўны могуць рабіць асобныя запыты API. Наладзьце кожнага патрэбнага спажыўца праз падтрыманую ім інтэграцыю проксі. Маршрутызацыя аднаго працэсу не даказвае, што ўсе іншыя працэсы выкарыстоўваюць шлюз.
Для прыкладання на JVM выкарыстоўвайце адпаведную ўласную канфігурацыю кліента HTTP або SOCKS і падтрыманую пастаўшчыком схему аўтэнтыфікацыі. Не рабіце выснову пра сумяшчальнасць з Java па прыкладзе абгорткі, напісаным для іншага асяроддзя выканання.
Трымайце ўваходныя запыты на маршруце прыкладання
Дакументацыя Proximo для Heroku відавочна паведамляе, што яна не забяспечвае ўваходны доступ да прыкладання. Кліенты, якія дасягаюць вэб-прыкладання, па-ранейшаму выкарыстоўваюць наладжанае імя хоста Heroku і схему маршрутызацыі.
Выкарыстоўвайце URL прыкладання, каб правяраць уваходны вэб-доступ. Выкарыстоўвайце доказы з запытаў, атрыманых партнёрам, каб праверыць зыходны адрас крыніцы. Чаканне, што статычны IP проксі будзе абслугоўваць прыкладанне, злівае гэтыя два кірункі ў функцыю, якую служба выхаду не прадастаўляе.