कॉल करणारे Heroku ॲप बदलत्या dynos वर चालत असतानाही विनंत्या ज्ञात स्रोत IP वरून याव्यात अशी मागणी भागीदार API करू शकते. विद्यमान 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 ॲपला सेवा देईल अशी अपेक्षा या दोन दिशा एकत्र करून अशा वैशिष्ट्यात रूपांतरित करते जे आउटबाउंड सेवा देत नाही.

संबंधित लेख