Expo एप Android 9 मा HTTP मा असफल हुन्छ: कारण cleartext हो, VPN होइन

तपाईंले नयाँ बिल्ड जारी गर्नुभयो, VPN मा जानुभयो, र त्यही स्क्रिन लोड हुन छोड्यो। Android 9 र त्यसपछि बढी सामान्य व्याख्या बढी नीरस छ: प्लेटफर्मले API 28 वा त्यसभन्दा माथि लक्ष्य गर्ने एपहरूका लागि साधारण HTTP अस्वीकार गर्छ, र VPN ले त्यो देखाउन पर्याप्त सन्दर्भ मात्र बदल्यो। तपाईंले देख्ने त्रुटि HTTP क्लाइन्टमा निर्भर हुन्छ, त्यसैले यो cleartext भनेर यति कमै भन्छ।

यो असफलता वास्तवमा के हो

Android 9 देखि प्लेटफर्मले डिफल्ट रूपमा cleartext ब्लक गर्छ, एपले API स्तर 28 वा त्यसभन्दा माथि लक्ष्य गरेपछि। साधारण HTTP ठेगानामा गरिएको अनुरोध एउटा पनि प्याकेट उपकरणबाट निस्कनु अघि नै प्लेटफर्मले अस्वीकार गर्छ। कुन त्रुटि देख्नुहुन्छ भन्ने HTTP लाइब्रेरीमा निर्भर हुन्छ: कहिले सामान्य नेटवर्क असफलता, कहिले समय समाप्त, कहिले cleartext सिधै नाम दिने सन्देश। यसले कहिल्यै नगर्ने कुरा तपाईंको सर्भरसम्म पुग्नु हो। Android ले डिफल्ट र डोमेन-सीमित विकल्प आफ्नो सुरक्षा कन्फिगरेसन गाइडमा दस्तावेज गर्छ।

एउटै उपकरणको ब्राउजरले अझै पृष्ठ लोड गर्न सक्छ, र यही त्यो संकेत हो जुन धेरैले छुटाउँछन्। ब्राउजरहरू तपाईंको एपको नेटवर्क सुरक्षा नीतिको अधीनमा छैनन्।

VPN लाई दोष किन दिइन्छ

सामान्यतया तीन चीजहरू एकैचोटि बदलिन्छन्। VPN जोडिएपछि एपले अर्को होस्टनाम रिजोल्भ गर्न सक्छ, उपकरण नयाँ र नयाँ बिल्डको हुन सक्छ, वा बिल्ड आफैं डिफल्ट सक्रिय गर्ने लक्ष्य API स्तरमा गएको हुन सक्छ। VPN देखिन्छ र लक्ष्य SDK देखिँदैन, त्यसैले टिकट VPN ले पाउँछ।

नेटवर्क कन्फिगमा हात हाल्नु अघि पुरानो र नयाँ बिल्डको लक्ष्य स्तर तुलना गर्नुहोस्। 27 वा त्यसभन्दा कम लक्ष्य गर्ने एप छुट पाउँछ, र यसैले «मेरो पुरानो फोनमा चल्छ» भन्ने हरेक रिपोर्ट व्याख्या गर्छ।

Expo फ्ल्याग वास्तवमा कहाँ पर्छ

व्यवस्थित Expo परियोजनामा app.json मा सेटिङ थप्दा Android म्यानिफेस्ट सम्पादन हुँदैन, किनकि म्यानिफेस्ट prebuild र विकास बिल्डहरूले उत्पादन गर्छन्। त्यो चरणमा सेटिङ लेख्ने कन्फिग प्लगइन हो। समर्थित बाटो expo-build-properties हो, जो एप कन्फिगमा android अन्तर्गत cleartext विकल्पसहित कन्फिगर गरिन्छ।

{
  "plugins": [
    ["expo-build-properties", {
      "android": { "usesCleartextTraffic": true }
    }]
  ]
}

स्निपेटले प्लगइन विकल्प मात्र सेट गर्छ; म्यानिफेस्ट पछि उत्पादन हुन्छ। prebuild वा नयाँ विकास-क्लाइन्ट बिल्ड चलाउनुहोस्, त्यसपछि फेरि परीक्षण गर्नु अघि उत्पादित AndroidManifest.xml मा android:usesCleartextTraffic छ कि जाँच्नुहोस्, किनकि JS मात्र रिलोड गर्दा पुरानो म्यानिफेस्ट रहन्छ। प्लगइन संस्करण परियोजना चल्ने Expo SDK सँग मिलाउनुहोस्। प्लगइन विकल्प रिलिजहरूबीच सर्छन्, र अर्को SDK बाट कपी गरिएको स्निपेट शान्त निष्क्रियताको भरपर्दो स्रोत हो।

Bare कार्यप्रवाह र अझ साँघुरो विकल्प

bare React Native का लागि समान कुरा application एलिमेन्टमा android:usesCleartextTraffic, वा नाम दिइएका डोमेनका लागि मात्र cleartext अनुमति दिने नेटवर्क सुरक्षा कन्फिग हो। डोमेन-सीमित रूप नै रोज्नुपर्ने हो, किनकि यसले आन्तरिक API लाई अनुमति दिन्छ र बाँकी सबै HTTPS मा राख्छ। यसले आफ्नै अपवाद सूची पनि दस्तावेज गर्छ, र समीक्षकले ठ्याक्कै त्यही भागबारे सोध्नेछ।

दुवैमध्ये कुनै पनि दृष्टिकोणले तपाईंले नाम नदिएको कुनै पनि कुराका लागि प्लेटफर्मको डिफल्ट बदल्दैन।

पहिले उपकरण लगबाट प्रमाणित गर्नुहोस्

कन्फिग सम्पादन गर्नु अघि सही असफलता लिनुहोस्। जोडिएको उपकरणमा adb logcat ले प्लेटफर्मको cleartext अस्वीकार देखाउँछ र त्यो उठाउने कम्पोनेन्टको नाम बताउँछ। अस्वीकृत सकेट, रिजोल्भ नहुने नाम वा असफल TLS ह्यान्डसेक पूर्ण रूपमा अन्तै सङ्केत गर्छन्, र cleartext सक्षम गर्दा एपलाई व्यर्थै कमजोर बनाउँछ।

त्यसपछि उत्पादनलाई इमानदार राख्नुहोस्। TLS दिन नसक्ने प्रयोगशाला इन्डपोइन्टका लागि cleartext स्वीकार्य छ, र तपाईंले योजना गर्न सक्ने सबैभन्दा छोटो समयका लागि मात्र। यदि API ले निजी नेटवर्क भित्र TLS अन्त्य गर्न सक्छ भने, प्रमाणपत्र उपकरणको ट्रस्ट स्टोरमा राख्नुहोस् र cleartext निष्क्रिय राख्नुहोस्, किनकि टनेलले आफ्नो निकाससम्मको बाटो इन्क्रिप्ट गर्छ, त्यसपछि केही होइन।

इन्डपोइन्टले HTTPS मा जवाफ दिन थालेपछि अनुमति हटाउनुहोस्, फेरि बिल्ड गर्नुहोस् र त्यही सत्रमा VPN मा र साधारण Wi-Fi मा परीक्षण गर्नुहोस्। नाम रिजोल्युसन यी दुई बाटोमा फरक हुन सक्छ, र कुन सत्य बोलिरहेको छ भन्ने कुरा त्यो जोडीले मात्र बताउँछ।