403s المتقطع بسبب فشل CSRF (Django 1.2.3)

Question

لقد حصلت على خطأ مجنون/غاضب قليلاً مع موقع و CSRF.

نحن نقوم بتشغيل Django 1.2.3 ، Python 2.6 على Ubuntu مع Apache2 + mod_wsgi ونحصلوا على المستخدمين النهائيين الذين يبلغون عن فشل التحقق من 403 CRSF و 403S نتيجة لذلك.

جميع أشكالنا لها ملف csrf_token - وبقدر ما أدرك - تعمل الأمور بشكل جيد في Dev المحلي وعلى المسرح (لسنا في الإنتاج بعد) ... بصرف النظر عن مكتب واحد (العميل ، Natch). في المناسبات العشوائية ، سيحصلون على مثل هذا 403 ، ولكن بعد ذلك سوف يختفي (لذلك ليس HTML يفتقر إلى رمز الرمز الرمزي وما إلى ذلك)

أنا أفكر في الأسباب والحلول ، وقد يكون هذا المكتب لديه ذاكرة التخزين المؤقت الوكيل بشكل مفرط أو سيئ الإعداد ، أو ما شابه ذلك ، وسوف نقدر بعض النصائح حول ما يمكننا القيام به ، بطريقة Django/Apache إلى تعامل مع الوكلاء فوق القمة (من المحتمل ألا يغير مكتب العميل إعدادهم) أو ما الذي قد يكون الأمر كذلك لسبب فشل هذه المسؤولية الاجتماعية للشركات.

راجع للشغل: كان هذا مشروع 1.2.3 من نقطة الصفر ، وليس نوعًا من الترقية 1.1 ، ونحن نستخدم فقط قياسي واحد/صحيح 1.2.3 csrfmiddlewar

أيضًا: لقد حدث هذا على خادمين منفصلين (خادم DEV وخادم التدريج) ، يتم استضافته في مواقع منفصلة. العوامل الشائعة هي (من الناحية النظرية) نفس إعداد Django/Apache/mod_wsgi ، نفس قاعدة الكود ونفس المكتب الحصول على 403s (وعدم القدرة على تكرار 403s في موقعنا).

Answer 1

مجرد تحديث في حال يساعد أي شخص.

لقد أسقطنا حماية CRSF للاختبار (باستخدام http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/). قام هذا بمسح 403s ، ولكن بعد ذلك كان لدينا 500s متقطع لبيانات النشر بطول صفرية من نفس العميل/الشبكة المحلية ، والتي أوضحت أن CSRF كان لأن الرمز المميز كان موجودًا في الجلسة ولكن ليس في الحمولة الصافية (بدلاً من طريقة بديلة).

لذلك ، لم تكن مشكلة CSRF ، على وجه التحديد ، ولكن مشكلة ما بعد التحميل-Zapped-Lyperhere. (على الأرجح من خلال وكيل خاطئ في مكان واحد فقط)

HTH

ستيف