Un’API partner può richiedere che le richieste provengano da un IP di origine noto mentre l’app Heroku che la chiama viene eseguita su dynos variabili. Un’integrazione Proximo esistente fornisce un percorso in uscita tramite un indirizzo statico assegnato.

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

L’indirizzo egress assegnato è quello che deve figurare nella lista delle origini consentite del partner. PROXIMO_URL identifica l’endpoint del proxy e le credenziali che l’applicazione usa per entrare in quel percorso; non è l’URL pubblico del sito dell’applicazione.

Applicate la rotta al processo che effettua la chiamata

Un processo web e un worker in background possono effettuare richieste API separate. Configurate ogni consumatore necessario tramite la sua integrazione proxy supportata. Instradare un processo non dimostra che ogni altro processo usi il gateway.

Per un’applicazione JVM, usate una configurazione nativa appropriata del client HTTP o SOCKS e il meccanismo di autenticazione supportato dal fornitore. Non deducete la compatibilità con Java da un esempio di wrapper scritto per un altro runtime.

Mantenete le richieste in ingresso sulla rotta dell’applicazione

La documentazione Proximo per Heroku afferma esplicitamente che non fornisce accesso in ingresso all’applicazione. I client che raggiungono l’app web usano ancora il nome host Heroku configurato e il suo instradamento.

Usate l’URL dell’app per verificare l’accesso web in ingresso. Usate le prove dalle richieste ricevute dal partner per verificare l’indirizzo di origine in uscita. Aspettarsi che l’IP statico del proxy serva l’app unisce quelle due direzioni in una funzione che il servizio in uscita non offre.

Articoli correlati