خادم Access يتجاهل سكربت post_auth الذي عدّلته على القرص

سكربت mac.py المعدّل الذي لا يغيّر شيئًا هو العرَض الأول المعتاد. الملف الموجود على القرص ليس ما ينفّذه خادم Access؛ فخدمة المصادقة تحمّل السكربت من قاعدة بيانات إعدادات الخادم، وتلك النسخة المخزّنة هي التي تحدد تسجيل الدخول. وإلى أن تُستبدل القيمة المخزّنة، فإن كل اختبار تجريه يثبت فقط أن السكربت القديم ما زال يعمل.

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

الملف مصدر وليس النسخة العاملة

يحتفظ خادم Access بسكربت post-auth تحت المفتاح auth.module.post_auth_script. تعديل الملف يحدّث نسختك العاملة ولا شيء غيرها. تقرأ الخدمة القيمة المخزّنة، فيبقى التعديل غير مرئي حتى تحذف الإدخال القديم وتضع الملف الجديد مكانه. تلك القيمة المخزّنة هي النسخة الوحيدة التي تراجعها خدمة المصادقة.

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

./sacli -k auth.module.post_auth_script ConfigGet

استبدل النسخة المخزّنة ثم طبّقها

الحذف قبل الكتابة ليس زينة. ConfigPut مع --value_file يستبدل القيمة في خطوة واحدة، وConfigDel أولًا يجعل من المستحيل ترك إدخال قديم أو تالف. احتفظ بنسخة من السكربت العامل خارج مجلد السكربتات قبل أن تبدأ.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

sacli start يطبّق الإعداد المتغيّر على الخدمات الداخلية، وهذا ما يجعل السكربت الجديد يسري. وهو ليس مثل إعادة تشغيل الجهاز كله أو الخدمة، ولا ينبغي أن يُستبدل بها إلا إذا كان التغيير الذي تجريه يتطلب ذلك.

استخدم مسارًا مطلقًا لملف القيمة وتأكد من أن root يستطيع قراءته. المسار الذي يُحلّ من صدفة لديك ولا يُحلّ من حساب الخدمة ينتج قيمة مخزّنة تبدو سليمة في ConfigGet وتفشل عند أول تسجيل دخول. تحقق من النتيجة المخزّنة مرة أخرى بعد sacli start لا قبله.

نطاق الوحدة أم لكل اتصال: أين يقع الاستعلام

يشغّل Python عبارات مستوى الوحدة مرة واحدة عند تحميل السكربت. لذلك يقرأ استعلام قاعدة بيانات مكتوب في أعلى الملف الجدول وقت التحميل ويحتفظ بتلك الإجابة لكل اتصال لاحق. هذا هو السبب الثاني لظهور التعديل كأنه لا يفعل شيئًا: الكود يعمل لكن ليس في الوقت الذي تتوقعه.

ضع الاستعلام داخل معالج post_auth ليعمل مع كل مصادقة. حافظ على التوقيع الموثّق، وعدّل نتيجة المصادقة التي يتلقاها المعالج، وأعد الكائن نفسه لا رقمًا مجرّدًا.

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

مسارا رفض ومالك واحد

إذا كان القرار استعلامًا محليًا فمعالج Python يملك النتيجة. وإذا كان فحصًا خارجيًا عبر HTTP فدع حالة خروج الأمر تحمل الجواب: غلاف يخرج بقيمة غير صفرية يرفض تسجيل الدخول، وتصبح حالة الأمر الأخير حالة السكربت دون exit صريح.

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

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

طبّقه دون إقفال حساب المسؤول

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

شرطان يقولان انتظر: ألا تستطيع قراءة ملف القيمة بصلاحية root، أو ألا تملك طريقًا ثانيًا إلى واجهة الإدارة. كلاهما يحوّل تغييرًا صغيرًا إلى إقفال، ولا يستحق أي منهما الاختبار على خادم إنتاج في نهاية اليوم. توثيق خادم Access يغطي واجهة post-auth وحقولها المدعومة.