مصادقة REST API في ووردبريس: Nonce أم كلمات مرور التطبيقات؟

لو فتحت أدوات المطور وأنت بتكتب ووردبريس للمحتوى المؤرخ مثل التدوينات والأخبار والشروحات. تُرتّب زمنيًا وتُنظَّم بالتصنيفات والوسوم وتظهر في الأرشيف وخلاصات RSS، بخلاف الصفحات الثابتة.">مقالة في محرر ووردبريس، هتلاقي طلبات رايحة جاية للسيرفر كل شوية، ومع ذلك عمرك ما كتبت كلمة السر غير مرة واحدة. طب لما تيجي تربط n8n أو سكربت على سيرفر تاني بنفس الموقع، ليه نفس الطريقة دي ما بتشتغلش؟ الإجابة في آليتين مختلفتين للمصادقة، وكل واحدة معمولة لباب مختلف.

ثلاث طبقات لأي طلب على REST API

قبل التفاصيل، رتّب الصورة في ذهنك. ليست كل نقاط النهاية (Endpoints) في الـ API في ووردبريس واجهة مدمجة تتيح قراءة المحتوى وإنشاءه وتعديله عبر روابط HTTP تحت /wp-json/، دون فتح الإضافات والقوالب والمستخدمين والإعدادات، وما يظهر فيها يختلف حسب دور المستخدم.">لوحة التحكم. عليها تعتمد تطبيقات الموبايل والمواقع المنفصلة…">REST API بحاجة إلى مصادقة أصلاً:

إذا كان كل ما تحتاجه عرض آخر المقالات في صفحة هبوط أو تطبيق خارجي، فلا تضف مصادقة لا داعي لها. المصادقة تبدأ عندما تتجاوز البيانات العامة: المسودات، والإنشاء، والتعديل، والإعدادات.

داخل لوحة التحكم: الكوكي يعرّفك

بعد تسجيل الدخول يحفظ المتصفح كوكي المصادقة (Authentication Cookie) باسم يبدأ بـ wordpress_logged_in_. يرسل المتصفح هذا الكوكي تلقائياً مع كل طلب إلى الدومين نفسه، فيعرف السيرفر من أنت دون أن تعيد كتابة كلمة المرور.

حين يستدعي JavaScript الخاص بلوحة التحكم الـ REST API، كأن يحفظ محرر المكوّنات (Gutenberg) مسودتك في الخلفية، فهو يعتمد على هذا الكوكي نفسه.

لماذا لا يكفي الكوكي وحده؟

هنا تظهر ثغرة تزوير الطلبات عبر المواقع (CSRF). لأن المتصفح يرفق الكوكي تلقائياً، فإن فتح صفحة خبيثة وأنت مسجّل الدخول قد يجعلها ترسل طلباً إلى موقعك يحمل الكوكي نفسه، فيحذف مقالة أو يغيّر إعداداً دون علمك.

لو قبل السيرفر طلبات الكتابة بناءً على الكوكي فقط، لكانت زيارة صفحة واحدة كافية لإحداث الضرر. لذلك تضيف ووردبريس طبقة ثانية.

الـ Nonce: إثبات أن الطلب خرج من صفحتك

رمز التحقق المؤقت (Nonce) لا يُستخدم مرة واحدة كما يوحي اسمه. هو رمز مرتبط بالمستخدم الحالي وبإجراء محدد، وصالح لنافذة زمنية (24 ساعة افتراضياً، وقد يمتد قرابة 48 ساعة مع التدوير).

يولّده السيرفر بالدالة wp_create_nonce() ويضعه داخل صفحة لوحة التحكم، ثم ترسله طلبات الكتابة في الترويسة X-WP-Nonce. بالنسبة للـ REST API تحديداً، اسم الإجراء المعتمد هو wp_rest:

<?php
// Pass the REST nonce to your admin script
add_action( 'admin_enqueue_scripts', function () {
    wp_enqueue_script( 'my-admin', plugins_url( 'admin.js', __FILE__ ), array(), '1.0', true );
    wp_localize_script( 'my-admin', 'myApi', array(
        'root'  => esc_url_raw( rest_url() ),
        'nonce' => wp_create_nonce( 'wp_rest' ),
    ) );
} );

// admin.js — write request that rides on the login cookie + nonce
fetch( myApi.root + 'wp/v2/posts/123', {
  method: 'POST',
  credentials: 'same-origin',
  headers: {
    'Content-Type': 'application/json',
    'X-WP-Nonce': myApi.nonce
  },
  body: JSON.stringify( { title: 'Updated title' } )
} );

الصفحة الخبيثة لا تستطيع قراءة هذا الرمز، لأنه موجود فقط داخل صفحة على دومينك. باختصار: الكوكي يجيب عن سؤال «من أنت؟»، والـ Nonce يجيب عن سؤال «هل قصدت هذا الإجراء من هذه الصفحة الآن؟». ولا يمر الطلب إلا إذا نجح الاثنان.

أين يتوقف أسلوب الكوكي والـ Nonce؟

هذا التصميم يفترض أن الطلب يخرج من متصفح داخل جلسة دخول قائمة. أداة سطر أوامر، أو سكربت على سيرفر آخر، أو منصة أتمتة مثل n8n، لا تملك جلسة متصفح طبيعية تحافظ عليها.

والـ Nonce قصير العمر ويحتاج إلى جلبه من جديد مع كل تحميل لصفحة في لوحة التحكم، فلا يصلح أساساً لتكامل يعمل وحده كل ساعة.

كلمات مرور التطبيقات: باب منفصل للبرامج الخارجية

أضافت ووردبريس كلمات مرور التطبيقات (Application Passwords) إلى النواة منذ الإصدار 5.6 عام 2020 لتحل هذه المشكلة تحديداً. تعمل بأسلوب يشبه مصادقة HTTP Basic، وبعيداً تماماً عن الكوكي والـ Nonce.

لإنشاء واحدة:

1. افتح المستخدمون ← ملفك الشخصي في لوحة التحكم.
2. انزل إلى قسم Application Passwords (كلمات مرور التطبيقات).
3. اكتب اسماً يصف التكامل، مثل n8n-publisher، واضغط Add New Application Password.
4. انسخ كلمة المرور فوراً، فلن تظهر مرة أخرى.

بعدها يرسلها البرنامج الخارجي في ترويسة Authorization: Basic:

curl -u "editor_user:abcd efgh ijkl mnop qrst uvwx" 
  "https://example.com/wp-json/wp/v2/posts?status=draft"

كلمة مرور التطبيق تحمل صلاحيات الحساب الذي أنشأها، لذلك أنشئها من حساب بدور (User Role) محرر أو كاتب حسب حاجة التكامل، لا من حساب المدير إن أمكن.

ما الذي يميزها عن كلمة مرور الدخول؟

• لا تعتمد على جلسة متصفح: أي برنامج يملكها يستطيع استخدامها فوراً.
• تُلغى منفردة: إن توقفت عن استخدام تكامل ما، احذف كلمة مروره وحدها دون أن تلمس كلمة مرور دخولك أو تؤثر على بقية التكاملات.
• لا تسلّم كلمة مرورك الحقيقية لأي طرف ثالث.

مشكلات شائعة على الاستضافات في المنطقة

• الميزة لا تظهر في الملف الشخصي: ووردبريس تتيح كلمات مرور التطبيقات افتراضياً فقط على المواقع التي تعمل بشهادة SSL. فعّل HTTPS أولاً، وهو متاح مجاناً عبر Let’s Encrypt على أغلب الاستضافات.
• خطأ 401 رغم صحة كلمة المرور: بعض إعدادات Apache وCGI على الاستضافات المشتركة تحذف ترويسة Authorization قبل وصولها إلى PHP. تأكد أن ملف .htaccess يحتوي على السطر التالي داخل كتلة ووردبريس:

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

• إضافة حماية تحجب الـ REST API: بعض إضافات الأمان تعطّل الـ REST API لغير المسجلين. راجع إعداداتها واسمح للمسارات التي يحتاجها تكاملك فقط.

في Elementor وJetEngine: محرر Elementor نفسه يعمل بالكوكي والـ Nonce داخل لوحة التحكم، فلا تحتاج إلى شيء إضافي. أما حين تربط مواقعك بـ n8n لنشر مسودات أو تحديث حقول مخصصة (Custom Fields) أنشأتها بـ JetEngine، فاستخدم كلمة مرور تطبيق لكل تكامل، وتأكد من تفعيل خيار إظهار الحقول في الـ REST API عند تعريفها.

الأسئلة الشائعة

س: هل أحتاج إلى مصادقة لعرض آخر مقالات موقعي في موقع آخر؟
ج: لا. نقطة النهاية /wp/v2/posts تعرض المقالات المنشورة للعامة دون مصادقة. المصادقة ضرورية فقط للمسودات والكتابة والتعديل.

س: ما الفرق بين الـ Nonce وكلمة مرور التطبيق؟
ج: الـ Nonce رمز مؤقت يحمي الطلبات الصادرة من متصفحك داخل لوحة التحكم من هجمات CSRF، أما كلمة مرور التطبيق فهي بيانات دخول دائمة لبرنامج خارجي يمكنك إلغاؤها في أي وقت.

س: لماذا لا تظهر كلمات مرور التطبيقات في ملفي الشخصي؟
ج: غالباً لأن الموقع لا يعمل عبر HTTPS، أو لأن إضافة أمان أو كوداً مخصصاً عطّل الميزة عبر الفلتر wp_is_application_passwords_available.

س: هل استخدام كلمة مرور التطبيق آمن؟
ج: نعم ما دام الاتصال عبر HTTPS، وما دمت تنشئ كلمة منفصلة لكل تكامل من حساب بأقل صلاحيات لازمة، وتحذف ما لم تعد تستخدمه.

الخلاصة

القاعدة بسيطة: الطلب اللي طالع من المتصفح جوه لوحة التحكم بيعدّي بالكوكي والـ Nonce، والبرنامج اللي شغال بره المتصفح ياخد كلمة مرور تطبيق خاصة بيه. افتح ملفك الشخصي النهارده وراجع كلمات مرور التطبيقات الموجودة، واحذف أي واحدة مش عارف هي بتاعة إيه.

مرجع المقال (بالإنجليزية): REST API Authentication: Cookie+Nonce vs. Application Passwords
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.