אפליקציית Expo נכשלת ב-HTTP באנדרואיד 9: זה cleartext, לא ה-VPN

בנייה של Expo שקוראת ל-API פשוט של HTTP נכשלת באנדרואיד 9 ואילך. המנהרה חפה מפשע: דגל ה-cleartext שייך לקונפיגורציית הבנייה.

שחררתם בנייה חדשה, עברתם ל-VPN, ואותו מסך הפסיק להיטען. באנדרואיד 9 ואילך ההסבר הנפוץ יותר משעמם יותר: הפלטפורמה מסרבת ל-HTTP פשוט עבור אפליקציות שמכוונות ל-API 28 ומעלה, וה-VPN שינה רק מספיק הקשר כדי לחשוף את זה. השגיאה שאתם רואים תלויה בלקוח ה-HTTP, ולכן הוא כל כך נדיר אומר cleartext.

מהי התקלה הזו באמת

החל מאנדרואיד 9 הפלטפורמה חוסמת cleartext כברירת מחדל ברגע שאפליקציה מכוונת לרמת API 28 ומעלה. הפלטפורמה דוחה את הבקשה לכתובת HTTP פשוטה לפני שחבילה אחת יוצאת מהמכשיר. איזו שגיאה תראו תלוי בספריית ה-HTTP: לפעמים כשל רשת כללי, לפעמים פסק זמן, לפעמים הודעה שממנה את cleartext במפורש. מה שהיא אף פעם לא עושה זה להגיע לשרת שלכם. אנדרואיד מתעד את ברירת המחדל ואת החלופה המוגבלת לתחום במדריך תצורת האבטחה.

דפדפן באותו מכשיר עדיין יכול לטעון את העמוד, וזה הרמז שרוב האנשים מפספסים. דפדפנים אינם כפופים למדיניות אבטחת הרשת של האפליקציה שלכם.

למה מאשימים את ה-VPN

בדרך כלל שלושה דברים משתנים בבת אחת. האפליקציה עשויה לפענח שם מארח אחר לאחר שה-VPN מתחבר, המכשיר עשוי להיות חדש עם בנייה חדשה יותר, או שהבנייה עצמה עברה לרמת API יעד שמפעילה את ברירת המחדל. ה-VPN נראה וה-SDK ליעד לא, ולכן ה-VPN מקבל את הכרטיס.

השוו את רמות היעד של הבנייה הישנה והחדשה לפני שאתם נוגעים בתצורת הרשת. אפליקציה שמכוונת ל-27 או נמוך יותר פטורה, וזה מסביר כל דיווח מסוג «אצלי זה עובד בטלפון הישן».

לאן דגל ה-Expo באמת נוחת

בפרויקט Expo מנוהל, הוספת הגדרה ל-app.json לא עורכת מניפסט של אנדרואיד, כי prebuild ובניות פיתוח הם מה שמייצר את המניפסט. תוסף תצורה הוא מה שכותב את ההגדרה בשלב הזה. הנתיב הנתמך הוא expo-build-properties, שמוגדר בתצורת האפליקציה עם אפשרות ה-cleartext תחת android.

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

הקטע רק מגדיר את אפשרות התוסף; המניפסט נוצר מאוחר יותר. הריצו prebuild או בנייה חדשה של לקוח הפיתוח, ואז, לפני בדיקה חוזרת, בדקו את ה-AndroidManifest.xml שנוצר עבור android:usesCleartextTraffic, כי טעינה מחדש של JS בלבד שומרת על המניפסט הישן. התאימו את גרסת התוסף ל-Expo SDK שהפרויקט רץ עליו. אפשרויות תוסף זזות בין מהדורות, וקטע שהועתק מ-SDK אחר הוא מקור אמין ל-no-op שקטים.

זרימת ה-bare והאפשרות הצרה יותר

עבור bare React Native המקבילה היא android:usesCleartextTraffic על רכיב ה-application, או תצורת אבטחת רשת שמתירה cleartext רק לתחומים בשמם. הצורה המוגבלת לתחום היא זו שכדאי להעדיף, כי היא מתירה את ה-API הפנימי ומשאירה כל השאר ב-HTTPS. היא גם מתעדת את רשימת החריגים של עצמה, וזה החלק שסוקר ישאל עליו.

אף אחת משתי הגישות לא משנה את ברירת המחדל של הפלטפורמה לשום דבר שלא ציינתם בשמו.

קודם להוכיח את זה מיומן המכשיר

לפני עריכת התצורה, השיגו את התקלה המדויקת. adb logcat במכשיר מחובר מראה את דחיית ה-cleartext של הפלטפורמה וממנה את הרכיב שהעלה אותה. סוקט שנדחה, שם שלא נפתר או לחיצת יד TLS שנכשלה מצביעים למקום אחר לגמרי, והפעלת cleartext רק תחליש את האפליקציה לחינם.

אחר כך שמרו על ייצור כן. cleartext מקובל עבור נקודת קצה במעבדה שאינה יכולה להציע TLS, ורק לזמן הקצר ביותר שתוכלו לתכנן. אם ה-API יכול לסיים TLS בתוך הרשת הפרטית, שימו את האישור במאגר האמון של המכשיר והשאירו את cleartext כבוי, כי המנהרה מצפינה את הדרך עד ליציאה שלה ושום דבר מעבר לה.

ברגע שנקודת הקצה עונה ב-HTTPS, הסירו את ההרשאה, בנו מחדש ובדקו על ה-VPN ועל Wi-Fi רגיל באותה הפעלה. פתרון שמות עשוי להיות שונה בין שני המסלולים האלה, ורק הצמד אומר לכם מי מספר את האמת.

מאמרים קשורים