خطای 400 در admin-ajax.php وردپرس؛ چه زمانی واقعاً مشکل داریم؟

در ابزار بررسی سایت یا زبانه Network مرورگر، نشانی admin-ajax.php را با پاسخ 400 یا عدد صفر می‌بینید. شاید نگران شوید که بخش مدیریت وردپرس خراب شده است. اما اگر این نشانی را بدون اطلاعات لازم مستقیم در مرورگر باز کرده باشید، دریافت چنین پاسخی در وردپرس عادی می‌تواند اتفاق بیفتد؛ این نشانی به‌تنهایی یک صفحه عادی برای نمایش نیست.

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

بعضی افزونه‌ها و قالب‌های وردپرس برای انجام کاری در پس‌زمینه، درخواستی به admin-ajax.php می‌فرستند. درخواست باید اطلاعاتی داشته باشد که به وردپرس بگوید کدام کار یا action را می‌خواهیم. خود نام فایل به معنی این نیست که هر بازدیدکننده باید به همه عملیات مدیریت دسترسی داشته باشد.

اگر URL فایل را بدون action در نوار مرورگر باز کنید، پاسخ 400 یا صفر می‌تواند با رفتار پیش‌فرض وردپرس سازگار باشد. پس معیار سلامت، باز شدن ظاهری آن نشانی نیست؛ کار واقعی افزونه و پاسخ همان درخواست را بررسی کنید. راهنمای رسمی AJAX وردپرس نقش action در درخواست را توضیح می‌دهد.

برای شروع، یک کار مشخص انتخاب کنید: مثلاً «دکمه ثبت تنظیم در صفحه افزونه واکنش ندارد». نشانی صفحه، نقش حساب، زمان و متن خطا را ثبت کنید. در فروشگاه، عملیات مالی یا ثبت سفارش را صرفاً برای تکرار خطا چند بار اجرا نکنید؛ از محیط و داده آزمایشی استفاده کنید.

در Chrome یا Edge روی صفحه مشکل‌دار، ابزار توسعه‌دهنده را با F12 یا از منوی مرورگر باز کنید. به زبانه Network بروید. اگر ابزار فیلتر Fetch/XHR دارد آن را انتخاب کنید، سپس کار آزمایشی را یک بار انجام دهید. در فهرست درخواست‌ها موردی را پیدا کنید که به admin-ajax.php مربوط است و زمان آن با همان کلیک هم‌خوانی دارد.

روی درخواست بزنید و این موارد را یادداشت کنید:

در Payload، Headers و Response ممکن است رمز، کوکی، nonce، داده مشتری یا توکن وجود داشته باشد. تصویر کامل یا فایل HAR را بدون پاک‌سازی برای دیگران نفرستید. لازم نیست مقدار محرمانه را بدانیم؛ برای شروع کافی است بدانیم فیلد مورد انتظار وجود دارد یا نه.

| نتیجه | معنی احتمالی و اقدام | | --- | --- | | باز کردن مستقیم URL بدون action، پاسخ 400 یا صفر دارد | ممکن است رفتار معمول همان نشانی باشد. یک عملیات واقعی افزونه را آزمایش کنید. | | درخواست واقعی 400 دارد و action ارسال نشده یا خالی است | کد صفحه یا افزونه ممکن است اطلاعات لازم را نفرستاده باشد. خطاهای JavaScript و نسخه افزونه را بررسی کنید. | | پاسخ صفر است و کار اجرا نمی‌شود | ممکن است action شناخته نشده یا پردازشگر مربوط ثبت نشده باشد؛ از روی عدد صفر به‌تنهایی علت قطعی ندهید. | | پاسخ 403 یا منفی یک است | می‌تواند به اعتبار نشست، nonce، مجوز کاربر یا قانون امنیتی مربوط باشد. متن پاسخ و گزارش همان زمان را بررسی کنید. | | پاسخ 500 است | خطای سمت سرور محتمل است؛ گزارش PHP و خطای افزونه در همان زمان را بخوانید، نه اینکه فقط محدودیت مرورگر را عوض کنید. |

افزونه یا تنظیم امنیتی می‌تواند پاسخ متفاوتی بسازد. بنابراین قبل از تصمیم، کد و محتوای پاسخ را کنار هم و در کنار رفتار واقعی سایت ببینید. صفر و 403 برای همه افزونه‌ها یک معنی ثابت ندارند.

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

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

اگر کلاینت فایل JavaScript قدیمی دریافت کرده ولی افزونه جدید است، نسخه فایل و کش همان صفحه را بررسی کنید. ابتدا در پنجره خصوصی تازه آزمایش کنید و سپس، در صورت تأیید، کش مرتبط را طبق راهنمای افزونه یا CDN پاک کنید. پاک کردن کش، action اشتباه داخل کد را خودکار درست نمی‌کند.

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

وردپرس و افزونه‌ها برای بعضی درخواست‌ها از nonce استفاده می‌کنند؛ این مقدار به تشخیص درخواست معتبر در یک زمینه کمک می‌کند. پاسخ منفی یک می‌تواند با شکست بررسی nonce مرتبط باشد، اما هر پاسخ مشابه لزوماً همین علت را ندارد. مستندات check_ajax_referer نشان می‌دهد بررسی ناموفق می‌تواند پاسخ 403 بدهد. nonce جای بررسی مجوز حساب را نمی‌گیرد.

اگر گزارش امنیتی یا وب‌سرور نشان می‌دهد یک قانون مشخص درخواست سالم را رد کرده، زمان، مسیر و شناسه قانون را به مسئول امنیت بدهید تا استثنای محدود و قابل بازگشت را ارزیابی کند. کل فایروال یا همه قوانین امنیتی را خاموش نکنید و مسیر مدیریت را برای تمام اینترنت بازتر نکنید.

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

اگر پاسخ از REST API و مسیر wp-json می‌آید، آن را با admin-ajax اشتباه نگیرید؛ روش احراز هویت و گزارش خطا متفاوت است. راهنمای خطای REST API در ویرایشگر وردپرس آن مسئله را جداگانه توضیح می‌دهد.

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

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