لماذا يؤدي إعادة تشغيل وكيل عكسي إلى إبطال كل جلسة في تطبيق مستضاف ذاتيًا واحد؟

إيفا وونغ

IceWhale author

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?

لا تؤدي إعادة تشغيل الوكيل العكسي إلى تسجيل خروج جميع المستخدمين إلا عندما تغيّر حالة الجلسة التي يستخدمها التطبيق أو تفقدها أو تعيد توجيهها.

عادةً ما يمرر الوكيل الأساسي ملفات تعريف الارتباط بدلاً من امتلاك جلسة التطبيق، لذلك لا ينبغي أن تؤدي إعادة تشغيل الوكيل وحدها إلى إبطال جميع عمليات تسجيل الدخول. قد يكون العامل الحقيقي هو إعادة تشغيل بوابة المصادقة، أو إعادة إنشاء سر توقيع ملفات تعريف الارتباط، أو ذاكرة تخزين مؤقت للجلسات داخل الذاكرة، أو تغيير نسخة خلفية، أو تبعية في Compose تؤدي إلى إعادة تشغيل التطبيق مع الوكيل. حدّد المكوّن الذي أصدر الجلسة ويتحقق منها قبل تغيير سمات ملفات تعريف الارتباط أو إجبار المستخدمين على تسجيل الدخول مجدداً.

تأكّد من الخدمات التي أُعيد تشغيلها مع الوكيل

سجّل معرّفات الحاويات، وأوقات البدء، وعدد مرات إعادة التشغيل، وأحداث السلامة، والسجلات الخاصة بالوكيل العكسي، وخدمة المصادقة، والتطبيق، وذاكرة التخزين المؤقت، وقاعدة البيانات قبل إعادة تشغيل الوكيل مرة واحدة بصورة مضبوطة وبعدها.

يمكن لـ Docker Compose إعادة تشغيل الخدمات التابعة عندما تُضبط التبعية صراحةً لنشر إعادة التشغيل. توضّح إرشادات ترتيب البدء الرسمية سبب احتمال أن يستبدل أمر موصوف بأنه إعادة تشغيل للوكيل حاوية المصادقة أو التطبيق أو يعيد تشغيلها أيضاً.

إذا كان الوكيل وحده قد حصل على وقت بدء جديد، فركّز على المصادقة وإعادة التوجيه وملفات تعريف الارتباط التي يديرها الوكيل. أما إذا أُعيد تشغيل التطبيق أو ذاكرة التخزين المؤقت أو بوابة المصادقة أيضاً، فتحقّق أولاً من استمرارية الجلسات والأسرار الخاصة بها.

حدّد الطبقة التي أصدرت ملف تعريف ارتباط تسجيل الدخول

قبل إعادة التشغيل، سجّل اسم ملف تعريف الارتباط، والنطاق، والمسار، وسمات Secure وHttpOnly وSameSite، ومدة الانتهاء، وما إذا كان التطبيق أو بوابة المصادقة هو الذي يضبطه.

توضّح MDN أن نطاق ملف تعريف الارتباط وسماته يحددان المكان الذي يرسله إليه المتصفح، لكن هذه السمات لا تكشف أي خادم خلفي يتحقق من قيمته.

قارن رؤوس الاستجابة الخاصة بطلب تسجيل الدخول وأول طلب بعد إعادة التشغيل. يشير غياب ملف تعريف الارتباط إلى مشكلة في نطاق المتصفح؛ أما رفض الخادم لملف تعريف ارتباط لم يتغير فيشير إلى فقدان الحالة أو تغيّر المفاتيح أو استخدام خادم خلفي مختلف.

تحقّق مما إذا كانت بوابة المصادقة قد أعادت إنشاء سر الجلسة

افحص مصدر سر بوابة المصادقة، وتركيب الملف، والبيئة، وإعادة إنشاء الحاوية، والإعدادات المُنشأة. قارن مصدر القيمة قبل إعادة التشغيل وبعدها من دون كشف السر نفسه.

توضّح Authelia أن سر الجلسة يشفّر بيانات الجلسة المخزنة، لذا فإن تغيير هذا السر أو فقدانه يمنع الخدمة من قراءة الجلسات التي أُنشئت سابقاً.

خزّن أسرار الجلسات في ملف أسرار دائم أو في مخزن أسرار مُدار بدلاً من إنشائها عند بدء كل حاوية. أجرِ عملية التدوير عمداً مع توثيق فترة تسجيل الخروج.

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

استبعد استخدام مخزن جلسات داخل الذاكرة

حدّد ما إذا كان التطبيق يخزّن الجلسات في ذاكرة العملية، أو في ذاكرة تخزين مؤقت محلية، أو Redis، أو قاعدة بيانات، أو ملفات تعريف ارتباط موقّعة من جهة العميل. قارن مدة تشغيل عملية مخزن الجلسات بوقت حدوث تسجيل الخروج.

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

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

قارن مفاتيح توقيع التطبيق بين عمليات إعادة التشغيل

افحص مصدر مفتاح توقيع الجلسات أو تشفيرها في التطبيق، وحدّد ما إذا كان المفتاح محفوظاً، أو محمّلاً من ملف البيئة المتوقع، أو مُنشأ عند بدء التشغيل.

تستخدم Flask SECRET_KEY لتوقيع ملفات تعريف ارتباط الجلسات، لذا فإن استبدال هذا المفتاح يجعل ملفات تعريف الارتباط الموقّعة الحالية غير صالحة حتى لو استمر المتصفح في إرسالها.

لا تحاول حل المشكلة بمشاركة سر واحد بين تطبيقات غير مرتبطة. امنح كل تطبيق سراً ثابتاً، واحمه باعتباره إعداداً بالغ الأهمية للنسخ الاحتياطي، وتحقّق من بقائه بعد إعادة إنشاء الصورة.

تحقّق من الجلسات الثابتة وتغيّر النسخ الخلفية

أدرج النسخ الخلفية، ومخازن جلساتها، وسياسة موازنة الحمل في الوكيل. اختبر بقاء المستخدم نفسه مسجلاً للدخول عندما تصل الطلبات إلى نسخة خلفية أخرى.

توجّه إعدادات الجلسات الثابتة في Traefik العميلَ مجدداً إلى خادم خلفي واحد، لكن قد يفقد المستخدمون جلساتهم إذا لم تشارك النسخ الخلفية الحالة، وأدت إعادة التشغيل إلى تغيير نقطة النهاية المحددة.

قد تخفي الجلسات الثابتة وجود مخزن جلسات محلي غير صحيح. فضّل استخدام حالة جلسات مشتركة ودائمة عندما يُفترض أن تستمر عدة نسخ من التطبيق بعد استبدال الوكيل أو الخادم الخلفي.

أعد إنتاج المشكلة باستخدام حساب اختباري واحد وإعداد ثابت

احفظ لقطة من الإعدادات، وسجّل الدخول باستخدام حساب واحد مخصص للاختبار، وسجّل معرّفات الجلسة، وأعد تشغيل الوكيل فقط، ثم اختبر الطلب نفسه قبل إعادة تشغيل أي مكوّن آخر.

تتناول مقالة ZimaSpace حول حلقات تسجيل الدخول خارج الشبكة المنزلية فقط حالات فشل تسجيل الدخول المرتبطة بالمسار؛ أما هذه المقالة فتركّز على الإبطال المتزامن للجلسات الصالحة مسبقاً بعد إعادة التشغيل.

تُحل المشكلة عندما تحافظ عمليات إعادة تشغيل الوكيل وحده على الجلسات، وتستخدم عمليات إعادة تشغيل المصادقة أو التطبيق المقصودة أسراراً ثابتة وحالة دائمة، وتقبل كل نسخة خلفية تسجيل الدخول النشط نفسه.

الأسئلة الشائعة

هل يمكن للوكيل العكسي نفسه تخزين جلسات المستخدمين؟

يمكنه ذلك عندما يتضمن بوابة مصادقة أو وسيط وصول أو آلية للجلسات الثابتة. أما وكيل إعادة التوجيه البسيط فعادةً لا يمتلك جلسة تسجيل دخول التطبيق.

هل تؤدي إعادة تشغيل Redis دائماً إلى تسجيل خروج المستخدمين؟

فقط عندما تكون الجلسات موجودة حصراً في Redis ولا تُحفظ بياناتها أو تُستعاد. وتتصرف التطبيقات التي تستخدم جلسات مدعومة بقاعدة بيانات أو ملفات تعريف ارتباط موقّعة بطريقة مختلفة.