Aplicația Expo eșuează la HTTP pe Android 9: este cleartext, nu VPN-ul

O compilare Expo care apelează un API HTTP simplu eșuează pe Android 9 și versiunile ulterioare. Tunelul este nevinovat: indicatorul cleartext aparține configurației compilării.

Ați publicat o compilare nouă, ați trecut pe VPN și același ecran a încetat să se încarce. Pe Android 9 și versiunile ulterioare explicația mai frecventă este mai plictisitoare: platforma refuză HTTP simplu pentru aplicațiile care vizează API 28 sau mai sus, iar VPN-ul a schimbat doar suficient context ca să scoată asta la iveală. Eroarea pe care o vedeți depinde de clientul HTTP, de aceea spune atât de rar cleartext.

Ce este de fapt această eșuare

De la Android 9 platforma blochează cleartext implicit imediat ce o aplicație vizează nivelul API 28 sau mai sus. Platforma respinge cererea către o adresă HTTP simplă înainte ca un singur pachet să părăsească dispozitivul. Ce eroare vedeți depinde de biblioteca HTTP: uneori o eroare de rețea generică, uneori un timeout, uneori un mesaj care numește cleartext direct. Ce nu face niciodată este să ajungă la serverul dumneavoastră. Android documentează comportamentul implicit și alternativa limitată la domeniu în ghidul de configurare a securității.

Un browser de pe același dispozitiv poate încărca în continuare pagina, și acesta este indiciul pe care majoritatea îl ratează. Browserele nu sunt supuse politicii de securitate a rețelei aplicației dumneavoastră.

De ce este vinovat VPN-ul

De obicei se schimbă trei lucruri deodată. Aplicația poate rezolva un alt nume de gazdă după conectarea VPN-ului, dispozitivul poate fi nou cu o compilare mai recentă, sau compilarea însăși poate fi trecut la un nivel API țintă care activează comportamentul implicit. VPN-ul se vede, iar SDK-ul țintă nu, așa că VPN-ul primește tichetul.

Comparați nivelurile țintă ale compilării vechi și ale celei noi înainte de a atinge configurația de rețea. O aplicație care vizează 27 sau mai puțin este exceptată, iar asta explică fiecare raport de tipul «la mine merge pe telefonul vechi».

Unde ajunge de fapt indicatorul Expo

Într-un proiect Expo administrat, adăugarea unei setări în app.json nu editează un manifest Android, pentru că manifestul este produs de prebuild și de compilările de dezvoltare. Pluginul de configurare este cel care scrie setarea în acea etapă. Calea acceptată este expo-build-properties, configurat în configurația aplicației cu opțiunea cleartext sub android.

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

Fragmentul doar setează opțiunea pluginului; manifestul este produs mai târziu. Rulați un prebuild sau o compilare nouă a clientului de dezvoltare, apoi, înainte de a retesta, inspectați AndroidManifest.xml generat pentru android:usesCleartextTraffic, pentru că o reîncărcare doar cu JS păstrează manifestul vechi. Potriviți versiunea pluginului cu SDK-ul Expo pe care rulează proiectul. Opțiunile pluginului se mută între versiuni, iar un fragment copiat din alt SDK este o sursă sigură de no-op-uri silențioase.

Fluxul bare și opțiunea mai îngustă

Pentru React Native bare echivalentul este android:usesCleartextTraffic pe elementul application, sau o configurație de securitate a rețelei care permite cleartext doar pentru domenii numite. Forma limitată la domeniu este cea de preferat, pentru că permite API-ul intern și lasă tot restul pe HTTPS. Documentează și propria listă de excepții, iar aceasta este partea despre care va întreba un recenzent.

Niciuna dintre abordări nu schimbă comportamentul implicit al platformei pentru ceva ce nu ați numit.

Mai întâi dovediți-o din jurnalul dispozitivului

Înainte de a edita configurația, obțineți eșuarea exactă. adb logcat pe un dispozitiv conectat arată refuzul cleartext al platformei și numește componenta care l-a ridicat. Un socket refuzat, un nume care nu se rezolvă sau un handshake TLS eșuat indică cu totul altceva, iar activarea cleartext ar slăbi aplicația degeaba.

Apoi țineți producția onestă. Cleartext este acceptabil pentru un endpoint de laborator care nu poate oferi TLS, și doar pentru cel mai scurt timp pe care îl puteți planifica. Dacă API-ul poate termina TLS în interiorul rețelei private, puneți certificatul în magazinul de încredere al dispozitivului și lăsați cleartext dezactivat, pentru că tunelul criptează drumul până la ieșirea lui și nimic dincolo de ea.

Când endpointul răspunde pe HTTPS, scoateți permisiunea, recompilați și testați pe VPN și pe Wi-Fi obișnuit în aceeași sesiune. Rezolvarea numelor poate diferi între aceste două căi, iar doar perechea vă spune care spune adevărul.

Articole similare