متابعة لبعض التحقيقات الإضافية والتأكيد من الاستخدام الفعلي.
بعد التعمق أكثر، أعتقد أن هذه بالفعل قيود متصفح داخل التطبيق لنظام iOS (WKWebView) وليست شيئًا خاصًا بـ Discourse أو تكوين Azure.
ما تمكنت من تأكيده
من سجلات nginx + Rails واختبارات المستخدمين:
- تبدأ عملية OAuth أحيانًا داخل متصفح داخل تطبيق iOS (مثل Snapchat).
- يتم تحميل تسجيل دخول Microsoft (login.microsoftonline.com) داخل متصفح التطبيق الداخلي هذا.
- يصل رد نداء OIDC إلى Discourse بنجاح.
- لكن ملف تعريف الارتباط الخاص بالجلسة الذي يحتوي على قيمة الحالة لا يبقى.
- مما يؤدي إلى نتيجة حتمية:
GET /auth/failure?message=csrf_detected&strategy=oidc
يحدث هذا على الرغم من أن المُحيل هو Microsoft وأن عنوان URI لإعادة التوجيه صحيح.
وكيل مستخدم ممثل:
Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X)
Snapchat/13.76.1.0 (like Safari/..., panda)
لذا، على الرغم من أن واجهة المستخدم “تُظهر” Microsoft بشكل جيد، إلا أن المتصفح الأساسي لا يزال متصفح WKWebView الخاص بـ Snapchat، وليس Safari / ASWebAuthenticationSession.
اعتراض مكون السمة لا يعمل
لقد حاولت التخفيف من هذا الأمر من جانب العميل باستخدام مكون سمة:
- اكتشاف وكلاء المستخدمين المعروفين للمتصفح داخل التطبيق.
- حظر روابط /auth/oidc.
- عرض تراكب دائم يوجه المستخدمين إلى الفتح في Safari/Chrome.
ومع ذلك، فإن هذا لا يعترض التدفق بشكل موثوق، لأن:
- يتم بدء إعادة توجيه OAuth من جانب الخادم.
- يجب أن يكون ملف تعريف الارتباط الخاص بالحالة موجودًا بالفعل قبل تشغيل JavaScript العميل.
- بحلول وقت تحميل السمة، يكون الضرر قد وقع بالفعل.
لذا، لا يمكن لمكون السمة منع وضع الفشل هذا بشكل موثوق.
ما يعمل بشكل موثوق
التخفيف الوحيد الذي وجدته ويعمل باستمرار هو تجاوز نص الموقع:
login.omniauth_error.csrf_detected
لشرح صريح بأن:
- فشل تسجيل الدخول بسبب متصفح داخل التطبيق.
- يجب على المستخدمين فتح الموقع في Safari أو Chrome.
- ثم إعادة محاولة تسجيل الدخول.
يتم عرض هذه الرسالة من جانب الخادم بعد الفشل، وبالتالي تظهر حتى في سياقات المتصفح داخل التطبيق المعطلة.
وقد أدى ذلك إلى تقليل ارتباك المستخدم بشكل كبير، حيث كان المستخدمون سابقًا يعودون بصمت إلى صفحة تسجيل الدخول وغالبًا لم يدركوا أن شيئًا قد حدث خطأ.
حول ملفات تعريف الارتباط SameSite
لم أقم بتغيير same_site_cookies إلى “None”.
نظرًا لأن هذه مشكلة عزل WKWebView (بدلاً من التنقل عبر المواقع في Safari)، فإن تغيير SameSite لا يبدو أنه يعالج السبب الجذري وقد يقدم مقايضات أمنية غير ضرورية.
سؤال مفتوح
بالنظر إلى ما سبق، أردت التحقق من صحة ما إذا كان:
- يعتبر هذا السلوك متوقعًا عند بدء تشغيل OAuth من متصفحات iOS داخل التطبيق.
- وما إذا كانت Discourse تنوي دعم هذا التدفق، أو ببساطة توثيق أنه يجب أن يتم تسجيل الدخول من متصفح حقيقي.
قد يكون من المفيد أيضًا لـ Discourse عرض رسالة افتراضية أكثر وضوحًا لـ csrf_detected في سياقات OmniAuth، حيث يبدو أن وضع الفشل هذا شائع بشكل متزايد مع المستخدمين الطلاب الذين يصلون عبر روابط Snapchat / Instagram.
يسعدني تقديم المزيد من السجلات المجهولة إذا كانت مفيدة - ولكن في هذه المرحلة يبدو السلوك متسقًا للغاية وقابلاً للتكرار.
شكرًا لك على إلقاء نظرة.