سلسلة ملفات تعريف الارتباط في Discourse أعلاه يبلغ طولها 1,962 حرفًا!
للمقارنة، فإن رأس الكوكي المُرسل إلى موقع Mediawiki الخاص بي يبلغ طوله 122 حرفًا فقط، متضمنًا اسم المستخدم ومعرف المستخدم ومعرف الجلسة.
معرف الجلسة في Mediawiki يبلغ طوله 32 حرفًا، لكن Discourse يبدو أنه يحتوي على معرفي جلسة: rack.session يبلغ طوله 813 حرفًا و _forum_session يبلغ طوله 1,075 حرفًا. يرجى مساعدتي في فهم سبب حاجة معرف مستخدم بسيط (uid) لأن يكون بهذه الطول. هل يمكنني تكوين Discourse لاستخدام معرف جلسة أقصر؟ هل مثل هذا الطلب منطقي؟
ما الذي يُخزن في هذه السلسلة؟ هل من الممكن جعلها أصغر؟
على وجه التحديد، لأي مكون من مكونات برنامج Discourse يُستخدم rack.session؟ وماذا يُستخدم _forum_session؟
بالتأكيد يمكنني مجرد رفع حدود تكوين nginx، لكنني أود الحفاظ عليها منخفضة بشكل معقول ما لم يكن هناك شرط قوي لزيادتها.
أنا مؤيد لمراجعة ملفات تعريف ارتباط الجلسة لدينا، وربما الانتقال إلى استخدام افتراضي لجلساتنا المدعومة بـ Redis والتي تنتهي تلقائيًا، وهو أمر أفضل على أي حال. @david، هل لديك أي أفكار في هذا الصدد؟
يعتمد الأمر؛ فالإضافات التي تعتمد بشكل كبير على الجلسات قد تتأثر، كما أن الأمر يتعلق بالنظافة أيضًا، فمن الأفضل الاحتفاظ بكل هذه المعلومات السرية على الخادم بدلاً من تشفيرها على العميل.
يا إلهي، تم هذا الضبط عمدًا لأغراض أمنية؛ إنه ليس “وكيلًا سيئ التكوين”. إن تخفيض القيم التالية في أوامر nginx يُعد إجراءً شائعًا ضمن إجراءات تعزيز أمان nginx (لمعالجة التوافر، وتحديد المعدلات، ومنع هجمات حجب الخدمة، إلخ):
الإعدادات التي نستخدمها في ملف تكوين nginx تعمل بشكل ممتاز على جميع مواقعنا الحالية. المشكلة هنا تبدو وكأنها ناتجة عن أن Discourse يخزن بيانات عميل غير ضرورية في ملف تعريف الارتباط (cookie)، حيث أرى شخصيًا أن الشيء الوحيد الذي يجب تخزينه في ملف تعريف الارتباط هو بضع معرّفات فريدة يمكن للخادم استخدامها للوصول إلى تلك البيانات من جانب الخادم.
شكرًا لك يا سام. هل تقصد بـ “الانتقال إلى استخدام افتراضي لـ Redis” أن من الممكن حاليًا نقل البيانات المخزنة في ملف تعريف ارتباط الجلسة إلى Redis عن طريق تغيير في التكوين؟ أم أن نقل هذه البيانات من ملف تعريف ارتباط الجلسة إلى الخادم سيتطلب حتمًا تغييرًا في الكود؟
ملاحظة: اضطررت أيضًا إلى تجاوز تعليمات large_client_header_buffers في إعدادات nginx المشددة الخاصة بي لكي يعمل Discourse بشكل صحيح.
على وجه التحديد، أستخدم large_client_header_buffers 2 1k في إعدادات nginx لجميع مواقع أخرى. لكن هذا يتسبب في ظهور خطأ 414 Request-URI Too Large من /admin/reports/bulk?XYZ — حيث أن XYZ يتكون فعليًا من 1,019 حرفًا!
تم حل هذه المشكلة عن طريق ضبط large_client_header_buffers 4 8k; في كتلة server{} الخاصة بإعدادات nginx الخاصة بـ Discourse، مما يتجاوز التعليمات العامة ويعيد القيمة الافتراضية لهذه التعليمات لـ Discourse.
تحسينًا للتوافقية بين تثبيتات Discourse عبر خوادم الويب المشددة الشائعة وجدران الحماية الشبكية وجدران حماية تطبيقات الويب، أحث مطوري Discourse على النظر في استخدام طريقة POST لمثل هذه سلاسل الاستعلام الطويلة.
بالنسبة لشخص ليس مهندس الواجهة الخلفية، ما هو الحل لهذه المشكلة؟
نتلقى الكثير من التقارير حول هذا الخطأ على مدار الشهر الماضي في منتدى Webflow. يوصي الزائر بمسح ملفات تعريف الارتباط/الذاكرة المؤقتة أو استخدام وضع التصفح المتخفي، وقد نجح ذلك ولكنه ليس مثاليًا.