سرور 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 بررسی کنید، نه پیش از آن.

دامنهٔ ماژول یا هر اتصال: پرس‌وجو کجا باید باشد

پایتون دستورهای سطح ماژول را یک بار، هنگام بارگذاری اسکریپت اجرا می‌کند. بنابراین پرس‌وجوی پایگاه داده‌ای که در بالای فایل نوشته شده، جدول را در زمان بارگذاری می‌خواند و همان پاسخ را برای هر اتصال بعدی نگه می‌دارد. این دومین دلیلی است که یک ویرایش بی‌اثر به نظر می‌رسد: کد اجرا می‌شود، اما نه وقتی که انتظار دارید.

پرس‌وجو را داخل گردانندهٔ post_auth بگذارید تا برای هر احراز هویت اجرا شود. امضای مستندشده را حفظ کنید، نتیجهٔ احراز هویتی را که گرداننده دریافت می‌کند تنظیم کنید و به‌جای یک عدد خالی همان شیء را بازگردانید.

مدیریت اتصال را هم داخل گرداننده نگه دارید. اتصالی که هنگام واردسازی باز می‌شود ممکن است پیش از ورود نخستین کاربر توسط سرور بسته شود و خطای حاصل مانند اعتبارنامهٔ ردشده به نظر برسد، نه اسکریپت خراب.

دو مسیر رد، یک مالک

اگر تصمیم یک پرس‌وجوی محلی است، گردانندهٔ پایتون مالک نتیجه است. اگر یک بررسی خارجی HTTP است، بگذارید وضعیت خروج فرمان پاسخ را حمل کند: پوششی که با کد غیرصفر خارج می‌شود ورود را رد می‌کند و وضعیت آخرین فرمان بدون exit صریح به وضعیت اسکریپت تبدیل می‌شود.

راز را بیرون از فهرست فرایندها نگه دارید. فایلی که root می‌خواند یا مقدار محیطی که سرویس می‌فرستد، از آرگومانی که هر کاربر محلی می‌تواند از ps بخواند ایمن‌تر است. پیش از فراخوانی، نقطهٔ پایانی را در یک متغیر تثبیت کنید تا یک غلط تایپی در زمان پیکربندی شکست بخورد، نه در میانهٔ ورود کسی. آن راز را مانند هر اعتبارنامهٔ دیگری دوره‌ای عوض کنید.

برای هر بررسی یک مالک انتخاب کنید. اسکریپتی که هم پایگاه داده را می‌پرسد و هم سرویس HTTP را صدا می‌زند، برای حالتی که این دو اختلاف دارند به قاعدهٔ اولویت اعلام‌شده نیاز دارد، وگرنه دلیل رد در گزارش با آنچه به کاربر گفته شده همخوان نخواهد بود.

آن را بدون قفل‌شدن مدیر اعمال کنید

دو پادزهر تغییر را بازگشت‌پذیر می‌کند: حساب مدیر دومی که به اسکریپت وابسته نیست، و نسخهٔ سالم شناخته‌شده‌ای که بیرون از پوشهٔ اسکریپت‌ها نگه داشته می‌شود. تغییر را در پنجرهٔ نگهداری اعمال کنید، سپس پیش از قطع اتصال یک ورود آزمایشی و یک رد عمدی را ببینید. اگر گزارش به‌جای تصمیم احراز هویت خطای نحوی نشان دهد، اسکریپت ذخیره‌شده خراب است و هر ورودی شکست می‌خورد.

دو شرط می‌گویند صبر کنید: نمی‌توانید فایل مقدار را به‌عنوان root بخوانید، یا راه دومی به رابط مدیریت ندارید. هر دو تغییری کوچک را به قفل‌شدن تبدیل می‌کنند و هیچ‌کدام ارزش آزمایش روی سرور تولیدی در پایان روز را ندارند. مستندات سرور Access رابط post-auth و فیلدهای پشتیبانی‌شدهٔ آن را پوشش می‌دهد.