تاسو نوی build خپور کړ، VPN ته لاړئ، او هماغه سکرین له لوډ کېدو ودرېد. په Android 9 او وروسته کې ډېره عامه توضیح ډېره بې خونده ده: پلیټفارم د هغو اپونو لپاره چې API 28 یا لوړ هدف ګرځوي ساده HTTP ردوي، او VPN یوازې هغه اندازه زمینه بدله کړه چې دا ښکاره شي. هغه تېروتنه چې وینئ د HTTP کلاینټ پورې اړه لري، ځکه نو ډېر کم cleartext بولي.

دا ناکامي په رښتیا څه ده

له Android 9 راهیسې پلیټفارم په ډیفالټ ډول cleartext بندوي، کله چې اپ د API کچې 28 یا لوړ هدف وګرځوي. ساده HTTP پتې ته غوښتنه د پلیټفارم لخوا ردېږي، مخکې له دې چې یو هم بسته وسیله پرېږدي. کومه تېروتنه چې وینئ د HTTP کتابخانې پورې اړه لري: کله عمومي شبکه یی ناکامي، کله د وخت پای، کله هغه پیغام چې cleartext په روښانه ډول نوموي. هغه څه چې هېڅکله یې نه کوي، ستاسو سرور ته رسېدل دي. Android ډیفالټ او د ډومین له مخې محدود بدیل په خپل د امنیتي ترتیباتو لارښود کې مستند کوي.

په هماغه وسیله کې براوزر لا هم کولی شي پاڼه لوډ کړي، او دا هغه نښه ده چې ډېری خلک یې له لاسه ورکوي. براوزر ستاسو د اپ د شبکې امنیتي تګلارې تابع نه دي.

ولې VPN تورنېږي

معمولاً درې شیان یوځای بدلېږي. اپ ممکن د VPN له نښلېدو وروسته بله کوربه نوم حل کړي، وسیله ممکن نوې او نوی build ولري، یا build پخپله هغې موخې API کچې ته تللی وي چې ډیفالټ فعالوي. VPN ښکاري او موخه SDK نه ښکاري، نو ټکټ VPN ته ورسیږي.

له شبکې ترتیباتو سره د لاس وهلو مخکې د زوړ او نوي build د موخې کچې پرتله کړئ. هغه اپ چې 27 یا کم هدف ګرځوي معاف دی، او دا هر هغه راپور تشریح کوي چې «زما په زوړ تلیفون کې کار کوي».

د Expo بیرغ په رښتیا چېرته کېږي

په مدیریت شوي Expo پروژه کې app.json ته ترتیباتو اضافه کول د Android مانیفست نه سمونځای کوي، ځکه مانیفست prebuild او پراختیایي buildونه جوړوي. په هغه پړاو کې ترتیبات د کانفیګ پلګین لخوا لیکل کېږي. ملاتړ شوې لار expo-build-properties ده، چې د اپ په کانفیګ کې د android لاندې د cleartext انتخاب سره تنظیمیږي.

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

ټوټه یوازې د پلګین انتخاب ټاکي؛ مانیفست وروسته جوړېږي. یو prebuild یا نوی پراختیایي-کلاینټ build وچلوئ، بیا د بیا ازموینې مخکې جوړ شوی AndroidManifest.xml د android:usesCleartextTraffic لپاره وګورئ، ځکه یوازې د JS بیا لوډول زوړ مانیفست ساتي. د پلګین نسخه له هغه Expo SDK سره سمه کړئ چې پروژه پرې ځي. د پلګین انتخابونه د خپرېدو ترمنځ بدلېږي، او له بل SDK څخه کاپي شوې ټوټه د غلې بې اثرۍ باوري سرچینه ده.

Bare بهیر او تنګ انتخاب

د bare React Native لپاره معادل د application عنصر باندې android:usesCleartextTraffic دی، یا د شبکې امنیت کانفیګ چې cleartext یوازې نومول شوو ډومینونو ته اجازه ورکوي. د ډومین له مخې محدوده بڼه هغه ده چې باید غوره شي، ځکه کورني API ته اجازه ورکوي او نور هر څه په HTTPS پرېږدي. دا همدارنګه خپل د استثناوو لیست مستند کوي، او بیاکتونکی به هماغه برخه وپوښتي.

له دوو لارو هیڅ یوه هم د هغه څه لپاره چې تاسو نوم نه دی ورکړی پلیټفارم ډیفالټ نه بدلوي.

لومړی یې د وسیلې له لاګ ثابت کړئ

له ترتیباتو د سمون مخکې دقیقه ناکامي ترلاسه کړئ. په نښلول شوې وسیله adb logcat د پلیټفارم cleartext ردونه ښیي او هغه برخه نوموي چې دا یې پورته کړی. رد شوی ساکټ، هغه نوم چې نه حل کېږي یا ناکام TLS لاس ورکول په بشپړ ډول بل ځای ته اشاره کوي، او cleartext فعالول یوازې اپ بې ځایه کمزوری کوي.

بیا تولیداتو ته وفادار اوسئ. Cleartext د هغه لابراتواري پای ټکي لپاره منل کېدای شي چې TLS نه شي وړاندې کولی، او یوازې د هغه ترټولو لنډ وخت لپاره چې پلان یې کولی شئ. که API کولی شي TLS د خصوصي شبکې دننه پای ومومي، سند د وسیلې د باور زېرمه کې کېږدئ او cleartext بند پرېږدئ، ځکه تونل تر خپل وتلو پورې لاره کوډ کوي او له هغې وروسته هېڅ نه.

کله چې پای ټکی په HTTPS ځواب ووایه، اجازه لرې کړئ، بیا build کړئ او په هماغه ناسته کې پر VPN او عادي Wi-Fi ازموینه وکړئ. د نومونو حل کېدل په دې دوو لارو کې توپیر کولی شي، او یوازې دواړه یوځای تاسو ته وایي چې کوم یې رښتیا وایي.

اړوندې مقالې