Expo-aplikaĵo malsukcesas pri HTTP en Android 9: temas pri cleartext, ne pri VPN

Expo-konstruaĵo, kiu vokas simplan HTTP-API, malsukcesas en Android 9 kaj pli nova. La tunelo estas senkulpa: la cleartext-flago apartenas al la konstrua agordo.

Vi publikigis novan konstruaĵon, transiris al la VPN, kaj la sama ekrano ĉesis ŝargiĝi. En Android 9 kaj pli nova la pli ofta klarigo estas pli enuiga: la platformo rifuzas simplan HTTP por aplikoj celantaj API 28 aŭ pli altan, kaj la VPN nur ŝanĝis sufiĉe da kunteksto por malkaŝi ĝin. La eraro, kiun vi vidas, dependas de la HTTP-kliento, tial ĝi tiel malofte diras cleartext.

Kio fakte estas tiu malsukceso

Ekde Android 9 la platformo blokas cleartext defaŭlte, tuj kiam aplikaĵo celas API-nivelon 28 aŭ pli altan. La peton al simpla HTTP-adreso la platformo rifuzas antaŭ ol eĉ unu paketo lasas la aparaton. Kiun eraron vi vidos dependas de la HTTP-biblioteko: foje ĝenerala reta malsukceso, foje tempolimo, foje mesaĝo, kiu rekte nomas cleartext. Kion ĝi neniam faras, estas atingi vian servilon. Android dokumentas la defaŭlton kaj la domajne limigitan alternativon en sia gvidilo pri sekureca agordo.

Retumilo sur la sama aparato ankoraŭ povas ŝargi la paĝon, kaj tio estas la indico, kiun plej multaj homoj maltrafas. Retumiloj ne subiĝas al la retsekureca politiko de via aplikaĵo.

Kial oni kulpigas la VPN

Kutime tri aferoj ŝanĝiĝas samtempe. La aplikaĵo povas solvi alian gastigantnomon post kiam la VPN konektiĝas, la aparato povas esti nova kun pli nova konstruaĵo, aŭ la konstruaĵo mem eble moviĝis al cela API-nivelo, kiu aktivigas la defaŭlton. La VPN estas videbla kaj la cela SDK ne, do la VPN ricevas la bileton.

Komparu la celajn nivelojn de la malnova kaj nova konstruaĵoj antaŭ ol tuŝi la retan agordon. Aplikaĵo celanta 27 aŭ malpli altan estas esceptita, kaj tio klarigas ĉiun raporton «ĝi funkcias sur mia pli malnova telefono».

Kie la Expo-flago vere finiĝas

En administrata Expo-projekto, aldoni agordon al app.json ne redaktas Android-manifeston, ĉar prebuild kaj development-konstruaĵoj estas tio, kio produktas la manifeston. Agorda kromaĵo estas tio, kio skribas la agordon en tiu stadio. La subtenata vojo estas expo-build-properties, agordita en la aplika agordo kun la cleartext-opcio sub android.

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

La fragmento nur agordas la kromaĵan opcion; la manifesto produktiĝas poste. Rulu prebuild aŭ freŝan development-client-konstruaĵon, poste, antaŭ ol retesti, kontrolu la generitan AndroidManifest.xml pri android:usesCleartextTraffic, ĉar reŝargo nur per JS konservas la malnovan manifeston. Kongruigu la kromaĵan version al la Expo SDK, sur kiu la projekto ruliĝas. Kromaĵaj opcioj moviĝas inter eldonoj, kaj fragmento kopiita el alia SDK estas fidinda fonto de silentaj no-op-oj.

La bare-fluo kaj la pli mallarĝa opcio

Por bare React Native la ekvivalento estas android:usesCleartextTraffic sur la application-elemento, aŭ reta sekureca agordo, kiu permesas cleartext nur por nomitaj domajnoj. La domajne limigita formo estas la preferinda, ĉar ĝi permesas la internan API kaj lasas ĉion alian en HTTPS. Ĝi ankaŭ dokumentas sian propran esceptoliston, kaj tio estas la parto, pri kiu recenzanto demandos.

Neniu el la du aliroj ŝanĝas la defaŭlton de la platformo por io, kion vi ne nomis.

Unue pruvu tion el la aparata protokolo

Antaŭ ol redakti la agordon, akiru la precizan malsukceson. adb logcat sur konektita aparato montras la cleartext-rifuzon de la platformo kaj nomas la komponanton, kiu kaŭzis ĝin. Rifuzita ingo, nomo, kiu ne solviĝas, aŭ malsukcesa TLS-manpremo indikas tute aliloken, kaj ŝalti cleartext nur senbezone malfortigus la aplikaĵon.

Poste tenu la produkciadon honesta. Cleartext estas akceptebla por laboratoria finpunkto, kiu ne povas oferti TLS, kaj nur por la plej mallonga tempo, kiun vi povas plani. Se la API povas fini TLS ene de la privata reto, metu la atestilon en la fido-stokon de la aparato kaj lasu cleartext malŝaltita, ĉar la tunelo ĉifras la vojon ĝis sia eliro kaj nenion post ĝi.

Tuj kiam la finpunkto respondas per HTTPS, forigu la permeson, rekonstruu kaj testu en la VPN kaj en ordinara Wi-Fi en la sama seanco. Nomsolvado povas malsami inter tiuj du vojoj, kaj nur la paro diras al vi, kiu diras la veron.

Rilataj artikoloj