એક ભાગીદાર API માંગી શકે છે કે વિનંતીઓ જાણીતા સ્રોત IP પરથી આવે, જ્યારે તેને કૉલ કરતી Heroku એપ્લિકેશન બદલાતા dynos પર ચાલે છે. હાલનું Proximo એકીકરણ સોંપાયેલા સ્થિર સરનામા દ્વારા આઉટબાઉન્ડ માર્ગ આપે છે.

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

સોંપાયેલું ઇગ્રેસ સરનામું એ છે જે ભાગીદારની સ્રોત મંજૂરી સૂચિમાં હોવું જોઈએ. PROXIMO_URL એ પ્રોક્સી એન્ડપોઇન્ટ અને એપ્લિકેશન તે માર્ગમાં પ્રવેશવા માટે વાપરતી ઓળખપત્રો ઓળખે છે; તે એપ્લિકેશનનું જાહેર વેબસાઇટ URL નથી.

માર્ગને કૉલ કરતી પ્રક્રિયા પર લાગુ કરો

વેબ પ્રક્રિયા અને પૃષ્ઠભૂમિ વર્કર અલગ API વિનંતીઓ કરી શકે છે. દરેક જરૂરી ગ્રાહકને તેના સમર્થિત પ્રોક્સી એકીકરણ દ્વારા ગોઠવો. એક પ્રક્રિયાને રૂટ કરવું એ સાબિત કરતું નથી કે અન્ય દરેક પ્રક્રિયા ગેટવે વાપરે છે.

JVM એપ્લિકેશન માટે યોગ્ય નેટિવ HTTP અથવા SOCKS ક્લાયન્ટ ગોઠવણી અને પ્રદાતાની સમર્થિત પ્રમાણીકરણ વ્યવસ્થા વાપરો. અન્ય રનટાઇમ માટે લખાયેલા wrapper ઉદાહરણ પરથી Java સુસંગતતા અનુમાન ન કરો.

આવતી વિનંતીઓ એપ્લિકેશનના માર્ગ પર રાખો

Proximo ના Heroku દસ્તાવેજ સ્પષ્ટ કહે છે કે તે એપ્લિકેશનમાં ઇનબાઉન્ડ ઍક્સેસ આપતું નથી. વેબ એપ્લિકેશન સુધી પહોંચતા ક્લાયન્ટ હજી પણ તેના ગોઠવેલા Heroku હોસ્ટનામ અને રૂટિંગનો ઉપયોગ કરે છે.

આવતી વેબ ઍક્સેસ ચકાસવા માટે એપ URL વાપરો. ભાગીદારને મળેલી વિનંતીઓના પુરાવા વાપરીને આઉટબાઉન્ડ સ્રોત સરનામું ચકાસો. સ્થિર પ્રોક્સી IP એપ્લિકેશનને સેવા આપશે એવી અપેક્ષા એ બંને દિશાઓને એવા લક્ષણમાં જોડે છે જે આઉટબાઉન્ડ સેવા આપતી નથી.

સંબંધિત લેખો