Az Expo-alkalmazás HTTP-vel elbukik Android 9-en: a cleartext a hibás, nem a VPN

Egy Expo-build, amely egyszerű HTTP API-t hív, elbukik Android 9-en és újabbakon. Az alagút ártatlan: a cleartext kapcsoló a build konfigurációjába való.

Kiadtál egy új buildet, átváltottál a VPN-re, és ugyanaz a képernyő már nem töltődött be. Android 9-en és újabbakon a gyakoribb magyarázat unalmasabb: a platform megtagadja az egyszerű HTTP-t azoktól az alkalmazásoktól, amelyek az API 28-as vagy újabb szintet célozzák, a VPN pedig csak annyi kontextust változtatott, hogy ez kiderüljön. A látott hiba a HTTP-klienstől függ, ezért mondja olyan ritkán, hogy cleartext.

Mi is ez a hiba valójában

Android 9-től a platform alapértelmezés szerint blokkolja a cleartextet, amint egy alkalmazás az API 28-as vagy újabb szintet célozza. A platform az egyszerű HTTP-címre küldött kérést még az előtt elutasítja, hogy egyetlen csomag elhagyná az eszközt. Hogy melyik hibát látod, a HTTP-könyvtártól függ: néha általános hálózati hiba, néha időtúllépés, néha egy üzenet, amely nyíltan megnevezi a cleartextet. Amit soha nem tesz, az az, hogy elérje a szerveredet. Az Android dokumentálja az alapértelmezést és a tartományra korlátozott alternatívát a biztonsági konfigurációs útmutatójában.

Ugyanazon az eszközön egy böngésző még betöltheti az oldalt, és pont ez az a nyom, amelyet a legtöbben elszalasztanak. A böngészők nem tartoznak az alkalmazásod hálózati biztonsági szabályzata alá.

Miért a VPN-t hibáztatják

Általában három dolog változik egyszerre. Az alkalmazás a VPN csatlakozása után más hosztnevet oldhat fel, az eszköz lehet újabb builddel rendelkező új készülék, vagy maga a build került olyan cél-API-szintre, amely kiváltja az alapértelmezést. A VPN látszik, a cél-SDK nem, ezért a VPN kapja a jegyet.

Hasonlítsd össze a régi és az új build célszintjeit, mielőtt hozzányúlsz a hálózati konfigurációhoz. Az az alkalmazás, amely 27-et vagy alacsonyabbat céloz, mentesül, és ez magyarázza az összes „a régi telefonomon működik” típusú jelentést.

Hová kerül valójában az Expo kapcsolója

Egy kezelt Expo-projektben a beállítás hozzáadása az app.json fájlhoz nem szerkeszt Android-manifestet, mert a manifestet a prebuild és a fejlesztői buildek állítják elő. Ebben a szakaszban egy konfigurációs plugin írja a beállítást. A támogatott útvonal az expo-build-properties, amelyet az alkalmazás konfigurációjában állítasz be a cleartext opcióval az android alatt.

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

A részlet csak a plugin opcióját állítja be; a manifest később készül el. Futtass egy prebuildet vagy egy friss fejlesztői kliens buildet, majd újratesztelés előtt vizsgáld meg a létrehozott AndroidManifest.xml fájlt android:usesCleartextTraffic szempontjából, mert a csak JS-ből történő újratöltés megtartja a régi manifestet. Igazítsd a plugin verzióját ahhoz az Expo SDK-hoz, amelyen a projekt fut. A plugin opciói kiadásról kiadásra mozognak, és egy másik SDK-ból másolt részlet megbízható forrása a csendes semmittevésnek.

A bare munkafolyamat és a szűkebb lehetőség

Bare React Native esetén a megfelelő az android:usesCleartextTraffic az application elemen, vagy egy hálózati biztonsági konfiguráció, amely csak megnevezett tartományok számára engedi a cleartextet. A tartományra korlátozott forma az előnyben részesítendő, mert engedi a belső API-t, és minden mást HTTPS-en hagy. Dokumentálja a saját kivétellistáját is, és egy bíráló pont ezt fogja kérdezni.

Egyik megközelítés sem változtatja meg a platform alapértelmezését olyasmire, amit nem neveztél meg.

Először az eszköznaplóból bizonyítsd

A konfiguráció szerkesztése előtt szerezd meg a pontos hibát. Egy csatlakoztatott eszközön az adb logcat megmutatja a platform cleartext-elutasítását, és megnevezi az azt kiváltó komponenst. Egy elutasított socket, egy fel nem oldható név vagy egy sikertelen TLS-kézfogás egészen máshová mutat, és a cleartext engedélyezése csak gyengítené az alkalmazást ok nélkül.

Utána tartsd őszintén a produkciót. A cleartext elfogadható egy olyan laborvégpontnál, amely nem tud TLS-t kínálni, és csak a lehető legrövidebb ideig, amit be tudsz ütemezni. Ha az API a magánhálózaton belül tudja lezárni a TLS-t, tedd a tanúsítványt az eszköz megbízhatósági tárolójába, és hagyd kikapcsolva a cleartextet, mert az alagút a kijáratáig titkosítja az utat, azon túl semmit.

Amint a végpont HTTPS-en válaszol, vedd le az engedélyt, építs újra, és teszteld a VPN-en és közönséges Wi-Fi-n ugyanabban a munkamenetben. A névfeloldás eltérhet a két útvonal között, és csak a pár mondja meg, melyik mond igazat.

Kapcsolódó cikkek