متابعةً للنقاش من فشل تسجيل الدخول عبر OIDC عبر تطبيق Discourse لنظام iOS أحيانًا مع ظهور csrf_detected عند الاستدعاء:
مرحباً بالجميع،
هذا متابعة للملاحظات المرتبطة بخيطي السابق حول فشل تسجيل الدخول عبر OIDC الذي يتم بدء تشغيله من متصفحات الويب داخل تطبيقات iOS. ركز ذلك النقاش على حالات الفشل الحتمية لـ csrf_detected الناتجة عن عزل ملفات تعريف الارتباط في WKWebView، والتي تبدو الآن مفهومة ومتوقعة بشكل جيد.
الموضوع المرتبط هنا يتعلق بوضوح المشغلين، وليس خطأً.
الملاحظة
أثناء التحقيق في سلسلة من حالات فشل تسجيل الدخول عبر OIDC، لاحظت أن نفس الخطأ الظاهري في Discourse:
/auth/oidc/callback → /auth/failure?message=csrf_detected
يمكن أن يتوافق مع أسباب أصلية متعددة ومختلفة جوهريًا، اعتمادًا على ما أعاده موفر الهوية (IdP).
من واجهة مستخدم التطبيق وحدها، هذه الحالات لا يمكن تمييزها. يظهر الاختلاف فقط من خلال فحص المسؤول ← السجلات ← البيئة / المعلمات.
أمثلة شوهدت عمليًا (Azure / Entra ID)
بالإضافة إلى فقدان ملفات تعريف الارتباط في المتصفح داخل التطبيق، لاحظت استدعاءات يعيد فيها Entra ID صراحةً أخطاءً منظمة مثل:
رفض المستخدم الموافقة
error=consent_required
error_description=AADSTS65004: User declined to consent to access the app
ألغى المستخدم تسجيل الدخول
error=access_denied
error_subcode=cancel
في كلتا الحالتين:
- نجح Azure في تحديد هوية المستخدم
- اختار المستخدم صراحةً عدم المتابعة (رفض / إلغاء)
- يستقبل Discourse الاستدعاء
- يحل التدفق في النهاية إلى
/auth/failure?message=csrf_detected
من منظور Discourse، هذا سلوك صحيح وآمن - لا يمكن التحقق من الحالة أو إكمالها - ولكن السبب الأساسي مختلف تمامًا عن ملف تعريف ارتباط جلسة مفقود.
لماذا يهم هذا المشغلين
بدون فحص بيئة / معلمات السجل، قد يفترض المسؤول الذي يرى فشل csrf_detected المتكرر بشكل معقول:
- ملفات تعريف ارتباط تالفة
- سوء تكوين
SameSite - مشكلات متصفح الهاتف المحمول
- عدم استقرار موفر الهوية (IdP)
… بينما في الواقع، بعض هذه الإخفاقات هي ببساطة اختيار المستخدمين عدم الموافقة أو إلغاء مطالبة Microsoft.
يصبح هذا التمييز واضحًا فقط إذا كنت تعرف بالفعل فحص حمولة السجل الخام.
اقتراح (للتوثيق / تجربة المستخدم فقط)
أنا لا أقترح أي تغيير سلوكي على OmniAuth أو معالجة CSRF.
قد يكون من المفيد إذا أشار التوثيق أو إرشادات استكشاف الأخطاء وإصلاحها صراحةً إلى أن:
- يمكن أن يكون
csrf_detectedهو الخطأ النهائي للعديد من نتائج موفر الهوية الأصلية - بما في ذلك الإجراءات الصريحة للمستخدم مثل الإلغاء أو رفض الموافقة
- ويجب على المسؤولين فحص المسؤول ← السجلات ← البيئة / المعلمات لتمييز هذه الحالات
سيجعل هذا من الأسهل على المشغلين:
- تشخيص فشل تسجيل الدخول بشكل صحيح
- تجنب تغييرات التكوين غير الضرورية
- وتقديم إرشادات دقيقة للمستخدمين (“لقد ألغيت / رفضت الموافقة” مقابل “قام متصفحك بحظر ملفات تعريف الارتباط”).
السياق
للتوضيح: هذا منفصل عن مشكلة متصفح iOS داخل التطبيق المؤكدة التي نوقشت في الموضوع المرتبط. في تلك الحالة، لا يصل موفر الهوية أبدًا إلى نقطة موافقة المستخدم، بينما هنا يبلغ موفر الهوية صراحةً عن نية المستخدم.
كلاهما ينتهي بمظهر متشابه على مستوى واجهة المستخدم ما لم يتم فحص السجلات.
شكراً للقراءة - أنشر هذا بشكل أساسي كوضوح للتوثيق / نقطة بيانات للآخرين الذين يديرون OIDC في بيئات يكثر فيها الطلاب حيث تحدث هذه الحالات بشكل متكرر.
يسعدني تقديم أمثلة مجهولة المصدر إذا كانت مفيدة.