شرح Webhooks: الحمولات الموقعة وإعادة المحاولة الموثوقة

Backend2026-10-20TryQuickToolBox

لقد قمت للتو بدمج بوابة دفع خارجية أو خدمة CI/CD، والآن تحتاج إلى إشعارات فورية. webhooks هي الحل - ولكن بدون أمان وموثوقية مناسبين، يمكن أن تصبح مصدرًا للإحباط. يمكن للمهاجمين انتحال الطلبات، ويمكن أن تؤدي الأعطال الشبكية إلى فقدان الأحداث. في هذا الدليل، سنستعرض تأمين webhooks باستخدام الحمولات الموقعة وتنفيذ آليات إعادة محاولة قوية.

ما هي webhooks؟

webhooks هي عمليات استدعاء HTTP محددة من قبل المستخدم يتم تشغيلها بواسطة أحداث معينة. عندما يحدث حدث (مثل نجاح الدفع)، ترسل الخدمة المصدر طلب HTTP POST إلى عنوان URL الذي تقدمه، يحتوي على بيانات الحدث. هذا النموذج الدفعي أكثر كفاءة من الاستقصاء ويمكّن من ردود الفعل في الوقت الفعلي.

ومع ذلك، تقدم webhooks تحديين: الأصالة (ضمان أن الطلب من المرسل المتوقع) والموثوقية (ضمان عدم تفويت الأحداث).

تأمين webhooks باستخدام الحمولات الموقعة

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

كيف يعمل توقيع HMAC

HMAC (رمز مصادقة الرسائل القائم على التجزئة) هو النهج القياسي. يحسب المرسل HMAC على جسم الطلب باستخدام السر المشترك ويضمه في رأس مثل X-Signature. يعيد المستقبل حساب HMAC ويقارنه.

// مثال: إنشاء توقيع في Node.js
const crypto = require('crypto');

function generateSignature(payload, secret) {
  return crypto
    .createHmac('sha256', secret)
    .update(JSON.stringify(payload))
    .digest('hex');
}

// على الطرف المتلقي، تحقق:
function verifySignature(payload, secret, receivedSignature) {
  const expected = generateSignature(payload, secret);
  // استخدم مقارنة آمنة زمنياً لمنع هجمات التوقيت
  return crypto.timingSafeEqual(
    Buffer.from(expected, 'hex'),
    Buffer.from(receivedSignature, 'hex')
  );
}

النقاط الرئيسية:

إجراءات أمان إضافية

تنفيذ إعادة المحاولة الموثوقة

الشبكات غير موثوقة. قد تفشل webhook بسبب المهلات أو أخطاء الخادم أو الانقطاعات المؤقتة. تضمن استراتيجية إعادة المحاولة القوية التسليم النهائي دون إرباك نظامك أو المرسل.

أفضل ممارسات إعادة المحاولة

  1. التراجع الأسي: زيادة التأخير بين المحاولات (مثل 1 ثانية، 2 ثانية، 4 ثوانٍ، 8 ثوانٍ...).
  2. الحد الأقصى لإعادة المحاولة: تحديد عدد المحاولات (مثل 5) لتجنب الحلقات اللانهائية.
  3. قائمة الانتظار الميتة: بعد استنفاد المحاولات، قم بتخزين الأحداث الفاشلة للفحص اليدوي.
  4. الاتساق الذاتي: تأكد من أن معالجة نفس الحدث عدة مرات لا تسبب آثارًا جانبية مكررة.

الاتساق الذاتي في الممارسة

ضمّن معرف حدث فريد في الحمولة. على جانب المستقبل، تتبع المعرفات المعالجة (في قاعدة بيانات أو ذاكرة تخزين مؤقت) وتجاهل التكرارات. على سبيل المثال:

// كود زائف للمعالجة المتسقة ذاتيًا
if (eventStore.exists(event.id)) {
  return 200; // تمت المعالجة بالفعل
}
// معالجة الحدث...
eventStore.save(event.id);

التعامل مع الفشل بسلاسة

استجب بسرعة بحالة 2xx لتأكيد الاستلام. إذا استغرقت المعالجة وقتًا، فضع الحدث في قائمة الانتظار وعالجه بشكل غير متزامن. أعد 5xx فقط للأخطاء المؤقتة التي تستدعي إعادة المحاولة؛ للأخطاء الدائمة (مثل حمولة غير صالحة)، أعد 4xx لمنع المحاولات غير المجدية.

مقارنة: الدفع مقابل الاستقصاء

الجانب webhooks (الدفع) الاستقصاء
زمن الاستجابة شبه فوري يعتمد على الفاصل الزمني
الكفاءة يرسل فقط عند الأحداث طلبات مستمرة
التعقيد يتطلب منطق إعادة المحاولة/الأمان أبسط لكنه مهدور

اختبار تنفيذ webhook الخاص بك

استخدم أدوات مثل ngrok لكشف خادمك المحلي ومحاكاة تسليم webhooks. تحقق من صحة التوقيع وسلوك إعادة المحاولة عن طريق فشل الطلبات عمداً.

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

ما هي حمولة webhook الموقعة؟

تتضمن الحمولة الموقعة توقيعًا تشفيريًا (غالبًا HMAC) يسمح للمستقبل بالتحقق من أصالة الطلب وسلامته باستخدام سر مشترك.

كم مرة يجب أن أعيد محاولة webhook فاشل؟

لا يوجد رقم عالمي، لكن 3-5 محاولات مع تراجع أسي شائعة. بعد ذلك، سجل الفشل للمراجعة اليدوية.

هل يمكنني استخدام webhooks بدون HTTPS؟

من الناحية التقنية نعم، لكنه غير آمن للغاية. استخدم دائمًا HTTPS لمنع التنصت وهجمات الوسيط.

هل أنت مستعد لفحص حمولات webhook؟ استخدم منسق JSON الخاص بنا لطباعة وتنسيق حمولات JSON والتحقق منها بسرعة.