كيفية حل مشكلة تطبيق مستضاف ذاتيًا يستمر في استخدام سرّ قديم

إيفا وونغ

IceWhale author

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

How to Resolve a Self-Hosted App That Keeps Using an Old Secret - Zima Store Online

يستمر التطبيق المستضاف ذاتيًا في استخدام سر قديم عندما لا تكون القيمة التي غيّرتها هي القيمة نفسها التي حمّلها فعليًا التطبيق قيد التشغيل.

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

أثبت أن الحاوية قيد التشغيل لا تزال تحتوي على القيمة القديمة

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

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

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

تتبّع مصدر السر الذي يقرأه التطبيق فعليًا

حدّد كل مصدر محتمل لبيانات الاعتماد: متغير بيئة مضمن في Compose، و.env، وenv_file، وملف مُحمّل، وسر Docker أو Podman، وملف إعدادات التطبيق، وواجهة إدارة الحاويات، وأي معالج إعداد أولي حفظ القيمة في وحدة تخزين دائمة.

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

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

أعِد إنشاء الخدمة عندما يكون السر جزءًا من إعدادات الحاوية

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

يشير مثال لتدوير الأسرار في Podman إلى أن تدوير السر يُحدّث الخدمات بعد استبدال السر، ما يجعل دورة حياة الحاوية خطوة منفصلة عن تحديث مخزن الأسرار.

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

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

تحقق من وجود إعدادات دائمة للتطبيق تتجاوز البيئة

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

تتجاوز الإعدادات الدائمة متغيرات البيئة إلى أن تغيّر الإعداد الدائم أو تعطل هذا السلوك عمدًا.

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

تحقق مما إذا كان التطبيق يحمّل ملف سر بدلًا من ذلك

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

يوضح أحد أمثلة تثبيت Open WebUI أن التطبيق يحمّل ملف سر محفوظًا في عمليات التشغيل اللاحقة، ما يوضح سبب ضرورة التحقق من مسار الملف الفعلي بشكل مستقل عن ملف YAML الخاص بـ Compose.

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

دوّر المستهلك والمزوّد كمعاملة واحدة

لكلمة مرور قاعدة البيانات أو رمز API أو بيانات اعتماد الخدمة جانبان: التطبيق الذي يقدّمها والمزوّد الذي يتحقق منها. يؤدي تحديث جانب واحد فقط إلى فشل في المصادقة قد يُفهم خطأً على أنه احتفاظ التطبيق بقيمة قديمة في ذاكرته المؤقتة.

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

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