هشدار ini_set در PHP؛ چرا غیرفعال کردن کورکورانه درست نیست؟

فرض کنید یک افزونهٔ PHP برای انجام کاری، یک تنظیم مجاز را در زمان اجرا تغییر می‌دهد. ابزار این تغییر می‌تواند ini_set باشد. این تابع مثل اجازهٔ عوض کردن چند گزینهٔ قابل تغییر است؛ کلید همهٔ تنظیمات سرور نیست.

پس اگر گزارش امنیت فقط نام این تابع را نشان می‌دهد، اول ببینید هدف شما محدود کردن کدام قابلیت است. مثلاً اگر مسئله سقف حافظهٔ یک حساب است، باید تنظیم همان سقف را در محیط اجرای آن حساب کنترل کنید. بستن یک تابع عمومی ممکن است افزونهٔ سالم را خراب کند، بدون اینکه محدودیت موردنظر شما به شکل درست اعمال شده باشد.

برای پیدا کردن خطای واقعی، صفحه یا عملیاتی را که خطا می‌دهد دوباره انجام دهید و گزارش PHP همان سایت را بخوانید. عبارت‌هایی مثل Call to undefined function ini_set() نشان می‌دهند برنامه به تابعی نیاز داشته که در دسترس نیست. متن همین خطا و نسخهٔ PHP سایت را برای میزبان بفرستید. نسخهٔ PHP که در SSH دیده می‌شود ممکن است با نسخهٔ انتخاب‌شده برای سایت شما فرق داشته باشد.

اول نسخهٔ PHP و مدل اجرای آن را پیدا کنید. ممکن است حساب‌های هاست از نسخه‌های مختلف استفاده کنند و هر کدام فایل تنظیم جدا داشته باشند. نتیجهٔ php در خط فرمان نیز لزوماً همان محیطی نیست که وب‌سایت اجرا می‌کند. تغییر فایل CLI ممکن است روی سایت هیچ اثری نداشته باشد.

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

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

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

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

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

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