Expo-forrit mistekst á HTTP í Android 9: það er cleartext, ekki VPN-ið

Þú gafst út nýtt build, fórst yfir á VPN-ið, og sami skjárinn hætti að hlaðast. Í Android 9 og nýrri er algengari skýringin dauflegri: pallurinn neitar venjulegu HTTP fyrir forrit sem miða við API 28 eða hærra, og VPN-ið breytti bara nægilegu samhengi til að afhjúpa það. Villan sem þú sérð fer eftir HTTP-biðlaranum, þess vegna segir hann svo sjaldan cleartext.

Hvað er þessi mistök í raun

Frá Android 9 lokar pallurinn á cleartext sjálfgefið um leið og forrit miðar við API-stig 28 eða hærra. Pallurinn hafnar beiðninni á venjulegt HTTP-vistfang áður en eitt pakka yfirgefur tækið. Hvaða villu þú sérð fer eftir HTTP-safninu: stundum almenn nettruflun, stundum tímamörk, stundum skilaboð sem nefna cleartext beint. Það sem hún gerir aldrei er að ná til þjónsins þíns. Android skjalfestir sjálfgefna hegðun og þann valkost sem er takmarkaður við lén í leiðbeiningum sínum um öryggisstillingar.

Vafri á sama tæki getur samt hlaðið síðunni, og það er vísbendingin sem flestir missa af. Vafrar lúta ekki netöryggisstefnu forritsins þíns.

Af hverju er VPN-ið kennt um

Venjulega breytast þrír hlutir í einu. Forritið gæti leyst annað hýsilnafn eftir að VPN-ið tengist, tækið gæti verið nýtt með nýrra buildi, eða buildið sjálft gæti hafa færst á mark-API-stig sem virkjar sjálfgefnu hegðunina. VPN-ið sést og mark-SDK-ið sést ekki, svo VPN-ið fær miðann.

Berðu saman markstig gamla og nýja buildsins áður en þú snertir netstillingarnar. Forrit sem miðar við 27 eða lægra er undanþegið, og það skýrir hverja skýrslu um að það virki í gamla símanum mínum.

Hvar Expo-flaggið lendir í raun

Í stýrðu Expo-verkefni breytir það ekki Android-manifesti að bæta stillingu við app.json, því prebuild og þróunarbuild eru það sem framleiða manifestið. Stillingarviðbót er það sem skrifar stillinguna á því stigi. Studda leiðin er expo-build-properties, stillt í forritsstillingunum með cleartext-valkostinum undir android.

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

Brotinn stillir bara valkost viðbótarinnar; manifestið verður til síðar. Keyrðu prebuild eða ferskt þróunarviðskiptabuild, og skoðaðu svo fyrir endurprófun AndroidManifest.xml sem varð til með tilliti til android:usesCleartextTraffic, því endurhleðsla með aðeins JS heldur gamla manifestinu. Stilltu útgáfu viðbótarinnar í samræmi við Expo SDK sem verkefnið keyrir á. Valkostir viðbóta færast á milli útgáfa, og brot sem er afritað úr öðru SDK er áreiðanleg uppspretta hljóðlausra no-op-a.

Bare-flæðið og þrengri valkosturinn

Fyrir bare React Native er hliðstæðan android:usesCleartextTraffic á application-einingunni, eða netöryggisstilling sem leyfir cleartext aðeins fyrir tilgreind lén. Lénstakmarkaða formið er það sem ætti að velja, því það leyfir innra API-ið og lætur allt annað vera á HTTPS. Það skjalfestir líka sinn eigin undantekningarlista, og það er hlutinn sem ritstjóri mun spyrja um.

Hvorug nálgunin breytir sjálfgefinni hegðun pallsins fyrir neitt sem þú nefndir ekki.

Sannaðu það fyrst út frá tækjalogginu

Áður en þú breytir stillingunum skaltu fá nákvæmu villuna. adb logcat á tengdu tæki sýnir cleartext-höfnun pallsins og nefnir eininguna sem olli henni. Hafnað samband, nafn sem leysist ekki eða misheppnað TLS-handaband bendir á allt annað, og að virkja cleartext myndi bara veikja forritið að óþörfu.

Haltu svo framleiðslunni heiðarlegri. Cleartext er ásættanlegt fyrir rannsóknar-endapunkt sem getur ekki boðið TLS, og aðeins í stysta tíma sem þú getur skipulagt. Ef API-ið getur lokið TLS innan einkanetsins skaltu setja vottorðið í traustageymslu tækisins og láta cleartext vera óvirkt, því göngin dulkóða leiðina að útgangi sínum og ekkert handan hans.

Um leið og endapunkturinn svarar yfir HTTPS skaltu fjarlægja heimildina, byggja upp á ný og prófa á VPN-inu og venjulegu Wi-Fi í sömu lotu. Nafnupplausn getur verið misjöfn á þessum tveimur leiðum, og aðeins parið segir þér hvort segir satt.