L’aplicació Expo falla amb HTTP a Android 9: és cleartext, no la VPN

Una compilació d’Expo que crida una API HTTP simple falla a Android 9 i posteriors. El túnel és innocent: l’indicador cleartext va a la configuració de compilació.

Heu publicat una compilació nova, heu passat a la VPN i la mateixa pantalla ha deixat de carregar-se. A Android 9 i posteriors l’explicació més habitual és més avorrida: la plataforma rebutja HTTP pla per a les aplicacions que apunten a l’API 28 o superior, i la VPN només ha canviat prou context per deixar-ho al descobert. L’error que veieu depèn del client HTTP, i per això tan poques vegades diu cleartext.

Què és realment aquesta fallada

A partir d’Android 9 la plataforma bloqueja cleartext per defecte quan una aplicació apunta al nivell d’API 28 o superior. La plataforma rebutja la petició a una adreça HTTP plana abans que surti cap paquet del dispositiu. Quin error veieu depèn de la biblioteca HTTP: de vegades una fallada de xarxa genèrica, de vegades un temps d’espera esgotat, de vegades un missatge que anomena cleartext directament. El que mai fa és arribar al vostre servidor. Android documenta el comportament per defecte i l’alternativa limitada per domini a la seva guia de configuració de seguretat.

Un navegador al mateix dispositiu encara pot carregar la pàgina, i aquesta és la pista que gairebé tothom passa per alt. Els navegadors no estan subjectes a la política de seguretat de xarxa de la vostra aplicació.

Per què es culpa la VPN

Normalment canvien tres coses alhora. L’aplicació pot resoldre un nom d’amfitrió diferent després de connectar la VPN, el dispositiu pot ser nou amb una compilació més recent, o la compilació mateixa pot haver passat a un nivell d’API objectiu que activa el comportament per defecte. La VPN es veu i l’SDK objectiu no, així que la VPN s’endú el tiquet.

Compareu els nivells objectiu de les compilacions antiga i nova abans de tocar la configuració de xarxa. Una aplicació que apunta a 27 o menys està exempta, i això explica tots els informes de «a mi em funciona al telèfon vell».

On acaba realment l’indicador d’Expo

En un projecte Expo gestionat, afegir un paràmetre a app.json no edita un manifest d’Android, perquè el manifest el produeixen el prebuild i les compilacions de desenvolupament. El que escriu el paràmetre en aquesta etapa és un connector de configuració. La ruta admesa és expo-build-properties, configurada a la configuració de l’aplicació amb l’opció cleartext sota android.

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

El fragment només defineix l’opció del connector; el manifest es produeix més tard. Executeu un prebuild o una compilació nova del client de desenvolupament, i després, abans de tornar a provar, reviseu l’AndroidManifest.xml generat per veure android:usesCleartextTraffic, perquè una recàrrega només de JS manté el manifest antic. Feu coincidir la versió del connector amb l’SDK d’Expo amb què funciona el projecte. Les opcions del connector es mouen entre versions, i un fragment copiat d’un altre SDK és una font fiable de no-ops silenciosos.

El flux bare i l’opció més estreta

Per a React Native bare l’equivalent és android:usesCleartextTraffic a l’element application, o una configuració de seguretat de xarxa que permeti cleartext només per a dominis concrets. La forma limitada per domini és la preferible, perquè permet l’API interna i deixa tota la resta en HTTPS. També documenta la seva pròpia llista d’excepcions, i aquesta és la part que un revisor preguntarà.

Cap dels dos enfocaments no canvia el comportament per defecte de la plataforma per a res que no hàgiu anomenat.

Primer demostreu-ho amb el registre del dispositiu

Abans d’editar la configuració, obteniu la fallada exacta. adb logcat en un dispositiu connectat mostra el rebuig de cleartext de la plataforma i anomena el component que l’ha provocat. Un sòcol rebutjat, un nom que no es resol o un handshake TLS fallit apunten a un lloc completament diferent, i habilitar cleartext només debilitaria l’aplicació per res.

Després manteniu la producció honesta. Cleartext és acceptable per a un punt de laboratori que no pot oferir TLS, i només durant el temps més curt que pugueu planificar. Si l’API pot acabar TLS dins de la xarxa privada, poseu el certificat al magatzem de confiança del dispositiu i deixeu cleartext desactivat, perquè el túnel xifra el camí fins a la seva sortida i res més enllà.

Quan el punt respongui per HTTPS, traieu el permís, torneu a compilar i proveu amb la VPN i amb Wi-Fi normal a la mateixa sessió. La resolució de noms pot diferir entre aquests dos camins, i només la parella us diu quin diu la veritat.

Articles relacionats