Expo অ্যাপে Android 9-এ HTTP ব্যর্থ: কারণ cleartext, VPN নয়

আপনি নতুন একটি বিল্ড প্রকাশ করেছেন, VPN-এ গেছেন, আর একই স্ক্রিন আর লোড হচ্ছে না। Android 9 ও পরের সংস্করণে বেশি দেখা ব্যাখ্যাটি আরও নীরস: API 28 বা তার বেশি লক্ষ্য করা অ্যাপের জন্য প্ল্যাটফর্ম সাধারণ HTTP প্রত্যাখ্যান করে, আর VPN শুধু এতটুকু প্রসঙ্গ বদলেছে যে এটি প্রকাশ পেয়েছে। আপনি যে ত্রুটি দেখেন তা HTTP ক্লায়েন্টের উপর নির্ভর করে, তাই এটি এত কম ক্ষেত্রে cleartext শব্দটি বলে।

এই ব্যর্থতা আসলে কী

Android 9 থেকে শুরু করে, কোনো অ্যাপ API লেভেল 28 বা তার বেশি লক্ষ্য করলে প্ল্যাটফর্ম ডিফল্টভাবে cleartext ব্লক করে। সাধারণ HTTP ঠিকানায় অনুরোধটি ডিভাইস থেকে একটি প্যাকেটও বের হওয়ার আগেই প্ল্যাটফর্ম প্রত্যাখ্যান করে। আপনি কোন ত্রুটি দেখবেন তা HTTP লাইব্রেরির উপর নির্ভর করে: কখনও সাধারণ নেটওয়ার্ক ব্যর্থতা, কখনও সময় শেষ, কখনও এমন বার্তা যা সরাসরি cleartext বলে। যা এটি কখনও করে না, তা হলো আপনার সার্ভারে পৌঁছানো। Android ডিফল্ট ও ডোমেইন-সীমিত বিকল্পটি তার সিকিউরিটি কনফিগারেশন গাইডে নথিভুক্ত করেছে।

একই ডিভাইসের একটি ব্রাউজার কিন্তু পৃষ্ঠাটি লোড করতে পারে, আর এটিই সেই সূত্র যা বেশিরভাগ মানুষ মিস করেন। ব্রাউজার আপনার অ্যাপের নেটওয়ার্ক সিকিউরিটি নীতি মানতে বাধ্য নয়।

কেন VPN-কে দোষ দেওয়া হয়

সাধারণত তিনটি জিনিস একসাথে বদলায়। VPN সংযুক্ত হওয়ার পর অ্যাপ ভিন্ন হোস্টনেম রিজলভ করতে পারে, ডিভাইসটি নতুন ও নতুন বিল্ডের হতে পারে, বা বিল্ডটিই এমন লক্ষ্য API লেভেলে সরে গিয়ে থাকতে পারে যা ডিফল্টটি চালু করে। VPN দৃশ্যমান, লক্ষ্য SDK নয়, তাই টিকিট VPN-ই পায়।

নেটওয়ার্ক কনফিগে হাত দেওয়ার আগে পুরোনো ও নতুন বিল্ডের লক্ষ্য লেভেল মিলিয়ে দেখুন। 27 বা তার কম লক্ষ্য করা অ্যাপ ছাড় পায়, আর এতেই «আমার পুরোনো ফোনে কাজ করে» ধরনের প্রতিটি রিপোর্ট ব্যাখ্যা হয়।

Expo ফ্ল্যাগটি আসলে কোথায় পড়ে

ম্যানেজড Expo প্রকল্পে app.json-এ একটি সেটিং যোগ করলে Android ম্যানিফেস্ট সম্পাদিত হয় না, কারণ prebuild ও development বিল্ডই ম্যানিফেস্ট তৈরি করে। সেই পর্যায়ে সেটিংটি লেখে একটি কনফিগ প্লাগইন। সমর্থিত পথটি expo-build-properties, যা অ্যাপ কনফিগে android-এর নিচে cleartext অপশন দিয়ে কনফিগার করা হয়।

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

স্নিপেটটি কেবল প্লাগইন অপশন সেট করে; ম্যানিফেস্ট তৈরি হয় পরে। একটি prebuild বা নতুন development-client বিল্ড চালান, তারপর আবার পরীক্ষা করার আগে তৈরি হওয়া 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-তে পরীক্ষা করুন। নাম রিজলিউশন এই দুই পথে আলাদা হতে পারে, আর কেবল দুটো মিলিয়েই বোঝা যায় কোনটি সত্য বলছে।