REST API يعيد 401 أو 403 في ووردبريس: اختبار العام مقابل context=edit

ظهر لك 401 أو 403 عند ربط تطبيق بووردبريس؟ لا يعني ذلك دائما أن الموقع معطل؛ ربما يرفض طلبا يحتاج تسجيل دخول أو صلاحية غير متوفرة. سنوضح الفرق بين قراءة المحتوى العام وتعديله، وما الذي تفحصه قبل تعطيل الحماية أو واجهة REST API.

REST API وسيلة يتواصل بها التطبيق مع ووردبريس. الزائر قد يستطيع قراءة مقال منشور، لكن تعديل المقال يحتاج هوية وصلاحية. الرمز 401 يرتبط عادة بالحاجة إلى التحقق من الهوية، و403 برفض العملية؛ ونص الرد يساعد في تحديد السبب بدقة.

الفرق بين 401 و403

عمليا يشير 401 إلى أن الطلب يحتاج مصادقة أو لم يتعرف إلى الهوية. 403 يعني غالبا أن الهوية أو الطلب معروف لكن العملية غير مسموحة، وقد يصدر أيضا من WAF قبل ووردبريس. اقرأ جسم JSON ورؤوس الاستجابة وسجل الخادم؛ الرمز وحده لا يحدد الطبقة.

أسئلة التشخيص

1. ما عنوان الطلب وما العملية المطلوبة؟ GET للقراءة عادة، وPOST للإرسال أو التعديل بحسب المسار، وDELETE للحذف.
2. هل العملية متاحة للزائر أم تحتاج صلاحية مثل تحرير المقالات (edit_posts) أو رفع الملفات (upload_files)؟
3. هل الطلب من داخل لوحة ووردبريس ويستخدم Cookie + X-WP-Nonce، أم من تطبيق خارجي؟
4. هل يستخدم التطبيق الخارجي «كلمة مرور تطبيق» (Application Password) مخصصة له عبر HTTPS، بدل كلمة مرور دخول المدير؟
5. هل حدث تحويل 301 أفقد رأس Authorization عند الانتقال بين HTTP وHTTPS أو www؟
6. هل الرد JSON من ووردبريس أم صفحة HTML من Cloudflare أو ModSecurity؟

ما الذي لا نفعله؟

لا نعيد true من permission_callback لكل الطلبات، ولا نضع كلمة مرور المدير في كود أو تطبيق هاتف، ولا نعطل REST API بالكامل؛ المحرر وميزات إضافات كثيرة تعتمد عليه. لا نستخدم Nonce لوحة التحكم في سكربت خارجي طويل العمر؛ Nonce رمز تحقق مؤقت مرتبط بالمستخدم والسياق، وليس كلمة مرور دائمة للتطبيق.

اختبار التطبيق الخارجي

أنشئ مستخدما بأقل صلاحية مطلوبة وApplication Password مستقلا يمكن إلغاؤه. ابدأ بطلب قراءة محدود، ثم عملية تجريبية على مسودة. سجل URL النهائي بعد التحويلات. إذا نجح GET وفشل POST فافحص الصلاحية والطريقة وWAF، لا الاتصال فقط. ويمكن مقارنة ذلك بخطأ المهلة cURL 28؛ هناك لا يصل الرد في الوقت، بينما هنا يصل رفض محدد.

تفاصيل التجربة ونتيجتها

تاريخ التجربة: 19 أغسطس 2026؛ ووردبريس: 7.0.4؛ PHP: 8.3.30؛ مكان التنفيذ وأدواته: طلبان غير مسجلين إلى REST API المحلية.

أعاد طلب قائمة المقالات العامة HTTP 200. أضفنا context=edit بالعميل نفسه دون جلسة فأعاد HTTP 401، وهو سلوك حماية صحيح.

تحقق إضافي، 19 أغسطس 2026: طلبنا قائمة عامة دون تسجيل، ثم طلبنا السياق التحريري بالعميل نفسه. النتيجة تخص مسارين وسياقين محددين دون تسجيل دخول. 401 في سياق التحرير متوقعة هنا، ولا تفسر كل حالة 403 أو مشكلة مصادقة في تطبيق آخر.

أعد اختبار القراءة العامة والسياق التحريري بنفسك

الأوامر التالية خطوات قابلة للتكرار، وليست سجلا لقياس جديد على الموقع المنشور. نتائج 19 أغسطس أعلاه تخص المختبر المذكور فقط. نفذ طلبا واحدا لكل سياق على موقعك أو موقع لديك إذن بفحصه، واستبدل نطاق المثال بنطاقك عند الحاجة. الطلبان للقراءة فقط ولا يعدلان المقالات.

استخدم أداة curl في الطرفية، أو curl.exe بدلا من curl عند استخدام Windows PowerShell. لا تضف Cookie أو Authorization أو بيانات دخول؛ الهدف مقارنة السياقين دون مصادقة. الخيار -q في بداية الأمر يمنع تحميل إعدادات curl الشخصية تلقائيا.

1. طلب عام يعرض معرف مقال منشور واحد

curl -q -i --connect-timeout 10 --max-time 20 --request GET --header "Accept: application/json" "https://gzkhabar.com/wp-json/wp/v2/posts?per_page=1&_fields=id&context=view"

2. الطلب نفسه مع context=edit ودون بيانات دخول

curl -q -i --connect-timeout 10 --max-time 20 --request GET --header "Accept: application/json" "https://gzkhabar.com/wp-json/wp/v2/posts?per_page=1&_fields=id&context=edit"

ما الذي تسجله من الاستجابة الفعلية؟

• وقت التنفيذ وعنوان الطلب والسياق المستخدم، مع ذكر عدم إرسال بيانات مصادقة.
• رمز HTTP في أول سطر من الاستجابة ورأس Content-Type؛ الخيار -i يعرض الرؤوس مع الجسم.
• جسم JSON: قائمة المعرفات في الطلب العام، أو حقول code وmessage وdata.status إذا أعاد ووردبريس خطأ. انسخ القيم التي ظهرت فعلا ولا تستبدلها بنتيجة متوقعة.
• إذا ظهر تحويل 301 أو 302، سجل رأس Location وتحقق من النطاق المقصود قبل إعادة الطلب؛ الأوامر لا تتبع التحويل تلقائيا.

عند إتاحة القراءة العامة، يتوقع أن يعيد الطلب الأول 200 وقائمة قد تكون فارغة. أما السياق التحريري دون مصادقة فيتوقع رفضه؛ كانت النتيجة 401 في تجربتنا التاريخية. قد تعيد طبقة حماية 403 أو صفحة HTML قبل وصول الطلب إلى ووردبريس، فلا تعتبر ذلك النتيجة نفسها ولا تعطل الحماية لتغيير الرمز. وإذا ظهر 429 أو طلب تحقق أمني، توقف عن تكرار الطلب وراجع إعدادات الموقع مع المسؤول.

احتفظ بالرؤوس والسجل الكامل محليا عند الحاجة، ولا تنشرهما قبل إزالة Set-Cookie وأي معرفات جلسة أو بيانات حساسة. يكفي للتوثيق العام عنوان الطلب المنقح، ورمز HTTP، ونوع المحتوى، ومقتطف الجسم اللازم لشرح النتيجة. لا يثبت هذا الاختبار نجاح مصادقة تطبيق خارجي أو صلاحيات الكتابة؛ لكل منهما اختبار منفصل في بيئة تجريبية.

المصادر

• مشكلة 403 عند التعامل مع وسائط REST API.
• WordPress REST API: المصادقة.