يا هلا بيك يا بشمهندس! لو بتطور نظام ويب (Web Development) وفي لحظة لقيت نفسك محتاج تربط السيرفر بتاعك بسيرفر تاني عشان يبعتوا لبعض تحديثات في الوقت الحقيقي (Real-time)، بنسبة كبيرة أنت استخدمت أو سمعت عن الـ Webhooks. بس خليني أخمن معاك.. هل حصل وربطت الـ Webhook بتاعك، وفجأة السيرفر التاني وقع (Server Downtop)، أو الداتا اتبعتت مرتين، أو الألعن من كده: جالكم طلب وهمي (Fake Request) من هكر بيلاعب السيرفر بتاعك؟ وجع دماغ صح؟

الموضوع ده مش لوحدك بتعاني منه، دي المشكلة الأزلية لأي مبرمج بيتعامل مع الـ Webhooks. عشان كده, في المقال ده هناخد رحلة تفصيلية وعملية بالعامية المصرية عشان نبني نظام Webhooks آمن وموثوق بنسبة 100%، ونتكلم بالتفصيل عن آليات إعادة الإرسال (Retries) وتوقيع البيانات لمنع التلاعب باستخدام الـ HMAC Signatures.

إيه هو الـ Webhook أساساً وليه بيعمل مشاكل؟

ببساطة شديدة، الـ Webhook هو عبارة عن "رسالة تنبيه" السيرفر بتاعك بيبعتها لسيرفر تاني أول ما حدث معين يحصل (زي مثلاً: عميل دفع الفاتورة، أو اشتراك جديد اتسجل). بدل ما السيرفر التاني يفضل كل شوية يسألنا "فيه جديد؟" (اللي بنسميها Polling)، الاحنا بنقوله: "خد اللينك ده، وأول ما حاجة تحصل هخبط عليك".

المشكلة فين بقى؟ المشكلة إن الانترنت مش مكان مثالي! أحياناً السيرفر اللي مستقبل الطلب هيكون مشغول، أو النت هيكون بطيء، أو الطلب هيضيع في السكة. لو السيرفر بتاعك بعت ومجاش رد (Response) بإن الداتا اتاستلمت بنجاح، الـ Webhook بيعتبر ضاع للأبد لو مكنتش عامل حسام. ومن الناحية التانية، لو السيرفر التاني مكنش متأكد إن الطلب جاي منك فعلاً، أي شخص ممكن يبعت لك طلبات وهمية ويبوظ لك الداتا بتاعتك.

الخطوة الأولى للأمان: توقيع البيانات باستخدام (HMAC Signatures)

تخيل حد عرف الرابط (Endpoint) بتاع الوعب هوك بتاعك، وقعد يبعت لك طلبات يقولك فيها "العميل الفلاني دفع فلوس"، وأنت صدقته وشحنت له الرصيد وهو مجاش أصلاً! مصيبة صح؟

الحل السحري هنا هو الـ HMAC (Hash-based Message Authentication Code). الفكرة باختصار إننا بنستخدم "سر مشترك" (Secret Key) موجود عندك وعند السيرفر اللي بيبعت الداتا بس. السيرفر المرسل بياخد الـ Payload (محتوى الرسالة) ويحسب له تشفير باستخدام السر ده، ويبعت التشفير ده جوه الـ Headers بتاع الـ HTTP (مثلاً في هيدر اسمه X-Hub-Signature).

أول ما الطلب يوصلك، أنت بتعمل نفس العملية على الداتا اللي وصلتك، وتقارن النتيجة باللي جالك في الهيدر. لو طلعوا طابقين بعض, يبقى الطلب ده ابن ناس وجاي من المصدر الصح. لو مش طابقين, يبقى ده هجوم (Spoofing Attack) وتطرده فوراً!

تعال نشوف مثال عملي بلغة بايثون (Python) أو فكرة البرمجة بلغة فلسفية واضحة:

import hmac
import hashlib

def verify_webhook_signature(request_body, received_signature, secret_key):
    # حساب التشفير باستخدام الـ Secret Key
    computed_signature = hmac.new(
        secret_key.encode('utf-8'),
        request_body,
        hashlib.sha256
    ).hexdigest()
    
    # مقارنة التشفير بأمان تام لمنع Timing Attacks
    return hmac.compare_digest(computed_signature, received_signature)

الموثوقية والاعتمادية: استراتيجيات إعادة الإرسال (Retries)

دلوقت ضمننا الأمان، تعال نضمن إن الرسالة توصل حتى لو السيرفر التاني واقع! في عالم الـ Web Development، الفشل أمر وارد جداً. عشان نبني نظام موثوق (Reliable)، لازم نعمل نظام Retries ذكي.

لو الـ Webhook فشل (يعني السيرفر التاني رجع HTTP Status Code مش في نطاق الـ 200، زي 500 أو 503، أو حصل Timeout)، المفروض منبعش فوراً وبشكل عشوائي، لأن ده ممكن يوقع سيرفر الزبون أكتر! الصح هو استخدام استراتيجية اسمها Exponential BackOff مع Jitter.

يعني إيه Exponential BackOff؟

يعني بنزود وقت الانتظار بين كل محاولة تانية بشكل مضاعف:

• المحاولة الأولى: فشلت، استنى 5 ثوانٍ وجرب تاني.
• المحاولة التانية: فشلت، استنى 15 ثانية وجرب تاني.
• المحاولة التالتة: فشلت، استنى 60 ثانية وجرب تاني.
• وكل مرة بنضاعف المدة لحد حد أقصى (مثلاً 5 محاولات)، وبعدها بنسجل الحدث كـ "فشل دائم" (Dead Letter Queue) عشان المبرمج يتدخل يحل المشكلة.

هندسة طوابير الانتظار (Message Queues) للـ Webhooks

لو عندك آلاف الـ Webhooks اللي بتتبعت في نفس اللحظة، مينفعش تخلي الـ Main Thread في التطبيق بتاعك هو اللي يبعتها synchronously، لأن السيرفر هيعلق (Block). الحل الهندسي الصح هو استخدام Background Workers و Message Queues زي (RabbitMQ أو Redis/Celery أو AWS SQS).

العمارة بتبقى كالتالي:

• الحدث بيحصل في السيستم عندك.
• بترمي رسالة في الـ Queue بتقول: "يا جماعة ابعتوا الـ Webhook ده".
• الـ Worker بياخد الرسالة دي ويبعتها للسيرفر الخارجي.
• لو السيرفر رد بـ Success، بنعتبر المهمة تمت. لو رد بـ Error، العامل (Worker) بيرجع الرسالة للـ Queue مع تحديد وقت تنفيذ مستقبلي (Delayed Message / Retry).

خاتمة: نصيحة من أخ

يا بشمهندس، بناء نظام Webhooks احترافي وآمن مش مجرد كود requests.post() ترميه في السيرفر وخلاص. التفاصيل الصغيرة دي هي اللي بتفرق بين سيستم هاوي وسيستم إنتربرايز (Enterprise-grade) بيعتمد عليه شركات ضخمة. اهتم بالـ Security من خلال الـ HMAC Signatures، واهتم بالـ Reliability من خلال الـ Retries والـ Queues، ونومك هيبقى هادئ بالليل ومفيش عميل هيصحيك يقولك "التنبيهات بتاعتكم بتضيع!".