أداة التحقق من توقيع webhook.
الصق حمولة webhook، والمفتاح السري للتوقيع، والتوقيع الذي استلمته. تحسب هذه الأداة HMAC (بخوارزمية SHA-256 أو SHA-1) باستخدام Web Crypto API وتخبرك ما إذا كان يطابق. أداة عامة — تعمل مع أي webhook موقّع بـ HMAC. لا شيء يغادر جهازك.
استخدم البايتات تمامًا كما وردت — إعادة تسلسل JSON تُغيّر قيمة الهاش.
تم حساب HMAC أدناه. الصق توقيعًا للتحقق من مطابقته.
كل شيء يعمل محليًا عبر Web Crypto API — الحمولة والمفتاح السري لا يغادران هذه الصفحة أبدًا. يُفضَّل استخدام مفتاح اختباري بدلًا من مفتاح إنتاج حقيقي في أي أداة عبر الإنترنت.
الإجابة المختصرة
ما هو توقيع webhook؟
توقيع webhook هو هاش مُفتاح — أي HMAC — لجسم الطلب، يحسبه المُرسِل باستخدام مفتاح سري يشترك فيه الطرفان ويُرسله مرفقًا بالطلب، عادةً في ترويسة (header). وللتحقق منه، تُعيد حساب HMAC على الجسم الخام تمامًا بنفس المفتاح والخوارزمية وتقارن النتيجتين. تطابق النتيجتين يثبت أن الحمولة صادرة عن جهة تملك المفتاح السري ولم تُعدَّل أثناء النقل. فهو يُثبت المصدر ويحمي السلامة — ولا يُشفّر الحمولة.
كيفية التحقق من التوقيع بشكل صحيح
- التقط جسم الطلب الخام قبل أي تحليل. إعادة تسلسل JSON تُعيد ترتيب المفاتيح والمسافات، ما يُغيّر قيمة الهاش.
- احسب HMAC باستخدام المفتاح السري المشترك ودالة الهاش الخاصة بالمُرسِل (عادةً SHA-256 في معظم الواجهات البرمجية الحديثة).
- حوّل النتيجة إلى صيغة hex وقارنها بترويسة التوقيع، متجاهلاً أي بادئة نظام مثل sha256=.
- في بيئة الإنتاج، قارن باستخدام دالة تساوٍ ذات وقت ثابت لتجنّب هجمات القياس الزمني، وارفض الطلبات القديمة باستخدام الطابع الزمني الذي يوقّعه المزوّد.
الأسئلة الشائعة
ما هو توقيع webhook؟
توقيع webhook هو هاش مُفتاح (HMAC) لجسم الطلب، يحسبه المُرسِل باستخدام مفتاح سري مشترك ويُرسله في ترويسة. يعيد المستقبِل حساب HMAC على الجسم الخام تمامًا بنفس المفتاح ويقارن — فإذا تطابقا، تكون الحمولة أصلية ولم تُعدَّل. يثبت ذلك المصدر والسلامة دون تشفير الحمولة.
كيف أتحقق من توقيع HMAC لـ webhook؟
خذ جسم الطلب الخام تمامًا (قبل أي تحليل أو إعادة تسلسل لـ JSON)، احسب HMAC باستخدام المفتاح السري المشترك وخوارزمية الهاش الخاصة بالمُرسِل (عادةً SHA-256)، ثم حوّل النتيجة إلى صيغة hex. قارنها بترويسة التوقيع متجاهلًا أي بادئة مثل 'sha256='. إذا تساويا، فالتوقيع صحيح.
لماذا لا يتطابق توقيعي؟
الأسباب الشائعة: أُعيد تسلسل الجسم فاختلف بايتًا عن الأصل الموقَّع؛ استخدام مفتاح أو خوارزمية هاش خاطئة؛ توقيع المزوّد لسلسلة تتضمن أيضًا طابعًا زمنيًا أو بادئة إصدار؛ أو عدم تطابق ترميز hex مقابل base64. احسب الهاش دائمًا على البايتات الخام تمامًا كما وردت.
هل من الآمن لصق مفتاح سري حقيقي هنا؟
الحساب يعمل بالكامل داخل متصفحك عبر Web Crypto API — لا شيء يُرفَع أو يُسجَّل. كعادة عامة، يُفضَّل مع ذلك استخدام مفتاح اختباري بدلًا من مفتاح إنتاج حقيقي في أي أداة عبر الإنترنت، وتدوير أي مفتاح تشتبه بتسريبه.
هل أستخدم SHA-256 أم SHA-1؟
استخدم HMAC-SHA-256. تُتاح SHA-1 هنا فقط لأن بعض المزوّدين القدامى ما زالوا يرسلون توقيعات SHA-1. يجب أن تعتمد عمليات التكامل الجديدة على SHA-256.
هل يُشفّر التوقيع حمولتي؟
لا. يُثبت توقيع HMAC صحة الحمولة ويُثبت أنها لم تُعبَث بها، لكن الجسم لا يزال يُرسَل نصًا واضحًا. استخدم HTTPS (TLS) لضمان السرية؛ التوقيع يتعلق بالمصدر والسلامة، لا بالسرية.
لماذا تتم المقارنة بوقت ثابت في بيئة الإنتاج؟
يمكن لمقارنة نصية ساذجة أن تكشف عدد الأحرف الأولى المتطابقة من خلال فروقات زمنية دقيقة، ما قد يستغله مهاجم لتزوير توقيع. في بيئة الإنتاج، قارن باستخدام دالة ذات وقت ثابت مثل crypto.timingSafeEqual. أداة المتصفح هذه تقارن مباشرةً لأنه لا يوجد مهاجم عن بُعد يقيس التوقيت.
تحقّق من أي webhook موقّع بـ HMAC.
تعمل هذه الأداة مع أي مزوّد يوقّع webhooks بـ HMAC. وعندما تكون مستعدًا للبناء، توفّر BroadNet واجهة REST API بمصادقة رمز Bearer، وwebhooks لإيصالات التسليم، وارتباطات SMPP 3.4 مباشرة.