خطای REST API وردپرس 401 یا 403؛ ویرایشگر را برگردانیم

ویرایشگر بلوکی ممکن است پیام «به‌روزرسانی انجام نشد» بدهد، صفحهٔ Site Health از REST API خطا بگیرد یا یک افزونه نتواند محتوا را بارگذاری کند. یکی از علت‌ها پاسخ 401 Unauthorized یا 403 Forbidden از REST API وردپرس است. این API راهی است که پیشخوان و افزونه‌ها با درخواست وب، دادهٔ وردپرس را می‌خوانند یا ذخیره می‌کنند. خاموش‌کردن کامل API می‌تواند بخش‌هایی از پیشخوان را خراب کند؛ بهتر است همان درخواست ناموفق را پیدا کنیم.

صفحهٔ پیشخوان را در Chrome باز کنید و کلید F12 را بزنید. در زبانهٔ Network گزینهٔ Fetch/XHR را انتخاب کنید، سپس همان کاری را که خطا می‌دهد تکرار کنید؛ مثلاً ذخیرهٔ یک پیش‌نویس. درخواست قرمز را باز کنید و کد Status، نشانی درخواست و چند خط اول Response را یادداشت کنید. پاسخ JSON معمولاً نام خطا و پیام قابل‌خواندن دارد. کوکی، nonce، رمز یا بدنهٔ کامل شامل محتوای خصوصی را در گزارش عمومی نگذارید.

اگر درخواست پاسخ 404 می‌گیرد، ممکن است مسیرهای بازنویسی یا پیوند یکتا درست کار نکنند. اگر 500 می‌بینید، لاگ PHP را در همان زمان بخوانید. این مقاله دربارهٔ 401 و 403 است؛ دانستن کد پاسخ کمک می‌کند مسیر اشتباه را دنبال نکنید.

از مرورگر خارج شوید یا یک پنجرهٔ خصوصی باز کنید و این نشانی را ببینید:

دامنه را عوض کنید. در حالت معمول باید فهرستی از مسیرهای عمومی API به شکل JSON ببینید. این صفحه برای افراد ناشناس در دسترس است و به‌تنهایی اجازهٔ ویرایش محتوا نمی‌دهد. راهنمای مرجع رسمی REST API وردپرس فرق دادهٔ عمومی و بخش‌های نیازمند دسترسی را توضیح می‌دهد.

اگر /wp-json/ خودش 401 یا 403 می‌دهد، احتمالاً تنظیم امنیتی، WAF، CDN یا کد سایت همهٔ API را بسته است. اگر این مسیر باز است ولی فقط یک درخواست پیشخوان خطا دارد، بررسی را روی همان endpoint محدود کنید؛ درخواست ذخیرهٔ خصوصی نیازمند احراز هویت و اجازهٔ کاربر است.

401 معمولاً یعنی درخواست برای ادامه به ورود یا اعتبارسنجی نیاز دارد. 403 یعنی درخواست دریافت شده اما اجازهٔ انجام این کار را ندارد؛ ممکن است کاربر نقش لازم را نداشته باشد یا قانون امنیتی آن را رد کند. در WordPress، بعضی endpointها برای دادهٔ عمومی بازند ولی ساخت یا ویرایش مطلب فقط برای کاربر واردشده با دسترسی مناسب انجام می‌شود. 403 را با «اجازهٔ نوشتن فایل روی هاست» اشتباه نگیرید؛ این کد می‌تواند از خود API یا از دیوارهٔ امنیتی آمده باشد.

درخواست GET /wp-json/wp/v2/posts?per_page=1 را برای دیدن یک فهرست عمومی امتحان کنید. اگر این کار باز است اما ذخیره از پیشخوان نه، REST API به‌طور کامل خراب نیست؛ احتمالاً nonce منقضی شده، کوکی ورود با دامنهٔ صفحه نمی‌خواند یا حساب شما مجوز آن کار را ندارد. یک بار خارج شوید، دوباره وارد شوید و همان پیش‌نویس را ذخیره کنید. از حذف کوکی‌های همهٔ کاربران یا ارسال رمز در curl خودداری کنید.

اگر مشکل پس از روشن‌کردن افزونهٔ امنیتی، WAF یا قانون CDN شروع شد، زمان تغییر را ثبت کنید. در نسخهٔ آزمایشی همان قانون را بررسی و درخواست دقیق REST را آزمایش کنید. همهٔ افزونه‌ها را هم‌زمان خاموش نکنید و API را برای تمام کاربران باز نگذارید؛ دسترسی بیش از حد می‌تواند اطلاعات یا عملیات مدیریت را در معرض خطر بگذارد.

اگر پاسخ HTML یک صفحهٔ بلاک‌شده است نه JSON وردپرس، درخواست احتمالاً پیش از رسیدن به WordPress مسدود شده است. شناسهٔ رخداد، زمان، مسیر و IP درخواست را به میزبان بدهید. اگر پاسخ JSON شامل rest_cookie_invalid_nonce است، ابتدا نشست پیشخوان را تازه کنید و کشی را که HTML پیشخوان را ذخیره کرده بررسی کنید. پیشخوان وردپرس نباید در کش عمومی کاربران قرار بگیرد.

برای درخواست‌های وروددار از ابزارهای ناشناس که نام کاربری و رمز را در URL می‌خواهند استفاده نکنید. مستند احراز هویت REST API روش کوکی و application password را توضیح می‌دهد؛ کلید application password را مانند رمز اصلی نگه دارید و در گزارش خطا قرار ندهید.

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

وردپرس می‌گوید بستن کامل REST API می‌تواند کارکرد مدیریت را بشکند؛ بنابراین برای رفع خطا، کل مسیر را مسدود یا برای همه باز نکنید. یک درخواست، یک کد پاسخ و یک قانون را در هر نوبت بررسی کنید. این کار هم سایت را امن‌تر نگه می‌دارد و هم علت را روشن می‌کند.

برای آزمون REST فقط دادهٔ عمومی را بخوانید؛ مسیرهایی که سفارش، حساب یا تنظیمات دارند در پنجرهٔ ناشناس باز نکنید و پاسخ خصوصی را برای دیگران نفرستید. اگر API در حالت ناشناس عمداً بسته شده، شاید مدیر سایت این تصمیم را گرفته باشد. هدف این است که درخواست موردنیاز پیشخوان برای کاربر مجاز با نشست معتبر پاسخ بگیرد، نه اینکه همهٔ endpointها برای بازدیدکنندهٔ ناشناس باز شوند.

نشانی پیشخوان باید از نظر دامنه و HTTPS با نشانی API هماهنگ باشد. اگر پیشخوان را با www باز کرده‌اید ولی سایت به نسخهٔ بدون www می‌رود، ممکن است کوکی ورود به درخواست نرسد. با نشانی اصلی وارد شوید و نتیجه را دوباره ببینید. اگر فقط مسیر wp-json خطا دارد، پاسخ curl -I را با پاسخ Network مرورگر مقایسه کنید؛ اختلاف نشان می‌دهد یک لایه درخواست را تغییر می‌دهد.