معمارية المصادقة في ووردبريس: فصل الهوية عن التفويض وإدارة الجلسات التشفيرية

المعضلة المعمارية الكبرى: من أنت؟ مقابل ماذا يحق لك أن تفعل؟

عشان تفهم الفرق بأسلوب هندسي قاطع لا يحتمل اللبس:

1. المصادقة (Authentication – AuthN) = إثبات الهوية (Identity):
   السؤال الوحيد اللي بتجاوب عليه هو: **”أنت مين بالظبط؟”**.
   العملية دي بتتم لما المستخدم يكتب اسم المستخدم وكلمة السر، أو يبصم بصباعه، أو يدخل كود OTP. لما السيرفر يتأكد إن صاحب الحساب هو اللي واقف قدامه، بتنتهي مرحلة المصادقة بنجاح، وووردبريس بيعطيه كائن WP_User مع كوكيز الجلسة.
2. التفويض (Authorization – AuthZ) = الصلاحيات والسلطة (Permission / Capability):
   السؤال الوحيد اللي بتجاوب عليه هو: **”هل مسموح لك تعمل العملية دي تحديداً؟”**.
   بعد ما عرفنا إنك “أحمد”، هل مسموح لأحمد إنه يمسح المقال ده؟ هل مسموح له يغير أسعار المنتجات في المتجر؟ هل مسموح له يشوف تقارير المبيعات؟

دورة حياة المصادقة في ووردبريس: سلسلة هوك authenticate

لما المستخدم يكتب بياناته في صفحة wp-login.php ويضغط “تسجيل الدخول”، ووردبريس بيستدعي دالة مركزية اسمها:

wp_authenticate($username, $password)

الدالة دي مبنية بذكاء معماري خارق يعتمد بالكامل على فلتر مركزي اسمه authenticate.
النواة بتشغل سلسلة من الفلاتر المتتالية المرتبة حسب الأولويات (Priorities):

1. الأولوية 10 (فحص الفراغ): فحص هل الحقول فارغة؟ إذا كانت فارغة يعاد WP_Error فوراً.
2. الأولوية 20 (المطابقة باليوزر نيم): استدعاء wp_authenticate_username_password() لمطابقة اسم المستخدم وكلمة السر.
3. الأولوية 30 (المطابقة بالبريد الإلكتروني): استدعاء wp_authenticate_email_password() لمطابقة البريد الإلكتروني وكلمة السر.
4. الأولوية 100+ (المصادقة المخصصة – Custom Auth Providers): هنا بنحقن إحنا كودنا المعماري المخصص! تقدر تفحص هل المستخدم مفعل خاصية التحقق بخطوتين (2FA)؟ أو تتأكد من كود الـ SMS، أو تفحص هل حسابه معلق إدارياً قبل منحه الإذن بالدخول!

الهندسة التشفيرية لكلمات المرور: من MD5 إلى PHpass

زمان في إصدارات ووردبريس القديمة (قبل 2.5)، كلمات المرور كانت بتتخزن بتجزئة MD5 عادية، وكانت كارثة سهلة الاختراق بجداول Rainbow Tables.

اليوم، ووردبريس بيعتمد على إطار عمل تشفيري قوي اسمه PHpass (Portable PHP password hashing framework):

• دالة wp_hash_password($password): بتولد Salt عشوائي لكل مستخدم وتدمجه مع كلمة المرور وتعمل دورات تشفير متكررة (Stretched Hashing) باستخدام خوارزميات بطيئة متطورة.
• دالة wp_check_password($password, $hash, $userId): بتقارن كلمة المرور المدخلة بالهاش المخزن بدون ما تفك التشفير (لأن الهاش أحادي الاتجاه).
• الترقية التلقائية للتشفير (Auto-rehashing on login): لو المستخدم كان مسجل من زمان بهاش قديم وضعيف، ووردبريس أول ما المستخدم يسجل دخوله بنجاح، بيقوم تلقائياً بتوليد هاش جديد فائق الحماية وتحديثه في جدول wp_users في صمت تام وبدون إزعاج المستخدم!

هندسة توكنات الجلسات (Session Tokens Architecture)

بعد ما مرحلة المصادقة تنجح، ووردبريس محتاج طريقة عشان يعرف إن المستخدم ده مسجل دخوله في كل ريكوست جاي من المتصفح بدون ما يطلب منه الباسورد تاني.

هنا ووردبريس بيستدعي كلاس معماري عبقري اسمه WP_Session_Tokens:

1. ووردبريس بيولد توكن جلسة عشوائي مشفر وقوي جداً (Session Token).
2. بيخزن الهاش التشفيري للتوكن ده في جدول wp_usermeta تحت مفتاح session_tokens مع تفاصيل: وقت إنشاء الجلسة، ووقت انتهائها، وعنوان الـ IP، وبيانات المتصفح (User Agent).
3. بيحط الرمز الأصلي داخل كوكي مشفرة في متصفح المستخدم (Auth Cookie).

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

“تسجيل الخروج من كافة الأجهزة الأخرى (Destroy all other sessions)”، وووردبريس هيحذف التوكنات دي من الميتا فتصبح كافة الأجهزة الأخرى مطرودة فوراً في نفس اللحظة!

الكود البرمجي الكامل: معمارية مصادقة مخصصة مع نظام التحقق الثنائي (OTP / 2FA)

تعال نبني كود إنتاجي يوضح إزاي تتدخل في سلسلة المصادقة (Authentication Pipeline)، وتفرض كود تحقق عبر الرسائل القصيرة (SMS OTP) على حسابات المديرين قبل تسليمهم جلسة ووردبريس:

 نبدأ تحدي المصادقة الثنائية (OTP Challenge)
        $this->initiateOtpChallenge($user);

        // إيقاف تسجيل الدخول التقليدي وتوجيه المدير لشاشة إدخال رمز التحقق
        $challengeToken = wp_create_nonce('otp_challenge_' . $user->ID);
        $redirectUrl = add_query_arg([
            'action' => 'enter_otp',
            'user'   => $user->ID,
            'token'  => $challengeToken
        ], wp_login_url());

        wp_safe_redirect($redirectUrl);
        exit;
    }

    /**
     * توليد رمز OTP وإرساله للرقم المسجل للمدير
     */
    private function initiateOtpChallenge(WP_User $user): void {
        $otpCode = (string) wp_rand(100000, 999999);
        $hashedOtp = wp_hash_password($otpCode);

        // تخزين الرمز المشفر في Transient مؤقت
        $transientKey = 'auth_otp_' . $user->ID;
        set_transient($transientKey, [
            'hash'       => $hashedOtp,
            'expires_at' => time() + self::OTP_EXPIRATION_SECONDS
        ], self::OTP_EXPIRATION_SECONDS);

        // إرسال الكود للرقم المسجل (محاكاة إرسال SMS أو عبر واتساب)
        $phone = get_user_meta($user->ID, 'security_phone_number', true) ?: '01012345678';
        $this->sendSmsNotification($phone, "رمز الأمان للدخول للوحة التحكم هو: {$otpCode}");
    }

    /**
     * معالجة استمارة إدخال كود الـ OTP
     */
    public function handleOtpChallengeSubmission(): void {
        $userId = absint($_POST['user_id'] ?? 0);
        $token  = $_POST['token'] ?? '';
        $enteredOtp = sanitize_text_field($_POST['otp_code'] ?? '');

        // 1. التحقق من النونس لمنع التلاعب برابط التحدي
        if (!wp_verify_nonce((string)$token, 'otp_challenge_' . $userId)) {
            wp_die('انتهت صلاحية جلسة التحقق، يرجى إعادة تسجيل الدخول.', 'فشل التحقق', ['response' => 403]);
        }

        $user = get_userdata($userId);
        if (!$user) {
            wp_die('مستخدم غير صالح.', 'خطأ', ['response' => 404]);
        }

        // 2. التحقق من صحة كود الـ OTP من Transient
        $transientKey = 'auth_otp_' . $userId;
        $storedData = get_transient($transientKey);

        if (!$storedData || empty($storedData['hash'])) {
            wp_die('رمز التحقق منتهي الصلاحية، يرجى تسجيل الدخول من جديد.', 'منتهي', ['response' => 403]);
        }

        if (!wp_check_password($enteredOtp, $storedData['hash'])) {
            wp_die('رمز التحقق المدخل غير صحيح! يرجى المحاولة مرة أخرى.', 'كود خاطئ', ['response' => 403]);
        }

        // نجحت المصادقة الثنائية بنسبة 100%!
        // نحذف الرمز لمنع إعادة استخدامه
        delete_transient($transientKey);

        // 3. تسليم جلسة ووردبريس الرسمية وتعيين الكوكيز
        wp_clear_auth_cookie();
        wp_set_current_user($userId);
        wp_set_auth_cookie($userId, true);

        // التوجيه للوحة التحكم بأمان
        wp_safe_redirect(admin_url());
        exit;
    }

    private function sendSmsNotification(string $phone, string $msg): void {
        // استدعاء بوابة الرسائل المحلية
        error_log("[2FA SMS SENT] To: {$phone} | Message: {$msg}");
    }
}

دراسة حالة حقيقية: كارثة منصة العمليات الجراحية بالمعادي

عشان تعرف خطورة الخلط بين إثبات الهوية (Authentication) وفحص الصلاحيات (Authorization)، هشاركك واقعة حقيقية حصلت مع منصة طبية شهيرة في المعادي بالقاهرة متخصصة في حجز غرف العمليات الجراحية وتنسيق الأطقم الطبية لجراحي العظام والقلب:

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

if (!is_user_logged_in()) { wp_die('يجب تسجيل الدخول أولاً'); }
المبرمج اكتفى بفحص الهوية (Authentication)! ولم يفحص هل المستخدم طبيب جراح أم مريض عادي (Authorization)!

يوم الكارثة:
أحد المرضى المسجلين بحساب عادي جداً (Subscriber)، كان حاجز ميعاد كشف استشاري بسيط بـ 250 جنيه.
المريض كان بيفهم في البرمجة وشاف طلبات الـ Network في المتصفح. دخل على واجهة تعديل مواعيد العمليات الجراحية بالـ ID، ولأن حسابه مسجل دخوله، كود الإضافة قبله واعتبره مصرحاً له!
المريض بالخطأ قام بتعديل جدول عمليات جراحية حرجة لمرضى قلب مفتوح في مستشفى استثماري كبير، وحذف حجز غرفة العمليات لجراح شهير ونقل موعد العملية لليوم التالي!

التبعات الطبية والقانونية:
في صباح اليوم التالي، المريض الحرج وصل المستشفى مجهزاً للجراحة، ليتفاجأ الجميع بأن غرفة العمليات محجوزة لجراحة أخرى، واسم المريض محذوف من النظام!
حصلت حالة طوارئ طبية كبرى، والمستشفى كادت تفقد حياة المريض، وإدارة المستشفى رفعت دعوى إهمال جسيم وطلب تعويض بملايين الجنيهات ضد المنصة الطبية!

العلاج المعماري الجذري:
لما استلمت إدارة الأزمة:

1. الفصل التام بين الهوية والصلاحيات: تم حظر الاعتماد على is_user_logged_in() وحدها في أي عملية تنفيذية، وإلزام كافة الدوال بفحص الصلاحية الصريحة: current_user_can('schedule_surgery_operations').
2. بناء قدرات مخصصة (Custom Capabilities): تم إنشاء رتب دقيقة (Surgeon, Anesthetist, ClinicAdmin) ومنح كل رتبة صلاحيات دقيقة جداً.
3. فحص حدود ملكية المورد (Object-level Authorization): الطبيب الجراح لا يستطيع تعديل أي عملية إلا إذا كان اسمه مدرجاً كطبيب رئيسي مسؤول عن تلك الحالة الجراحية تحديداً.

النتيجة: تم إنقاذ المنصة، واستعادة ثقة المستشفيات الشريكة، وتم اعتماد نظام رقابة طبية مؤتمت يمنع أي تداخل بين حسابات المرضى وصلاحيات الأطقم الطبية.

الوصايا العشر لمعمارية المصادقة والتفويض في ووردبريس

1. لا تخلط الهوية بالصلاحية: تذكر دائماً: is_user_logged_in() تخبرك فقط أن المستخدم مسجل، لكنها لا تمنحه الحق في تنفيذ أي إجراء دون current_user_can().
2. افحص القدرات وليس الرتب (Check Capabilities, Not Roles): لا تكتب $user->roles[0] === 'editor'، بل افحص الصلاحية الوظيفية current_user_can('edit_others_posts').
3. استخدم سلسلة هوك authenticate بأمان: عند بناء مزود تسجيل دخول مخصص، احرص على إرجاع كائن WP_User أو كائن WP_Error دون كسر بقية الفلاتر.
4. حصن حسابات المديرين بالـ 2FA: ألزم أي مستخدم يملك صلاحيات إدارية بتسجيل الدخول الثنائي (OTP) عبر البريد أو الـ SMS.
5. اعتمد على دوال تشفير ووردبريس: لا تستخدم دوال تجزئة عادية مثل md5 أو sha1، واستخدم دائماً wp_hash_password() و wp_check_password().
6. وفر ميزة إنهاء الجلسات البعيدة: اسمح لمستخدميك بإنهاء جلساتهم المفتوحة على الأجهزة الأخرى عبر كلاس WP_Session_Tokens.
7. أمن ملفات كوكيز الجلسة: تأكد أن كوكيز المصادقة تُرسل بعلامات Secure و HttpOnly و SameSite لمنع سرقتها عبر الشبكة أو الجافاسكريبت.
8. احذر من تخزين بيانات حساسة في usermeta بنصوص صريحة: إذا قمت بتخزين توكنات بنكية أو أرقام سرية للمستخدمين، شفرها قبل الحفظ.
9. حظر محاولات التخمين العشوائي (Brute-Force Protection): قيد عدد محاولات الدخول الخاطئة لكل عنوان IP لمنع هجمات القواميس الآلية.
10. وثق كل حركة مصادقة في سجلات الرقابة (Audit Logging): احتفظ بسجل زمني لحركات تسجيل الدخول الناجحة والفاشلة للكشف المبكر عن أي محاولات اختراق.

معمارية الدخول الموحد (Single Sign-On – SSO) والربط مع مزودي الهوية

في الشركات الكبرى والمؤسسات التعليمية، موظفو الشركة لا يملكون كلمات مرور مستقلة لكل موقع ووردبريس؛ بل تمتلك المؤسسة نظام إدارة هوية مركزي (Identity Provider – IdP) مثل Google Workspace، أو Microsoft Azure AD (Entra ID)، أو Okta.

كيف تتدخل معمارية ووردبريس لدعم تسجيل الدخول الموحد ببروتوكولات مثل **OAuth 2.0** و **OpenID Connect (OIDC)**؟

1. توجيه المستخدم لمزود الهوية: المستخدم يضغط على زر “تسجيل الدخول بحساب مايكروسوفت/جوجل”، فيتم توجيهه لخادم المصادقة الخارجي.
2. استقبال رمز التخويل (Authorization Code Callback): بعد نجاح المستخدم في تسجيل دخوله، يقوم الخادم الخارجي بإعادة توجيهه إلى رابط في إضافتك يحتوي على ?code=XYZ....
3. استبدال الرمز بتوكن الهوية (JWT / ID Token): تقوم إضافتك في الخلفية بإرسال طلب آمن من السيرفر للسيرفر واستلام بيانات الموظف (الاسم، البريد الإلكتروني، والقسم).
4. ربط الحساب أو إنشاؤه في ووردبريس: تفحص إضافتك جدول wp_users بواسطة get_user_by('email', $email)؛ فإذا كان موجوداً تسجل دخوله، وإذا كان موظفاً جديداً تنشئ له حساباً برتبة محددة وفقاً لأقسام الشركة، ثم تستدعي wp_set_auth_cookie()!

المصادقة بدون كلمة مرور: الروابط السحرية (Magic Links) والبصمة الحيوية (Passkeys)

الاتجاه العالمي الحديث في الأمن السيبراني هو التخلص التام من كلمات المرور التقليدية (Passwordless Authentication)؛ لأن المستخدمين يميلون دائماً لاختيار كلمات مرور ضعيفة أو مكررة عبر عدة مواقع.

1. معمارية الروابط السحرية (Magic Links):

المستخدم يكتب بريده الإلكتروني فقط؛ تقوم إضافتك بتوليد توكن عشوائي مشفر فائق الطول (64 حرفاً) وتخزينه في Transient بصلاحية زمنية لا تتجاوز 10 دقائق، وترسل له رابطاً يحتوي على التوكن مشفراً:

https://example.com/wp-login.php?action=magic_auth&token=abc...

عند نقر الرابط، يفحص السيرفر التوكن ويطابق التشفير، ويسجل دخول المستخدم فوراً ويحذف التوكن لمنع إعادة استخدامه!

2. معيار WebAuthn والبصمة الحيوية (Passkeys):

المعيار الأكثر أماناً في العالم اليوم المعتمد من تحالف FIDO؛ يتيح للمستخدم تسجيل دخوله إلى لوحة تحكم ووردبريس باستخدام بصمة الإصبع (Touch ID)، أو بصمة الوجه (Face ID)، أو مفاتيح الأمان الفيزيائية (YubiKey).
الميزة المعمارية الخارقة في Passkeys هي أنها محصنة بنسبة 100% ضد هجمات التصيد الاحتيالي (Phishing-proof)؛ لأن المفتاح السري لا يغادر شريحة الأمان في جهاز المستخدم إطلاقاً، ويتم إرسال توقيع تشفيري مجرد للسيرفر.

الهندسة العميقة لكلمات مرور التطبيقات (Application Passwords)

تم دمج ميزة **Application Passwords** في صلب نواة ووردبريس منذ إصدار 5.6 لتوفير مصادقة آمنة لتطبيقات الموبايل وأنظمة الـ REST API الخارجية.

العبقرية في هذا التصميم:

• المستخدم ينشئ كلمة مرور خاصة للتطبيق من شاشة حسابه (Profile).
• كلمة المرور هذه تعمل **فقط مع واجهات الـ REST API**، ولا يمكن استخدامها لتسجيل الدخول إلى لوحة التحكم عبر wp-login.php!
• إذا تم اختراق الموبايل أو تسريب التوكن، يمكن لمدير الموقع أو المستخدم إلغاء كلمة مرور التطبيق هذه بضغطة زر واحدة دون تغيير كلمة المرور الرئيسية لحسابه ودون التأثير على بقية أجهزته.

الصلاحيات الديناميكية وفلتر user_has_cap في الأنظمة متعددة الفروع

في التطبيقات المؤسسية المتقدمة (Enterprise Multi-Branch Systems)، الصلاحيات الثابتة (Static Capabilities) لا تكون كافية وحدها.
تخيل أن لديك متجراً كبيراً يمتلك فرعاً في الإسكندرية وفرعاً في القاهرة.
أنت تريد أن تمنح “مدير فرع الإسكندرية” صلاحية تعديل وحذف الطلبات، ولكن **لطلبات فرع الإسكندرية حصراً**! لو منحت حسابه صلاحية edit_orders، ووردبريس سيسمح له بتعديل طلبات القاهرة والصعيد أيضاً!

كيف تتدخل معمارية التفويض في ووردبريس لحل هذه المعضلة بدقة متناهية؟
السر يكمن في فلتر user_has_cap الفائق القوة:

ID, 'assigned_branch_id', true);

        // إذا كان الطلب يتبع نفس فرع المدير، امنحه الصلاحية فوراً
        if (!empty($orderBranch) && $orderBranch === $userBranch) {
            $allcaps['edit_branch_order'] = true;
        } else {
            // فرع مختلف -> احظر العملية فوراً حتى لو كان مديراً
            $allcaps['edit_branch_order'] = false;
        }
    }

    return $allcaps;
}, 10, 4);

هذا الفلتر المعماري العبقري يحول نظامك إلى نظام تفويض سياقي كامل (Attribute-Based Access Control – ABAC)، ويمنحك القدرة على بناء أعتى المنصات السحابية المتعددة الفروع والشركات (Multi-Tenant Platforms) بأعلى درجات الأمان والعزل التام.

أمان مفاتيح استعادة كلمة المرور (Password Reset Keys)

عندما يطلب المستخدم استعادة كلمة المرور في ووردبريس، لا يتم إرسال كلمة المرور إطلاقاً، بل يقوم النظام بتوليد مفتاح استرجاع تشفيري مؤقت ومخزن كهاش مشفر في جدول wp_users تحت حقل user_activation_key. صلاحية هذا الرابط تنتهي تلقائياً بعد 24 ساعة أو بمجرد استخدامها بنجاح لمرة واحدة، مما يمنع هجمات التخمين وإعادة الاستخدام.