VPN द्वारे iPhone ॲपमधून अंतर्गत API कसे कॉल करावे

API त्याच फोनवरील Safari मध्ये उत्तर देते, तर ॲपची विनंती वेळेची मर्यादा ओलांडते. हे अंतर सहसा टनेल नसते: अंतर्गत सेवेला कॉल करणारे ॲप सामान्य HTTPS विनंती करते, आणि डिव्हाइसवरील विद्यमान VPN त्या विनंतीला मार्ग आहे की नाही हेच ठरवते. ॲपमध्ये दुसरे टनेल लिहिणे हा उत्पादन निर्णय आहे, वेळेच्या मर्यादेसाठी दुरुस्ती नाही. पुढील मजकूर अयशस्वीतेचे ती कुठे घडते यानुसार वर्गीकरण करतो, ॲपकडे आधीच असलेला त्रुटी-पृष्ठभाग वापरून.

टनेलपासून नाही, त्रुटीपासून सुरुवात करा

URLSession वाहतूक अयशस्वीता NSError मूल्ये म्हणून NSURLErrorDomain मध्ये नोंदवते, आणि कोड हा सर्वात स्वस्त उपलब्ध पुरावा आहे. कोणतेही कॉन्फिगरेशन बदलण्यापूर्वी तो कोड अयशस्वी होणाऱ्या होस्टनावासह आणि कार्याच्या गेलेल्या वेळेसह लॉग करा. वेळेची मर्यादा, नाव अयशस्वीता आणि विश्वास अयशस्वीता स्क्रीनवर सारख्याच दिसतात आणि तीन वेगवेगळ्या दुरुस्त्या मागतात. आधी वर्गीकरण करा, नंतर त्या वर्गाचा विभाग वाचा.

कार्य मेट्रिक्स पुढील प्रश्नाचे उत्तर देतात, कनेक्शन कधीही प्रस्थापित झाले का, हे मार्ग नसलेल्या विनंतीला सर्व्हरने खूप उशिरा उत्तर दिलेल्या विनंतीपासून वेगळे करते. यापैकी काहीही टनेल बदलण्याची आवश्यकता नाही; विनंतीचे स्वतःचे निदान तुम्ही वाचू शकता अशा ठिकाणी छापण्याची आवश्यकता आहे.

नाव-निराकरण इतर कशापेक्षाही आधी अयशस्वी होते

उदाहरणार्थ api.corp.example सारखे छोटे कार्यालयीन नाव सहसा फोनमध्ये नसलेल्या शोध-डोमेनवर अवलंबून असते, त्यामुळे ॲप केवळ इमारतीच्या आत असलेले नाव निराकरण करते. NSURLErrorCannotFindHost ही त्याची स्वाक्षरी आहे. संपूर्ण होस्टनाव VPN स्थापित करतो त्याच कोणत्याही रिझॉल्व्हरद्वारे निराकरण केले पाहिजे, आणि शोध-डोमेनची हमी नसताना ॲपने पूर्णपणे पात्र रूप मागितले पाहिजे. नावाच्या जागी पत्ता टाकणे आणि प्रमाणपत्र तपासण्या बंद करणे अयशस्वीता दुरुस्त करण्याऐवजी हलवते.

खाजगी DNS नोंद आणि नेमक्या त्या नावासाठी जारी केलेले प्रमाणपत्र ही समर्थित जोडी आहे. बाकी सर्व वापरकर्त्यांपर्यंत पोहोचणारा एक मार्ग आहे.

वेळेची मर्यादा नावाचा प्रश्न नाही, मार्गाचा प्रश्न आहे

NSURLErrorTimedOut म्हणजे नाव निराकरण झाले आणि काहीही उत्तर दिले नाही, जे मार्ग, पॅकेट धोरण किंवा सेवेकडे निर्देश करते. टनेल प्रत्येक ॲप्लिकेशनसाठी नेमले जाते तेव्हा त्याच सर्व्हरपर्यंत पोहोचणारे दुसरे ॲप तुमच्या बिल्डबद्दल काहीही सांगत नाही, कारण ते मॅपिंग सामायिक केले जात नाही. तुम्ही चालवत असलेले बंडल त्या नेमणुकीत आहे का ते तपासा, नंतर सेवेचा मार्ग त्यासाठी परवानगी आहे का ते तपासा. नेमणुकीबाहेर स्थापित विकास बिल्ड पूर्णपणे टनेलबाहेर असू शकते आणि तुटलेल्या API सारखी दिसू शकते.

ब्राउझर तुलना दर्शवते की डिव्हाइसवरील कोणत्यातरी ॲपला मार्ग आहे. ते तुमच्या बिल्डला आहे हे कधीही सिद्ध करत नाही, म्हणून दोन्ही चाचण्या वेगळ्या कराव्या लागतात.

विश्वास अयशस्वीता प्रमाणपत्रावरील नावाबद्दल आहेत

NSURLErrorServerCertificateUntrusted त्याखालील TLS त्रुटीसह एकत्रितपणे म्हणजे साखळी किंवा ओळख तपासणी अयशस्वी झाली. अंतर्गत CA डिव्हाइसवर विश्वसनीय असणे आवश्यक आहे, आणि दुसऱ्या होस्टनावासाठी जारी केलेले प्रमाणपत्र कितीही नेटवर्क पुनर्रचना झाली तरी चुकीचेच राहते. Apple चे App Transport Security मार्गदर्शन या URL लोड करणाऱ्या कनेक्शन्सना अजूनही लागू आहे, आणि साध्या HTTP सेवेभोवतीचे टनेल ती सेवा टोकापासून टोकापर्यंत सुरक्षित करत नाही.

ओळख किंवा विश्वास-अँकर दुरुस्त करा आणि अपवाद यादी रिकामी ठेवा. अनियंत्रित लोडसाठीचा सर्वसमावेशक अपवाद विकासादरम्यान अयशस्वीता लपवतो आणि नंतर प्रत्येक वापरकर्त्यासाठी ती जागेवरच ठेवतो.

HTTP नाकारणे ॲपचे आहे, नेटवर्कचे नाही

पूर्ण झालेल्या हँडशेकनंतर 401 किंवा 403 म्हणजे विनंती पोहोचली आणि सेवेने ती नाकारली, त्यामुळे उरलेला प्रश्न खाते, टोकन प्रेक्षक, व्याप्ती किंवा की आहे. स्थिती कोड आणि होस्टनाव लॉग करा, कधीही बेअरर टोकन किंवा प्रतिसाद मुख्य भाग नाही. त्या क्षणी टनेल आपले काम करत आहे आणि पुढील नेटवर्क बदल केवळ खऱ्या सुधारणेला उशीर लावतात.

तक्ता म्हणजे टर्मिनलजवळ ठेवायचे वर्गीकरण: ॲप खरोखर नोंदवू शकते अशा प्रत्येक अयशस्वीतेसाठी एक ओळ. कोड वाचण्यापूर्वी छापा, कारण तुम्ही निवडलेली ओळ कोणता विभाग तुम्ही हाताळाल हे ठरवते.

प्रत्येक ओळ त्याखालील ओळीपेक्षा स्वस्तात तपासता येते, आणि प्रत्येकजण त्याच विनंतीचा वेगळा थर वगळतो. ओळ जुळेपर्यंत तक्त्यात खाली जा, नंतर नेटवर्क बदलणे थांबवा.