Expo rakendus ei saa Android 9-s HTTP-ga hakkama: süüdi on cleartext, mitte VPN

Avaldasite uue buildi, läksite üle VPN-ile ja sama vaade lakkas laadimast. Android 9 ja uuemates on tavalisem seletus tüütum: platvorm keeldub tavalisest HTTP-st rakenduste puhul, mis sihivad API 28 või uuemat, ja VPN muutis ainult nii palju konteksti, et see välja tuli. Viga, mille saate, sõltub HTTP kliendist, seepärast ütleb see nii harva cleartext.

Mis see tõrge tegelikult on

Alates Android 9-st blokeerib platvorm cleartext vaikimisi niipea, kui rakendus sihib API taset 28 või uuemat. Platvorm lükkab tavalisele HTTP-aadressile tehtud päringu tagasi enne, kui ükski pakett seadmest väljub. Millist viga näete, sõltub HTTP teegist: mõnikord üldine võrgu tõrge, mõnikord ajalõpp, mõnikord sõnum, mis nimetab cleartexti otse. Mida see kunagi ei tee, on teie serverini jõudmine. Android dokumenteerib vaikeväärtuse ja domeeniga piiratud alternatiivi oma turvakonfiguratsiooni juhendis.

Sama seadme brauser suudab lehe endiselt laadida, ja see on vihje, mille enamik inimesi kahe silma vahele jätab. Brauserid ei allu teie rakenduse võrgu turvapoliitikale.

Miks süüdistatakse VPN-i

Tavaliselt muutub kolm asja korraga. Rakendus võib pärast VPN-i ühendamist lahendada teise hostinime, seade võib olla uus ja uuema buildiga, või võib build ise olla liikunud siht-API tasemele, mis vaikeväärtuse käivitab. VPN on nähtav ja siht-SDK ei ole, nii et pileti saab VPN.

Võrrelge vana ja uue buildi sihttasemeid enne, kui võrgu konfiguratsiooni puudutate. Rakendus, mis sihib 27 või madalamat, on vabastatud, ja see seletab iga raportit stiilis «minu vanemas telefonis töötab».

Kuhu Expo lipp tegelikult maandub

Hallatavas Expo projektis ei muuda app.json-i lisatud säte Androidi manifesti, sest manifesti toodavad prebuild ja arendusbuildid. Sätte kirjutab selles etapis konfiguratsiooniplugin. Toetatud tee on expo-build-properties, mis konfigureeritakse rakenduse konfiguratsioonis cleartext valikuga android all.

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

Lõik seab ainult plugina valiku; manifest luuakse hiljem. Käivitage prebuild või värske arenduskliendi build, seejärel enne uuesti testimist kontrollige loodud AndroidManifest.xml failist android:usesCleartextTraffic olemasolu, sest ainult JS-iga uuesti laadimine jätab vana manifesti alles. Viige plugina versioon vastavusse Expo SDK-ga, millel projekt jookseb. Plugina valikud liiguvad väljaannete vahel ja teisest SDK-st kopeeritud lõik on usaldusväärne allikas vaiksetele tegevusetustele.

Bare töövoog ja kitsam valik

Bare React Native'i puhul on vasteks android:usesCleartextTraffic application elemendil või võrgu turvakonfiguratsioon, mis lubab cleartexti ainult nimetatud domeenidele. Domeeniga piiratud vorm on eelistatav, sest see lubab sisemist API-t ja jätab kõik muu HTTPS-ile. See dokumenteerib ka oma erandite loendi, ja just selle osa kohta küsib ülevaataja.

Kumbki lähenemine ei muuda platvormi vaikeväärtust millegi jaoks, mida te ei nimetanud.

Tõestage seda kõigepealt seadme logist

Enne konfiguratsiooni muutmist hankige täpne tõrge. Ühendatud seadmes näitab adb logcat platvormi cleartext keeldumist ja nimetab komponendi, mis selle esile kutsus. Tagasi lükatud socket, nimi, mida ei õnnestu lahendada, või ebaõnnestunud TLS käepigistus osutavad hoopis mujale, ja cleartexti lubamine ainult nõrgestaks rakendust ilma põhjuseta.

Seejärel hoidke tootmist ausana. Cleartext on vastuvõetav labori lõpp-punktile, mis ei saa TLS-i pakkuda, ja ainult nii lühikeseks ajaks, kui suudate planeerida. Kui API suudab TLS-i privaatvõrgu sees lõpetada, pange sertifikaat seadme usaldushoidlasse ja jätke cleartext välja lülitatuks, sest tunnel krüpteerib tee oma väljapääsuni ja mitte midagi pärast seda.

Kui lõpp-punkt vastab HTTPS-iga, eemaldage luba, ehitage uuesti ja testige VPN-is ning tavalises Wi-Fi-s samas sessioonis. Nimede lahendamine võib neil kahel teel erineda ja ainult paar ütleb teile, kumb räägib tõtt.