Expo-program se HTTP misluk op Android 9: dis cleartext, nie die VPN nie

’n Expo-bou wat ’n gewone HTTP-API aanroep, misluk op Android 9 en later. Die tonnel is onskuldig: die cleartext-vlag hoort in die boukonfigurasie.

Julle het ’n nuwe bou uitgestuur, na die VPN oorgeskakel, en dieselfde skerm het opgehou laai. Op Android 9 en later is die meer algemene verklaring verveliger: die platform weier gewone HTTP vir toepassings wat op API 28 of hoër teiken, en die VPN het net genoeg konteks verander om dit te laat opduik. Die fout wat jy kry, hang van die HTTP-kliënt af, en daarom sê dit so selde cleartext.

Wat die fout eintlik is

Van Android 9 af blokkeer die platform cleartext by verstek sodra ’n toepassing op API-vlak 28 of hoër teiken. Die versoek na ’n gewone HTTP-adres word deur die platform verwerp voordat ’n enkele pakket die toestel verlaat. Watter fout jy sien, hang van die HTTP-biblioteek af: soms ’n algemene netwerkfout, soms ’n tydverstreke, soms ’n boodskap wat cleartext reguit noem. Wat dit nooit doen nie, is om jou bediener te bereik. Android dokumenteer die verstek en die domeingebonde alternatief in sy gids vir sekuriteitskonfigurasie.

’n Blaaier op dieselfde toestel kan die bladsy steeds laai, en dit is die leidraad wat die meeste mense miskyk. Blaaiers is nie onderhewig aan jou toepassing se netwerksekuriteitsbeleid nie.

Waarom die VPN die skuld kry

Drie dinge verander gewoonlik gelyktydig. Die toepassing kan ná die VPN-verbinding ’n ander gasheernaam oplos, die toestel kan ’n nuwe een met ’n nuwer bou wees, of die bou self het dalk na ’n teiken-API-vlak geskuif wat die verstek aktiveer. Die VPN is sigbaar en die teiken-SDK is nie, so die VPN kry die kaartjie.

Vergelyk die ou en nuwe bou se teikenvlakke voordat jy aan netwerkkonfigurasie raak. ’n Toepassing wat op 27 of laer teiken, is vrygestel, wat elke verslag van die aard “dit werk op my ouer foon” verduidelik.

Waar die Expo-vlag werklik beland

In ’n bestuurde Expo-projek verander die byvoeg van ’n instelling by app.json nie ’n Android-manifes nie, want prebuild en ontwikkelingsboue is wat die manifes produseer. ’n Konfigurasie-inprop is die ding wat die instelling in daardie stadium skryf. Die ondersteunde roete is expo-build-properties, gekonfigureer in die toepassing se konfigurasie met die cleartext-opsie onder android.

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

Die fragment stel net die inprop-opsie; die manifes word later geproduseer. Voer ’n prebuild of ’n vars ontwikkelingskliënt-bou uit, en ondersoek dan die gegenereerde AndroidManifest.xml vir android:usesCleartextTraffic voordat jy weer toets, want ’n bloot JS-herlaai hou die ou manifes. Pas die inprop-weergawe aan by die Expo-SDK waarop die projek loop. Inprop-opsies skuif tussen weergawes, en ’n fragment wat uit ’n ander SDK gekopieer is, is ’n betroubare bron van stil no-ops.

Die bare workflow en die smaller opsie

Vir bare React Native is die ekwivalent android:usesCleartextTraffic op die application-element, of ’n netwerksekuriteitskonfigurasie wat cleartext net vir genoemde domeine toelaat. Die domeingebonde vorm is die een om te verkies, want dit laat die interne API toe en hou alles anders op HTTPS. Dit dokumenteer ook sy eie uitsonderinglys, en dit is die deel waaroor ’n resensent sal vra.

Nie een van die twee benaderings verander die platform se verstek vir enigiets wat jy nie genoem het nie.

Bewys dit eerste uit die toesteljoernaal

Voordat jy konfigurasie wysig, kry die presiese fout. adb logcat op ’n gekoppelde toestel wys die platform se cleartext-verwerping en noem die komponent wat dit veroorsaak het. ’n Geweierde socket, ’n naam wat nie oplos nie of ’n mislukte TLS-handdruk wys heeltemal elders heen, en om cleartext te aktiveer sou die toepassing net verniet verswak.

Hou dan die produksie eerlik. Cleartext is aanvaarbaar vir ’n laboratorium-eindpunt wat nie TLS kan bied nie, en net vir die kortste tyd wat jy kan beplan. As die API TLS binne die private netwerk kan beëindig, sit die sertifikaat in die toestel se trust store en laat cleartext gedeaktiveer, want die tonnel versleutel die pad na sy uitgang en niks verder nie.

Sodra die eindpunt op HTTPS antwoord, verwyder die toestemming, bou weer en toets op die VPN en op gewone Wi-Fi in dieselfde sessie. Naamresolusie kan tussen daardie twee paaie verskil, en net die paar sê vir jou watter een die waarheid praat.

Verwante artikels