WebView’dagi ijtimoiy autentifikatsiyani RN ko‘prigiga o‘tkazish

1. Kirish

Class Leader Note mobil ilovasi gibrid arxitekturadan foydalanadi: React Native mahalliy funksiyalarni boshqaradi, mavjud React veb-ilovasi esa WebView orqali taqdim etiladi. Ushbu arxitekturaning afzalligi shundaki, avval amalga oshirilgan ekranlar va biznes mantiqidan qayta foydalanish mumkin. Dastlab ijtimoiy login ham vebdagi kabi ishlashi, ya’ni OAuth sahifasiga WebView ichida o‘tish orqali amalga oshishi mumkin deb o‘ylagandik. Oqim brauzerda odatdagidek ishlagani sababli, mobil qurilmada sezilarli farq bo‘lmaydi deb kutgandik.

Biroq Google loginini haqiqiy mobil muhitda ishga tushirganimizda, 403 disallowed_useragent xatosi yuz berdi. Buning sababi OAuth kaliti yoki redirect URL emas, balki autentifikatsiya ekrani ilova boshqaradigan ichki WebView ichida ochilgani edi. Google siyosati va RFC 8252 native ilovalarga OAuth autentifikatsiyasi uchun ichki user-agentdan foydalanmaslikni tavsiya qiladi. Host ilova WebView ichidagi kontent va cookie’lardan foydalanishi mumkinligi sababli, autentifikatsiya provayderi bunday oqimni bloklashi mumkin.

Muammoni hal qilishning eng oddiy usuli autentifikatsiya URL’ini tashqi brauzerda ochish edi. Biroq login’dan so‘ng Class Leader Note a’zoni qidirish, yangi foydalanuvchini ro‘yxatdan o‘tkazish tarmog‘i, rol tanlash va sessiya yaratish uchun mavjud veb mantiqidan foydalanishi kerak edi. Agar butun oqim tashqi brauzerga ko‘chirilsa, ilovaga qaytish uchun deep linking va holatni tiklashni ham yangidan loyihalashga to‘g‘ri kelardi. Aksincha, autentifikatsiyadan xizmat sessiyasini yaratishgacha bo‘lgan hamma narsani React Native’da qayta amalga oshirsak, bir xil domen qoidalari veb va ilova o‘rtasida takrorlanardi.

Shu sababli ushbu ishda mas’uliyatlarni uch qismga ajratdik. React Native har bir Provider’ning native SDK’i orqali foydalanuvchini autentifikatsiya qiladi, Bridge natijani WebView’ga xavfsiz yetkazadi, React veb-ilovasi esa mavjud Gate tekshiruvi va login/ro‘yxatdan o‘tish tarmog‘ini bajarishda davom etadi. Ushbu maqolada mazkur arxitekturani tanlash sabablari, amalga oshirish vaqtida duch kelgan muammolar va bridge’ni oddiy postMessage emas, kichik protokol sifatida ko‘rib chiqish tajribamiz bayon qilinadi.

2. Nega WebView OAuth’dan avvalgidek foydalanishda davom eta olmadik

Veb OAuth’da foydalanuvchi login tugmasini bosganda, u Provider’ning authorization endpoint’iga yo‘naltiriladi va autentifikatsiya tugagach, ro‘yxatdan o‘tkazilgan redirect URI’ga qaytadi. Bu oqim odatiy brauzerda tabiiy ko‘rinadi, ammo autentifikatsiya provayderi nuqtayi nazaridan native ilovaning WebView’i ichki user-agent hisoblanadi. Ayniqsa Google o‘z siyosatida ishlab chiquvchilar OAuth so‘rovlarini o‘zlari boshqaradigan ichki user-agent orqali yubormasliklari kerakligini aniq bildiradi. Shuning uchun vebda muvaffaqiyatli ishlagan URL’lar va Client ID o‘zgartirilmasdan ishlatilsa ham, ular mobil WebView’da bloklanishi mumkin.

Dastlab xato ekrani Google OAuth konfiguratsiyasi yoki kaliti noto‘g‘ri ekanini ko‘rsatgandek tuyuldi. Biroq ayni konfiguratsiya desktop brauzerida muvaffaqiyatli ishladi, Kakao esa WebView’da ham ishladi. Har bir Provider’ning ruxsat berilgan ro‘yxat siyosati turlicha ekanini ajratib ko‘rsatishimiz kerak edi. Bitta Provider bilan muvaffaqiyatga erishish butun ijtimoiy login arxitekturasi to‘g‘ri ekanini anglatmasdi.

Biz uchta variantni ko‘rib chiqdik.

• WebView OAuth’ni saqlab qolish: bu veb kodidan eng ko‘p qayta foydalanish imkonini beradi, ammo Google siyosatiga javob bera olmaydi.

• Tashqi tizim brauzeri va deep linklardan foydalanish: bu standartga yaqinroq, ammo ilovaga qaytishni boshqarish, callback holati va veb sessiya integratsiyasini yangidan loyihalashni talab qiladi.

• Provider native SDK + mavjud veb callback’dan qayta foydalanish: faqat autentifikatsiya interfeysi native qismga ko‘chiriladi, Gate’dan keyingi mantiq esa vebda qoladi.

Class Leader Note uchinchi yondashuvni tanladi. Google, Kakao va Apple login siyosatlari, Gate uchinchi tomon tekshirish API’i hamda ro‘yxatdan o‘tish tarmog‘i allaqachon vebda amalga oshirilgan edi. Muhim jihat native SDK’dan olingan credential’ni mavjud veb callback tushuna oladigan shaklda uzatishdan iborat edi.

3. Mas’uliyatlarni RN-Bridge-React orqali ajratish

Dizayn tamoyili quyidagicha edi: “Faqat native tomonda bajarish mumkin bo‘lgan narsalarnigina React Native’ga ko‘chirish.” RN Provider SDK’ini ishga tushirish, platformaga xos konfiguratsiya va SecureStore’da saqlashni boshqaradi. Mavjud React ilovasi a’zo mavjud yoki mavjud emasligini aniqlash, Gate credential tekshiruvi, SSO login va yangi foydalanuvchini ro‘yxatdan o‘tkazish ekraniga o‘tishni bajaradi. Bridge ikki sohani bog‘laydi, biroq ularning hech biridagi domen mantiqining o‘rnini bosmaydi.

[1-rasm. React Native-Bridge-React-Gate orqali ijtimoiy autentifikatsiya oqimi]

RN ilovasi uch bosqichda ishlaydi: ishga tushirish, native-login va web. Ilova ishga tushganda SecureStore’dagi access token va tanlangan rolni tekshiradi. Ikkalasi ham mavjud bo‘lsa, WebView darhol ochiladi; ulardan biri to‘liq bo‘lmasa, saqlangan qiymatlar tozalanadi va native login ekrani ko‘rsatiladi. Autentifikatsiya muvaffaqiyatli yakunlangach, natija pending holatda saqlanadi va WebView bosqichiga o‘tiladi.

Veb ilovasi WebView ichida tayyorlanishni tugatgach, WEB_APP_READY yuboradi. RN credential’ni faqat shu signalni olgandan keyin yetkazadi. React natijani tekshiradi, uni vaqtincha sessionStorage’da saqlaydi va mavjud /oauth/callback/:provider yo‘liga o‘tadi. Shundan so‘ng Gate siyosatini qidirish va foydalanuvchini tasdiqlash brauzerdagi OAuth callback bilan bir xil tarzda bajariladi.

Ushbu arxitekturadagi muhim jihat shuki, RN CitizenUser mavjudligini yoki ro‘yxatdan o‘tish kerakligini aniqlamaydi. Native SDK faqat Provider autentifikatsiyasi natijasini hosil qiladi. Gate credential’ni tekshirgach, hisob allaqachon ro‘yxatdan o‘tgan bo‘lsa SSO login’ni bajaradi; aks holda foydalanuvchini registrationToken mavjud bo‘lgan ro‘yxatdan o‘tish oqimiga yo‘naltiradi. Platforma o‘zgargan taqdirda ham, xizmat qoidalari bitta joyda qoladi.

4. React Native’ni Provider autentifikatsiyasiga yo‘naltirish

RN login ekrani ochilganda, avvalo Gate’ning umumiy login siyosatini oladi. Client ID va grantType’ni ilovada qattiq kodlash o‘rniga, tugmalarni faol Provider va mijoz siyosati asosida sozlaymiz. Gate konfiguratsiyasiga ko‘ra, Google hozirda web client profilidan foydalanadi, Kakao va Apple esa app client profilini ustuvor qo‘yadi. clientSecret kabi faqat serverga tegishli maydonlar siyosat javobidan RN modeliga ko‘chirilmaydi.

SDK javoblari Provider’ga qarab farq qiladi. Google access token, ID token, server authorization code va foydalanuvchi profilini taqdim etishi mumkin. Kakao access token yoki ID token’dan foydalanadi; profilni olish muvaffaqiyatsiz bo‘lsa ham, login’ni darhol to‘xtatmaymiz, chunki Gate Provider tokenini qayta tekshirishi mumkin. Apple ID token yoki authorization code’dan foydalanadi, biz esa javob bilan birga state va nonce’ni yaratib, tekshirdik.

Agar bu farqlar chaqiruvchi kodgacha ochib berilsa, RN login ekrani Provider’ga xos shartlar bilan murakkablashadi. Shu sababli har bir SDK adapteri umumiy natija obyektini yaratadi, yuqori darajadagi oqim esa faqat Gate siyosatidagi providerCode va grantType’ni tekshiradi.

type NativeSocialAuthResultPayload = {
  requestId: string;
  providerCode: 'google' | 'kakao' | 'apple';
  credentials: { accessToken?: string; idToken?: string; authorizationCode?: string };
  profile?: { userId?: string; email?: string; displayName?: string };
  parameters?: Record<string, string>;
  issuedAt: number;
};

SDK qiymat qaytarganini darhol muvaffaqiyat isboti deb qaramadik. Agar Gate siyosati AccessToken’ni talab qilsa, SDK natijasida esa faqat ID token bo‘lsa, keyingi bosqich muvaffaqiyatsiz tugashi ehtimoli yuqori. Shuning uchun RN avval grantType haqiqiy credential turiga mos kelishini tekshiradi. Bekor qilish xatolardan ajratiladi; foydalanuvchi login oynasini yopganda, muvaffaqiyatsizlik Snackbar’ini ko‘rsatish o‘rniga dastlabki login ekrani saqlanib qoladi.

5. Bridge’ni postMessage emas, shartnoma sifatida ko‘rib chiqish

React Native WebView’ning aloqa funksiyasi asosan bitta satr yuboradigan postMessage’dan iborat. Faqat satrlarni yuborish va qabul qilishni amalga oshirish tez, ammo action nomidagi xatolar yoki payload o‘zgarishlari faqat runtime vaqtida aniqlanadi. Bir nechta bosqich va maxfiy ma’lumotlarni o‘z ichiga olgan funksiya uchun oddiy satrli aloqadan ko‘ra yo‘nalishlari va turlari aniq belgilangan shartnoma kerak edi.

Umumiy bridge paketida RN→WebView va WebView→RN event map’larini ajratdik. NATIVE_SOCIAL_AUTH_RESULT — RN autentifikatsiya natijasini yetkazadigan event, NATIVE_SOCIAL_AUTH_RESULT_RECEIVED esa veb natijani qabul qilganini bildiruvchi ACK hisoblanadi. REQUEST_NATIVE_LOGIN veb login ekrani native ekranni qayta so‘raganda ishlatiladi. Har bir action auth, session yoki lifecycle kabi funksiyaga tasniflanadi va messageId, correlationId hamda sentAt kabi metama’lumotlarni o‘z ichiga oladi.

interface AuthReactNativeToWebViewEventMap {
  NATIVE_SOCIAL_AUTH_RESULT: NativeSocialAuthResultPayload;
}

interface AuthWebViewToReactNativeEventMap {
  NATIVE_SOCIAL_AUTH_RESULT_RECEIVED: { requestId: string };
  REQUEST_NATIVE_LOGIN: void;
  WEB_AUTH_LOG: WebAuthLogPayload;
}

Faqat turlarning mavjudligi runtime kiritmalarini xavfsiz qilmaydi. WebView’dan olingan satrlarning maksimal hajmini chekladik, ularni JSON sifatida ajratdik va action’ga ruxsat berilganini, shuningdek payload maydonlarining turi va uzunligini tekshirdik. Noma’lum action’lar va haddan tashqari uzun xabarlar qayta ishlanmaydi. Shuningdek, vebdan olingan credential’larni ham tekshiramiz: providerCode, issuedAt, credential uzunligi, profile uzunligi hamda parametrlar soni va hajmini nazorat qilamiz.

Loglar ham alohida chegara talab qildi. Muammolarni bartaraf etish uchun butun payload chop etilsa, access token, ID token, elektron pochta manzillari va foydalanuvchi ID’lari ishlab chiqish loglarida qolib ketishi mumkin. Bridge logger maxfiy qiymatlarni kalit nomlari asosida REDACTED bilan almashtiradi va haqiqiy qiymatlar o‘rniga hasAccessToken hamda hasIdToken kabi maydonlar orqali faqat ularning mavjudligini qayd etadi.

6. READY-Retry-ACK orqali yetkazib berishdagi yo‘qotishlarni kamaytirish

Agar native autentifikatsiyadan so‘ng WebView darhol ochilib, natija ham darhol yuborilsa, xabar React listener’i ro‘yxatdan o‘tkazilishidan oldin yetib kelishi mumkin. Hatto bir xil qurilmada ham bu muammo tarmoq tezligi va veb bundle’ni yuklash vaqtiga qarab ba’zan yuz berishi, ba’zan esa takrorlanmasligi mumkin. Dastlab tugma bosilganda hech narsa sodir bo‘lmagandek ko‘rindi va veb Snackbar’i ham chiqmasdi, shu sababli jarayon qayerda to‘xtaganini aniqlash qiyin edi.

Buni hal qilish uchun WebView tayyorligi va credential yetkazilishini aniq handshake’ga aylantirdik. React listener’ni ro‘yxatdan o‘tkazgach, WEB_APP_READY yuboradi, RN esa ready holatiga kirishi bilan NATIVE_SOCIAL_AUTH_RESULT’ni yuboradi. Veb natijani muvaffaqiyatli saqlagach, darhol NATIVE_SOCIAL_AUTH_RESULT_RECEIVED’ni qaytaradi. RN pending natijani faqat ayni requestId uchun ACK olgandan keyin o‘chiradi.

WEB_APP_READY
  -> NATIVE_SOCIAL_AUTH_RESULT(requestId)
  -> NATIVE_SOCIAL_AUTH_RESULT_RECEIVED(requestId)

Agar ACK kelmasa, RN natijani ikki soniyalik oraliqlarda ko‘pi bilan uch marta qayta yuboradi. Veb requestId orqali allaqachon qayta ishlangan so‘rovlarni aniqlaydi va takroriy callback navigatsiyasining oldini oladi. Agar WebView tayyorlanishi belgilangan muddat ichida tugamasa yoki uchala urinishda ham ACK olinmasa, ilova aniq xato ekraniga o‘tadi. Bu to‘liq xabar navbati emas, ammo WebView lifecycle’i va listener’ni ro‘yxatdan o‘tkazish vaqtidagi farqlar sababli yuzaga keladigan vaqtinchalik yo‘qotishlarni samarali kamaytiradi.

Qayta urinishlarni qo‘shishda idempotentlikni ham hisobga olishimiz kerak edi. Bir xil credential bir necha marta kelishi mumkinligi sababli, veb uni requestId asosida sessionStorage’da bir marta saqlaydi va callback’da o‘qigandan so‘ng darhol o‘chiradi. RN ham jarayonni faqat joriy pending requestId ACK’dagi requestId bilan mos kelganda yakunlangan deb belgilaydi. Qayta urinishlar yetkazib berish ishonchliligini oshiradi, ammo takroriy qayta ishlashning oldi olinmasa, login so‘rovini bir necha marta bajarishi mumkin.

7. React’da mavjud Gate autentifikatsiya oqimidan qayta foydalanish

React NATIVE_SOCIAL_AUTH_RESULT’ni qabul qilganda, payload’ni URL query ichida to‘g‘ridan-to‘g‘ri va to‘liq ko‘rsatmaydi. Avval tekshirilgan natijani requestId asosidagi sessionStorage’da saqlaydi va callback URL’iga faqat native_request_id’ni uzatadi. Callback ekrani qiymatni bir marta ishlatadi va uni URLSearchParams orqali o‘zgartiradi. access_token, id_token va authorization code orasidan Gate siyosatidagi grantType’ga mos credential’ni tanlaydi.

Keyingi oqim mavjud veb OAuth bilan bir xil. U Pavilion va Provider siyosatlarini oladi hamda useThirdPartyOAuth orqali Gate’dan credential tekshiruvini so‘raydi. Gate javobi CitizenUser mavjudligini ko‘rsatsa, shifrlangan foydalanuvchi identifikatori yordamida SSO login’ni bajaradi. Bunday foydalanuvchi mavjud bo‘lmasa, registrationToken, email va name’ni ro‘yxatdan o‘tish holatida saqlaydi va shartlarga rozilik berish hamda qo‘shimcha ma’lumot kiritish bosqichlariga o‘tadi.

Bu ajratish shunchaki mavjud funksiyalardan qayta foydalanishdan ko‘proq narsani anglatadi. Takroriy CitizenUser’larni aniqlash, Provider hisoblarini xizmat hisoblari bilan bog‘lash qoidalari va yangi foydalanuvchini ro‘yxatdan o‘tkazish tarmog‘i allaqachon Gate va React oqimida mavjud. Agar ayni qarorlar RN’da ham amalga oshirilsa, veb va ilova turli qoidalar asosida rivojlanishi mumkin edi. Chegarani shunday saqladik: native qism “Provider orqali kim muvaffaqiyatli autentifikatsiyadan o‘tdi” degan ma’lumotni yetkazadi, xizmat qismi esa “ushbu foydalanuvchini xizmatimizda qanday boshqarish kerak”ligini hal qiladi.

Callback so‘rov native tarzda kelgan-kelmaganiga qarab clientType va redirectUriType’ni ajratadi. Joriy amalga oshirishda Google native SDK web client ID’dan foydalanadi, shuning uchun clientType web sifatida uzatiladi, Kakao va Apple esa app sifatida uzatiladi. Buni faqat Provider SDK turiga qarab belgilab bo‘lmaydi; u Gate POLISH siyosatidagi client profili va grantType bilan moslashtirilishi kerak.

8. Sessiyani sinxronlashtirish va saqlash muddati

Provider credential tekshiruvi va xizmatga login muvaffaqiyatli yakunlangach, veb access token, tanlangan rol va loginProvider’ni RN bilan sinxronlashtiradi. RN ularni avtomatik login siyosatiga muvofiq expo-secure-store’da saqlaydi. Ilova qayta ishga tushganda, token va rolning ikkalasi ham mavjud bo‘lsa, WebView bosqichini tiklaydi; faqat bittasi qolgan bo‘lsa, sessiyani to‘liq emas deb hisoblaydi va uni tozalaydi.

Bu yerda Provider SDK tokeni bilan xizmat access tokenining vazifalarini ajratdik. Provider tokeni faqat Gate foydalanuvchi shaxsini tekshiradigan qisqa uzatish jarayonida ishlatiladi. Ilovaning doimiy sessiyasi Gate loginidan keyin beriladigan xizmat access tokeni asosida boshqariladi. Refresh token WebView’ga uzatilmaydi va bridge payload’ida ham belgilanmagan.

loginProvider hisobni boshqarish ekranida foydalanuvchi hozir qanday login qilganini ko‘rsatish uchun ishlatiladigan ma’lumotdir. Veb sessionStorage va RN SecureStore’ning amal qilish muddatlarini joriy access token siyosati bilan moslashtirdik. Logout vaqtida token, rol va loginProvider birgalikda o‘chiriladi, foydalanuvchi esa RN login ekraniga qaytadi. Saqlashni bitta joyga birlashtirish o‘rniga, har bir runtime o‘ziga kerakli qiymatlarga egalik qiladi, holat o‘zgarishlari esa SYNC_USER_CONTEXT va CLEAR_USER_CONTEXT orqali sinxronlashtiriladi.

Apple’da name va email faqat dastlabki rozilik berilgan paytda taqdim etilishi mumkin degan cheklov ham mavjud. Joriy ro‘yxatdan o‘tish oqimi Provider profili va Gate javobidan foydalanadi, ammo foydalanuvchi avval rozilik bergan hisob bilan qayta ro‘yxatdan o‘tishga urinsa, name yoki email bo‘sh bo‘lishi mumkin. Shu sababli production muhitida dastlabki javobni xavfsiz saqlash siyosati va ma’lumot mavjud bo‘lmaganda foydalanuvchidan uni bevosita kiritishni so‘raydigan zaxira oqimi kerak bo‘ladi.

9. Avval ko‘rinmas bo‘lgan mobil xatolarni kuzatiladigan qilish

Veb ishlab chiqishda brauzerning Network yorlig‘i va Console’ini darhol tekshirish mumkin, ammo Expo Development Build yoki jismoniy qurilmadagi WebView’da ayni yondashuv qiyin. Haqiqiy test vaqtida qo‘shimcha ma’lumot tugmasini bosganda keyingi ekranga o‘tilmasligi va Snackbar chiqmasligi bilan bog‘liq muammo ham yuz berdi. Faqat UI’ga qarab, click hodisasi ishlamaganmi, WebView xabari yo‘qolganmi yoki Gate so‘rovi muvaffaqiyatsiz bo‘lganmi — ajratib bo‘lmasdi.

Shu sababli autentifikatsiya oqimidagi asosiy nuqtalarni stage event’lari sifatida qayd etdik. RN’da LOGIN_ATTEMPT_STARTED, SDK_RESULT_RECEIVED, CREDENTIAL_VALIDATED, BRIDGE_AUTH_SENT va BRIDGE_AUTH_RECEIVED’ni qayd etamiz. React POLICY_LOAD_STARTED, GATE_VERIFY_STARTED, SSO_LOGIN_STARTED hamda har biri uchun muvaffaqiyat, xato va timeout event’larini WEB_AUTH_LOG orqali RN console’iga yuboradi. requestId’dan correlationId sifatida foydalanish bitta urinishni native SDK chaqiruvidan Gate tekshiruvigacha kuzatish imkonini beradi.

Loglarda dastlabki credential’ni qayd etmaymiz. Buning o‘rniga sababni tahlil qilish uchun kerak bo‘ladigan grantType, clientType, redirectUriType, hasRegistrationToken va citizenUserExists kabi holatlargina yoziladi. Masalan, SDK ID token qaytarsa, Gate siyosati esa AccessToken’ni talab qilsa, haqiqiy tokenni chop etmasdan, jarayon CREDENTIAL_VALIDATED’dan oldin siyosat mos kelmagani sababli muvaffaqiyatsiz bo‘lganini tasdiqlashimiz mumkin.

Timeout’lar ham sohalar bo‘yicha ajratildi. RN’da Gate siyosatini qidirish, WebView READY’ni kutish, Bridge ACK’ni kutish, shuningdek React’da Gate siyosatini qidirish va credential’ni tekshirish alohida xato nuqtalaridir. Ularni bitta “login muvaffaqiyatsiz bo‘ldi” xabariga birlashtirish foydalanuvchi tajribasini soddaroq ko‘rsatishi mumkin, ammo ishlab chiqish vaqtida sababni topishni qiyinlashtiradi. Ichki loglar bosqichlarni batafsil ajratadi, foydalanuvchi xabarlari esa qayta urinish mumkin bo‘lgan soddalashtirilgan shaklga keltiriladi.

10. Amalga oshirish natijalari va murosalar

Ushbu arxitektura yordamida mavjud React/Gate login oqimini saqlab qolgan holda Google autentifikatsiyasini WebView ichida ishga tushirmasdan amalga oshira oldik. Kakao va Apple ham xuddi shu umumiy payload yordamida ulandi, bu esa yuqori darajadagi login oqimida provayderga xos tarmoqlanishlarni kamaytirdi. Eng katta foyda shundaki, biz RN’da xizmat qoidalarini, masalan, yangi va mavjud a’zolar o‘rtasidagi tarmoqlanishni, rol tanlashni va qo‘shimcha ma’lumot kiritishni takrorlamadik.

• Biz Provider SDK’lari va platforma konfiguratsiyasini RN’da markazlashtirdik, xizmat domeni qoidalarini esa React/Gate’da saqlab qoldik.

• Tiplangan hodisalar xaritasi va runtime guard’lardan foydalanib, xabarlar yozuvidagi xatolar va format xatolarini erta aniqlash imkonini yaratdik.

• READY xabarini qayta yuborish, ACK va requestId asosidagi bir martalik qabul qilish WebView yuklanishi paytidagi noaniqlikni kamaytirdi.

• Maxfiy ma’lumotlarni maskalash va bosqichma-bosqich korrelyatsiya loglari jismoniy qurilmalarda Expo sinovlari paytida diagnostika imkoniyatlarini yaxshiladi.

Boshqa tomondan, bridge endi protokol hisoblanadi, shuning uchun versiyalar mosligini boshqarish kerak. Agar ilova va web turli vaqtlarda deploy qilinsa, tomonlardan biri yangi action’ni tanimasligi mumkin. Payload’ga maydonlar qo‘shilganda, ularni ixtiyoriy qilish yoki ilovaning minimal versiyasini oshirish kerakligini hal qilishimiz lozim. Qayta yuborish va ACK bilan ishlash ham timeout qiymatini o‘zboshimchalik bilan oshirish o‘rniga, o‘lchangan yuklanish va xatolik darajalariga asoslanib sozlanishi kerak.

Bundan tashqari, barcha native SDK’lar va konfiguratsiyalarni faqat Expo Go yordamida tekshirib bo‘lmaydi. GoogleService-Info.plist, URL schemes va iOS entitlements kabi native loyiha konfiguratsiyasini talab qiladigan funksiyalar development build’da tekshirilishi kerak. Muvaffaqiyatli web sinovlari, Expo Go sinovlari va haqiqiy development build sinovlari teng deb qaralsa, yetishmayotgan konfiguratsiya juda kech aniqlanishi mumkin.

11. Xulosa

Dastlabki muammo bitta xatolikdek ko‘ringan edi: “Google Sign-In WebView’da bloklangan.” Biroq uni hal qilish uchun bir nechta jihatni birgalikda loyihalash kerak bo‘ldi: autentifikatsiya UI’sini qayerda ishga tushirish, Provider tokenini qanday shartnoma asosida uzatish, mavjud xizmat login oqimidan qanday qayta foydalanish, WebView yuklanayotgan paytda xabarlar yo‘qolishini qanday boshqarish va jismoniy qurilmalardagi xatolarni qanday kuzatish.

Bu tajriba bizga gibrid ilovada Bridge shunchaki native funksiyalarni chaqirish uchun qulay vosita emasligini, balki ikki runtime o‘rtasidagi API ekanini ko‘rsatdi. API sifatida u aniq yo‘nalishlar va payload’ga ega bo‘lishi, kiruvchi ma’lumotlarni tekshirishi, dublikatlar va timeout’larni boshqarishi hamda maxfiy ma’lumotlarning loglarga yozilishining oldini olishi kerak. Oddiy postMessage sifatida boshlangan aloqa autentifikatsiya bilan ishlay boshlashi bilanoq kichik taqsimlangan tizimga o‘xshash xususiyatlarni oladi.

Har bir ekran va domen mantiqini React Native’ga ko‘chirish har doim ham to‘g‘ri yechim emas. Banjangnote’da Provider autentifikatsiyasi kabi native imkoniyatlarni talab qiladigan qismlarnigina RN’da saqlab, React va Gate’da allaqachon tasdiqlangan a’zolik va sessiya mantiqidan qayta foydalanish orqali o‘zgarishlar va takrorlanish ko‘lamini kamaytirish yondashuvi tanlandi. Autentifikatsiya funksiyalari account linking, deep-link return flows va har bir Provider uchun qo‘shimcha rozilikni qamrab oladigan darajada kengaysa ham, xuddi shu chegarani saqlab qolish muhim.

Kelgusida biz ilova va web uchun bridge schema versiyalarini belgilashni hamda Provider’ga xos muvaffaqiyat, bekor qilish, dublikat hisob va sessiya muddati tugashi ssenariylari bo‘yicha Development Build asosidagi E2E testlarini avtomatlashtirishni rejalashtirmoqdamiz. Shuningdek, Apple’ning dastlabki avtorizatsiya paytida profilni taqdim etishga qo‘ygan cheklovini va operatsion ssenariylarga muvofiq ilovadan tashqaridan qaytish oqimini ham hal qilishimiz kerak. Bu ish web aktivlarini saqlab qolgan holda native autentifikatsiya siyosatlariga rioya qilish uchun haqiqiy xizmat oqimlari doirasida RN, Bridge va React o‘rtasidagi mas’uliyat chegaralarini moslashtirish tajribasi bo‘ldi.

Manbalar

Google for Developers, OAuth 2.0 Policies
https://developers.google.com/identity/protocols/oauth2/policies

IETF, RFC 8252: OAuth 2.0 for Native Apps
https://www.rfc-editor.org/rfc/rfc8252.html

React Native WebView, Communicating between JS and Native
https://github.com/react-native-webview/react-native-webview/blob/master/docs/Guide.md

Expo Documentation, AppleAuthentication
https://docs.expo.dev/versions/latest/sdk/apple-authentication/

Kakao Developers, Kakao Login for Android
https://developers.kakao.com/docs/latest/ko/kakaologin/android

Kakao Developers, Kakao Login for iOS
https://developers.kakao.com/docs/latest/ko/kakaologin/ios

jyyou