أحاول تشغيل الإشعارات الأصلية لموقع Discourse المستضاف ذاتيًا الخاص بـ TWA وواجهت “فشلًا ناعمًا” غريبًا جدًا في التحقق من صحة Digital Asset Link.
إليك الأعراض الدقيقة:
-
يبدأ التطبيق ويعمل بملء الشاشة بدون شريط عنوان URL، مما يشير إلى أن رابط الأصول يعمل جزئيًا.
-
ومع ذلك، تظهر رسالة “يعمل في Chrome” عند كل تشغيل.
-
والأهم من ذلك، عندما يطلب PWA إذن الإشعارات، فإنه يعرض الموجه بأسلوب المتصفح، وليس مربع حوار Android الأصلي. هذا يثبت أن تفويض واجهة برمجة التطبيقات الأصلية يفشل.
هذا السلوك متسق على جميع أجهزة الاختبار (Android 12 و 13) مع ملفات APK التي تم إنشاؤها بواسطة Bubblewrap و PWABuilder من Microsoft.
بعد تصحيح الأخطاء المكثف، أكدت أن تكوين الخادم الخاص بي بالكامل من جانب العميل والموجه للجمهور يبدو مثاليًا. يبدو أن المشكلة هي مشكلة دقيقة في جانب الخادم تؤثر فقط على مدقق Android.
إليك ما قمت بالتحقق منه بالفعل:
-
مفتاح التوقيع وملف
assetlinks.json: بصمة SHA-256 الخاصة بـandroid.keystoreالخاصة بي هي مطابقة تامة بنسبة 100% مع البصمة الموجودة في ملف/.well-known/assetlinks.jsonالمباشر الخاص بي. -
استجابة الخادم: يقدم خادمي عنوان URL لملف
assetlinks.jsonمع حالة200 OK، وapplication/jsonالصحيح لنوع المحتوىContent-Type، ولا توجد رؤوس CORS مانعة عند التحقق منها باستخدام أدوات الويب القياسية. -
تكوين تطبيق Android: ملف
AndroidManifest.xmlالذي تم إنشاؤه صحيح ويحتوي علىcom.google.browserhelper.trusted.DelegationServiceالقياسي. -
إعدادات مسؤول Discourse: إعدادات الأمان الخاصة بي للمسؤول لـ
cors originsوAllowed crawler user agentsفارغة.
نظرًا لهذا السلوك المحدد “للفشل الناعم”، سؤالي هو:
هل هناك قاعدة Nginx معروفة، أو إعداد جدار حماية، أو مشكلة دقيقة في استجابة الخادم (مثل تأخير طفيف أو رأس غير قياسي) في الإعداد الافتراضي لـ Discourse المستضاف ذاتيًا والتي من شأنها أن تتسبب في منح مدقق Android “ثقة جزئية” (مما يسمح بواجهة المستخدم بملء الشاشة) ولكن رفض المستوى الأعلى من الثقة المطلوب لتفويض واجهة برمجة التطبيقات الأصلية؟
لقد وصلت إلى نهاية ما يمكن تشخيصه من جانب العميل. أي رؤى حول التكوين العميق للخادم ستكون موضع تقدير كبير.