blog

Android WebView’da shaxsni tasdiqlash xatolarini yaxshilash

NEXTREE.

• 9 min read
Android WebView’da shaxsni tasdiqlash xatolarini yaxshilash

1. Ish haqida ma’lumot

Bu ish identifikatsiyani tekshirish funksiyasini noldan loyihalash emas, balki mavjud funksiyada yuzaga kelgan xatoni tahlil qilish va tuzatishni o‘z ichiga olgan texnik xizmat ko‘rsatish vazifasi edi. Loyihada React Native ilovasidagi umumiy WebView orqali Vue’da amalga oshirilgan veb-ekranlar taqdim etilgan bo‘lib, ekranga N*** CheckPlus identifikatsiyani tekshirish xizmati allaqachon integratsiya qilingan edi.

Funksiya veb-brauzerlarda va iOS ilovasida odatdagidek ishlagan, biroq autentifikatsiya faqat React Native Android WebView’ida muvaffaqiyatsiz yakunlangan. Vazifa mavjud integratsiya tuzilmasini to‘liq o‘zgartirish emas, balki platformaga xos farqlar asosida sababni aniqlash va umumiy WebView’ning boshqa funksiyalariga ta’sirni minimallashtirgan holda autentifikatsiya oqimini tiklashdan iborat edi.

2. Xatoning yuzaga kelishi va tahlildan olingan belgilar

2.1 Tasdiqlangan xato

Android ilovasining WebView’ida N*** identifikatsiyasi tekshirilganda, autentifikatsiya yakunlanmadi va foydalanuvchi xato sahifasiga yo‘naltirildi. O‘sha vaqtda quyidagi xato qayd etilgan.

SecurityError: Failed to read a named property 'checkSuccess' from 'Window':
Blocked a frame with origin "https://n***.checkplus.co.kr"
from accessing a cross-origin frame.

Bu xabar turli kelib chiqish manbalariga ega Windows yoki Frames o‘rtasidagi boshqa oynaning xususiyatiga bevosita kirish urinishi Same-Origin Policy tomonidan bloklanganini anglatadi. Biroq, checkSuccessloyihaning o‘zida yozilgan funksiya emas, balki N*** autentifikatsiya ekrani ichida ishlatiladigan nom edi. Shu sababli loyihaning Vue kodida ushbu funksiyani bevosita o‘zgartirish orqali muammoga yondashishning imkoni bo‘lmadi.

Bundan tashqari, ekranda oxirida ko‘rsatilgan istisno xatoning dastlabki sababi deb qabul qilinmadi. Autentifikatsiya oqimi avvalroq muvaffaqiyatsiz yakunlangan bo‘lishi, shundan so‘ng xato sahifasidagi keyingi skript bajarilayotganda Cross-Origin istisnosi yuzaga kelgan bo‘lishi mumkin.

2.2 Bajarilish muhitlari va URL navigatsiya oqimlarini taqqoslash

Bir xil funksiya turli bajarilish muhitlarida taqqoslanganda, u veb-brauzerlarda, xuddi shu Android qurilmasidagi oddiy brauzerda va iOS ilovasida odatdagidek ishladi, faqat React Native Android WebView’ida muvaffaqiyatsiz yakunlandi. Ushbu farq asosida men avvalo N*** xizmatining o‘zini yoki Vue biznes mantiqini emas, Android WebView’ining URL bilan ishlash oqimini tekshirdim.

Muvaffaqiyatsizlikdan bevosita oldingi qaydlarda quyidagi URL navigatsiya oqimi tasdiqlandi.

/cert/mobileCert/main
> /cert/mobileCert/method
> /cert/mobileCert/fail/applink
> SecurityError 발생

SecurityErrorAsosiy belgi shundan iborat ediki, shu nuqtaga qadar oqim /fail/applink yo‘lidan o‘tgan. Ushbu qaydning o‘zi N*** ichidagi muvaffaqiyatsizlikning aniq sababini aniqlash uchun yetarli emas edi, biroq yakuniy Cross-Origin istisnosidan oldin sodir bo‘lgan tashqi autentifikatsiya ilovasini ishga tushirish bosqichi avvalroq muvaffaqiyatsiz yakunlangan yoki yo‘qligini tekshirish zarur edi.

3. Mavjud kodni ko‘rib chiqish va sabab doirasini toraytirish

3.1 Haqiqiy o‘zgartirish nuqtasini aniqlash

Muammo faqat Android’da yuzaga kelgani sababli, dastlab Java yoki Kotlin’dagi WebViewClient ni o‘zgartirish kerakmi, deb ko‘rib chiqdim. Biroq loyiha Android Activity’si WebView’ni bevosita yaratmas edi; haqiqiy ekran react-native-webview ni o‘rab turuvchi umumiy TypeScript komponentida qurilgan edi.

Shu sababli o‘zgartirish nuqtasi Android Activity’si emas, umumiy React Native WebView komponenti edi. Xato Android’da yuzaga kelgan taqdirda ham, keraksiz o‘zgartirishlar doirasini kamaytirish uchun avvalo loyihaning qaysi qatlami native funksionallikni boshqarishini aniqlash zarur.

3.2 Mavjud sozlamalar va ichki callback oqimini ajratish

Mavjud umumiy WebView’da allaqachon originWhitelist={['*']}, JavaScript, DOM Storage, ko‘p oynali rejim va platformaga xos cookie sozlamalari qo‘llangan edi. Android uchun thirdPartyCookiesEnabled, domStorageEnabled va setSupportMultipleWindows kabi sozlamalar allaqachon mavjud bo‘lgani sababli, oddiygina cookie yoki storage opsiyasi yetishmaganini asosiy sabab deb hisoblash qiyin edi.

originWhitelist WebView ruxsat beradigan navigatsiya maqsadlari doirasini belgilaydi; u Same-Origin Policy’ni o‘chirib qo‘ymaydi va tashqi ilovaning ishga tushishini kafolatlamaydi. Shu sababli sababni faqat sozlamalarga asoslanib aniqlash o‘rniga, o‘sha paytda tekshirilgan umumiy komponentda tashqi ilova URL’lari uchun aniq tarmoqlanuvchi handler mavjud emasligiga asoslanib, tekshiruv doirasini toraytirdim.

Loyihada, shuningdek, PC popup natija sahifasi window.opener.callbackEncodeData() ni chaqiradigan alohida oqim mavjud edi. Bunga qarama-qarshi ravishda, mobil ilova formani _self bilan yuborar va qaytgan sahifada EncodeData ni qayta ishlardi, holbuki ushbu xatoda ko‘rsatilgan funksiya nomi checkSuccess edi. Shu sababli PC popup callback muammosi bilan Android WebView’dagi tashqi ilovani ishga tushirish muammosini bir xil sababga ega deb qaramadim.

Ko‘p oynali rejim sozlamalarini o‘zgartirish imkoniyatini ham ko‘rib chiqdim, biroq buni amaldagi yechimga qo‘llamadim. Yechimga faqat normal ishlashi tekshirilgan choralar kiritildi.

3.3 Tashqi ilovalarning maxsus sxemalarini qayta ishlashni tasdiqlash

N*** identifikatsiyasini tekshirish jarayonida P*** kabi tashqi autentifikatsiya ilovasi ishga tushirilganda, URL odatiy http:// yoki https:// manzil emas, balki aintent: URI yoki tauthlink: maxsus sxemalardan foydalanish mumkin. O‘sha paytdagi ish qaydlarida quyidagi shakl ham saqlanib qolgan: tauthlink://sktauth?... maxfiy parametrlar chiqarib tashlangan holda.

Odatdagi mobil brauzer bunday URL manzillarni operatsion tizimning ilovani ishga tushirish oqimiga uzatishi mumkin, biroq ilova ichidagi WebView’da URL navigatsiyasi so‘rovlarini ushlab qolish va ularni React Native yoki native qatlamga uzatish zarur bo‘lishi mumkin.

O‘sha paytda ko‘rib chiqilgan umumiy WebView komponentida cookie va oynalarga oid sozlamalar mavjud edi, biroq autentifikatsiya ilovasi URL manzillarini HTTP URL manzillaridan aniq ajratib, tashqi ilovaga uzatuvchi handler mavjud emas edi. Platformaga xos qayta tiklash natijalari, /fail/applink navigatsiya qaydi va mavjud kodda aniqlangan kamchiliklarga asoslanib, avval Android’dagi tashqi autentifikatsiya ilovasi URL manzillarini qayta ishlashni qo‘shdik.

4. Yechimni qo‘llash

4.1 Qayta ishlash mezonlari

onShouldStartLoadWithRequest autentifikatsiya jarayonida yuz beradigan URL navigatsiyasi so‘rovlarini tekshirish va WebView tomonidan qayta ishlanishi davom etishi kerak bo‘lgan so‘rovlarni operatsion tizimga uzatilishi kerak bo‘lgan tashqi ilova so‘rovlaridan ajratish uchun ishlatildi. Ushbu masaladagi URL boshlang‘ich yuklanish emas, balki autentifikatsiya jarayonida yuz beradigan navigatsiya so‘rovi bo‘lgani sababli, bu yondashuvdan muammoni hal qilishda foydalanish mumkin edi.

Qayta ishlash mezonlari quyidagicha tartibga solindi.

  • http://, https://, about:blank WebView tomonidan qayta ishlanishda davom etadi.

  • Faqat Android’da tekshirilgan autentifikatsiya ilovasi URL manzillariga (intent:, tauthlink:) tashqi ilovani ishga tushirish maqsadi sifatida ruxsat beriladi.

  • Tashqi ilovaga uzatiladigan URL manzillar uchun false qaytariladi, shunda WebView ularni yana yuklamaydi.

  • Ruxsat berilgan ro‘yxatga kiritilmagan sxemalar ishga tushirilmaydi va WebView tomonidan yuklash ham to‘xtatiladi.

  • iOS’da ushbu handler alohida Linking chaqiruvini amalga oshirmaydi.

4.2 Asosiy kod

Quyidagi kod o‘sha paytda qo‘llangan asosiy qayta ishlash tuzilmasini tushunishni osonlashtirish uchun soddalashtirilgan misol sifatida keltirilgan.

const handleShouldStartLoadWithRequest = (
  {url}: {url: string},
): boolean => {
  if (/^(https?:\/\/|about:blank(?:#.*)?$)/i.test(url)) return true;
  if (Platform.OS !== 'android') return true;

  const isIntentUrl = /^intent:/i.test(url);
  const isTAuthUrl = /^tauthlink:/i.test(url);
  if (!isIntentUrl && !isTAuthUrl) return false;

  const targetUrl = isIntentUrl ? parseIntentUrl(url) : url;
  if (!targetUrl) {
    showAuthAppError();
    return false;
  }

  void Linking.openURL(targetUrl).catch(showAuthAppError);
  return false;
};

Asosiy jihat — oddiy web URL manzillarini ruxsat berilgan Android autentifikatsiya ilovasi URL manzillaridan ajratish, tashqi ilovani ishga tushirishni Linking.openURL() orqali so‘rash va keyin WebView’ning ushbu navigatsiyani amalga oshirishini to‘xtatishdir.

parseIntentUrl() o‘sha paytda ko‘rib chiqilgan intent: formatidan haqiqiy ilova-sxemasi URL manzilini tuzuvchi yordamchi funksiyadir. O‘sha davrdagi qaydlarda ilova ishga tushmay qolganda getFallbackUrl() orqali S.browser_fallback_url ni tekshiradigan alohida tarmoq ham mavjud edi. Yuqoridagi misolda URL navigatsiyasini ajratishning faqat asosiy tuzilmasi saqlangan; bu ikki funksiya barcha Android Intent URI’lari uchun umumiy maqsadli parserlar emas, shuning uchun ulardan foydalanish doirasi amaldagi xizmatda tekshirilgan formatlar bilan cheklanishi kerak.

Sof maxsus sxema tauthlink: uchun ilova paketi yoki zaxira URL manzili haqida ma’lumot bo‘lmasligi mumkin. Shu sababli, ishga tushirish muvaffaqiyatsiz bo‘lganda faqat bildirishnoma ko‘rsatish yoki sxemadan paketga mosliklarni boshqarib, foydalanuvchilarni do‘konga yo‘naltirish masalasi alohida siyosat sifatida belgilanadi.

Agar umumiy komponent tashqi WebView xususiyatlarini ...rest orqali uzatsa, mavjud onShouldStartLoadWithRequest mavjud yoki yo‘qligini tekshirishingiz kerak. Xususiyatlar tartibiga asoslanib ulardan birini ikkinchisi bilan shunchaki almashtirish o‘rniga, mavjud handler va umumiy handler qaytargan natijalarni birlashtirish xavfsizroqdir.

5. Qayta test natijalari

O‘sha paytdagi o‘zgartirishdan so‘ng, avval muvaffaqiyatsiz bo‘lgan Android muhitida N*** shaxsni tasdiqlash jarayonini qayta sinab ko‘rdik. Oddiy https:// autentifikatsiya sahifasi WebView’da ochilishda davom etdi, autentifikatsiya ilovasining maxsus sxemasi esa WebView tomonidan bevosita yuklanmay, tashqi ilovani ishga tushirish so‘rovi sifatida uzatildi. Natijada P*** kabi tashqi autentifikatsiya ilovalariga chaqiruvlar va N*** shaxsni tasdiqlash jarayoni davom etdi, shuningdek mavjud /fail/applink va SecurityErrorUlar ketma-ket bajarilganidagi nosozlik oqimi endi ayni stsenariyda qayta takrorlanmadi.

Bu natija maxsus sxemalarni qayta ishlash mantiqi bir xil kelib chiqish siyosatini o‘zgartirganini anglatmaydi. Tashqi ilovaga chaqiruv odatiy yo‘l orqali bajarilgani sababli, jarayon endi /fail/applink uchun keyingi skript bajariladigan nosozlik yo‘liga kirmadi va natijada keyingi Cross-Origin istisnosi ham yuzaga kelmadi.

Biroq, maxsus sxemalarni qayta ishlashning mavjud emasligi SecurityErrorning yagona ichki sababi bo‘lgan degan xulosaga kelmadim. Buning sababi, N*** ichida checkSuccess chaqiriladigan butun tuzilmani bevosita tekshirmaganim edi. O‘sha paytda qaydlardan tasdiqlash mumkin bo‘lgan faktlar quyidagilardan iborat edi.

  • Autentifikatsiya faqat Android ilovasining WebView oynasida amalga oshmadi.

  • U muvaffaqiyatsiz tugaganda, /fail/applink manziliga murojaat qilindi, undan keyin SecurityError yuz berdi.

  • O‘sha paytda tekshirilgan umumiy WebView oynasida tashqi autentifikatsiya ilovasi URL manzillarini aniq qayta ishlaydigan mantiq mavjud emas edi.

  • Bu qayta ishlash qo‘shilgach, ayni autentifikatsiya stsenariysi yana odatdagidek ishladi.

Shuning uchun bu holatni “xato Cross-Origin siyosatini chetlab o‘tish orqali olib tashlandi” deb emas, balki “Android WebView oynasida tashqi autentifikatsiya ilovasi URL manzillarini qayta ishlash mantiqi to‘ldirilgach, oldingi nosozlik yo‘li va undan keyingi Cross-Origin istisnosi ayni stsenariyda endi qayta takrorlanmadi” deb umumlashtirish to‘g‘riroq bo‘ladi.

6. Amalga oshirish bo‘yicha mulohazalar

Umumiy WebView oynasiga URL navigatsiyasi qayta ishlagichini qo‘shish N*** dan tashqari ekranlarning ham ayni mantiqdan o‘tishiga olib kelishi mumkin. HTTP bo‘lmagan har bir URL manzilini tashqi ilovaga yo‘naltirish ko‘zda tutilmagan ilovalar ishga tushishiga yoki mavjud funksionallikning o‘zgarishiga sabab bo‘lishi mumkin. Shu sababli qamrovni autentifikatsiya ekranlari yoki autentifikatsiya davom etayotgan holatlar bilan cheklash va faqat tekshirilgan sxemalarga ruxsat berish xavfsizroq.

intent: URI qo‘llab-quvvatlashi umumiy tarzda ta’minlanishi kerak bo‘lsa, amalda ishlatiladigan ichki sxemalar, paketlar va zaxira URL domenlari ham ruxsat berilganlar ro‘yxati asosida tekshirilishi lozim. To‘liq autentifikatsiya URL manzili jurnallarga yozilsa, unda identifikatorlar yoki tokenlar bo‘lishi mumkin. Shu sababli sxema va xost kabi faqat zarur ma’lumotlarni qayd etish, maxfiy parametrlarni esa niqoblash kerak.

7. Ish jarayonida olingan tajriba

7.1 Yakuniy xatodan oldingi oqim tekshirilishi kerak

Men aniqlagan birinchi xabar Cross-Origin SecurityError edi, biroq URL navigatsiyasi tarixi ilova bundan oldin /fail/applink yo‘liga o‘tganini ko‘rsatdi. Agar faqat yakuniy istisnoni bevosita tuzatishga uringan bo‘lsam, tashqi ilovaga chaqiruv avvalroq muvaffaqiyatsiz tugaganini ko‘rsatuvchi belgini e’tibordan chetda qoldirishim mumkin edi. Hodisani tahlil qilishda istisnoga yetib borishdan oldingi URL navigatsiyasi va holat o‘zgarishlari ham tekshirilishi kerak.

7.2 Platformalarni taqqoslash tahlil doirasini toraytirishi mumkin

Muammo veb-brauzerlarda va iOS ilovasida odatdagidek ishlagani, ammo faqat React Native Android WebView oynasida yuzaga kelmagani tahlil nishonini tezda toraytirishimga imkon berdi. Bir xil Android qurilmasidagi oddiy brauzer va ilova WebView oynasini taqqoslash ham operatsion tizimning o‘zidagi farqlarni WebView integratsiyasi yondashuvidagi farqlardan ajratishga yordam berdi.

7.3 Amalga oshirilgan chora ko‘rib chiqilgan muqobillardan ajratilishi kerak

Tahlil davomida men bir nechta variantni, jumladan oynalarni boshqarish usullari va ko‘p oynali sozlamalarni ko‘rib chiqdim. Biroq, odatdagi ish holatini tiklagani tasdiqlangan asosiy o‘zgarish onShouldStartLoadWithRequest ichida ruxsat etilgan tashqi ilova URL manzillarini ajratib, ularni Linking ga yo‘naltiradigan qayta ishlash edi. Texnik holatni hujjatlashtirishda amalda joriy etilib, tekshirilgan choralarni faqat imkoniyat sifatida ko‘rib chiqilgan muqobillardan ajratish natijalarni bo‘rttirib ko‘rsatishning oldini olishga yordam beradi.

8. Xulosa

Bu ish mavjud React Native asosidagi gibrid ilovaning faqat Android WebView oynasida yuzaga kelgan N*** shaxsni tasdiqlash xatosini tahlil qilish va yaxshilashdan iborat holat edi. Tekshiruv Cross-Origin xatosidan boshlangan bo‘lsa-da, platformaga xos takrorlanish natijalarini, nosozlikdan bevosita oldingi URL navigatsiyasi oqimini, mavjud umumiy WebView sozlamalarini va maxsus qayta chaqiruv tuzilmasini ketma-ket tekshirish orqali tahlilni tashqi autentifikatsiya ilovasi URL manzillarini qayta ishlashga qaratdim.

O‘sha paytdagi qaydlarga asoslanib, oddiy veb-URL manzillarini Android autentifikatsiya ilovasi URL manzillaridan ajratish va ruxsat etilgan sxemalarni React Native Linking ga yo‘naltirish uchun amalga oshirishni to‘ldirdim. Tuzatishdan so‘ng tashqi autentifikatsiya ilovasiga chaqiruv va N*** shaxsni tasdiqlash jarayoni ayni nosozlik stsenariysida odatdagidek bajarildi, /fail/applink va undan keyingi SecurityError endi qayta takrorlanmadi.

Bu holat menga ekranda ko‘rsatilgan oxirgi xatoni bevosita tuzatish bilangina cheklanmay, xatodan oldingi URL navigatsiyasini va vebdan native qismga o‘tish chegarasida aslida qaysi qayta ishlash yetishmaganini tekshirish muhimligini o‘rgatdi. Texnik holat xulosasini bo‘rttirib ko‘rsatmaslik uchun tasdiqlangan faktlarni taxminlardan ajratish ham muhim edi.

green

Site footer