ظهر لك 401 أو 403 عند ربط تطبيق بووردبريس؟ لا يعني ذلك دائما أن الموقع معطل؛ ربما يرفض طلبا يحتاج تسجيل دخول أو صلاحية غير متوفرة. سنوضح الفرق بين قراءة المحتوى العام وتعديله، وما الذي تفحصه قبل تعطيل الحماية أو واجهة REST API.
REST API وسيلة يتواصل بها التطبيق مع ووردبريس. الزائر قد يستطيع قراءة مقال منشور، لكن تعديل المقال يحتاج هوية وصلاحية. الرمز 401 يرتبط عادة بالحاجة إلى التحقق من الهوية، و403 برفض العملية؛ ونص الرد يساعد في تحديد السبب بدقة.
الفرق بين 401 و403
عمليا يشير 401 إلى أن الطلب يحتاج مصادقة أو لم يتعرف إلى الهوية. 403 يعني غالبا أن الهوية أو الطلب معروف لكن العملية غير مسموحة، وقد يصدر أيضا من WAF قبل ووردبريس. اقرأ جسم JSON ورؤوس الاستجابة وسجل الخادم؛ الرمز وحده لا يحدد الطبقة.
أسئلة التشخيص
- ما عنوان الطلب وما العملية المطلوبة؟
GETللقراءة عادة، وPOSTللإرسال أو التعديل بحسب المسار، وDELETEللحذف. - هل العملية متاحة للزائر أم تحتاج صلاحية مثل تحرير المقالات (
edit_posts) أو رفع الملفات (upload_files)؟ - هل الطلب من داخل لوحة ووردبريس ويستخدم Cookie + X-WP-Nonce، أم من تطبيق خارجي؟
- هل يستخدم التطبيق الخارجي «كلمة مرور تطبيق» (Application Password) مخصصة له عبر HTTPS، بدل كلمة مرور دخول المدير؟
- هل حدث تحويل 301 أفقد رأس Authorization عند الانتقال بين HTTP وHTTPS أو www؟
- هل الرد 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 أو مشكلة مصادقة في تطبيق آخر.
