مفتش طلب Webhook

الصق طريقة خطاف الويب والرؤوس والنص لفحص الطلب وإنشاء أمر اختبار قابل للنسخ.

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

وجود حقل توقيع لا يثبت أن الطلب حقيقي — التحقق الفعلي يتطلب قواعد توقيع المرسل، والسر أو المفتاح، وبايتات الطلب الأصلية.

اختبار cURL المحلي
تفحص الطلب لرؤية هذه المخرجات.

يظل طلبك الذي تم لصقه في متصفحك. لا يقوم BroBroGo بتحميله أو حفظه.

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

ما هي تنسيقات نص خطاف الويب التي يمكنني فحصها؟

تم الكشف عن نصوص النماذج JSON وURL المشفرة وتنسيقها. تظل الهيئات الأخرى كنص عادي حتى لا تتمكن الأداة من تخمين محتوى XML أو متعدد الأجزاء أو الثنائي.

هل العثور على حقل توقيع يثبت صحة الطلب؟

لا. تعرض الأداة فقط التوقيع ورؤوس الطوابع الزمنية ذات الصلة. يحتاج التحقق الحقيقي إلى قواعد التوقيع الدقيقة للمرسل، والمفتاح السري أو العام، ووحدات بايت الطلب الأصلية.

هل يمكن لهذه الصفحة تلقي رد اتصال مباشر عبر الويب؟

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

فهم بنية طلبات الويب (Webhook Requests)

تُعد طلبات الويب (Webhooks) وسيلة أساسية لربط الأنظمة المختلفة ونقل البيانات الفورية عند حدوث أحداث معينة. لفهم كيفية تفاعل هذه الأنظمة، يحتاج مطورو واجهات برمجة التطبيقات (API developers) ومهندسو التكامل (Integration engineers) إلى فحص بنية الطلب الوارد بدقة. يتكون طلب الويب بشكل أساسي من ثلاثة أجزاء: طريقة الطلب، والرؤوس، وجسم الطلب (Body).

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


دور الرؤوس في اتصالات الويب

تلعب الرؤوس دوراً حاسماً في توجيه وتأمين اتصالات الويب. فهي تحمل معلومات تعريفية مثل نوع المحتوى (Content-Type) وبيانات الاعتماد، بالإضافة إلى الطوابع الزمنية وتواقيع الأمان.

عند استخدام الأداة، يتم إدخال الرؤوس بمعدل رأس واحد لكل سطر بتنسيق "الاسم: القيمة". وتخضع المدخلات للقيود التالية:

  • الحد الأقصى لعدد الأسطر: 200 سطر رأس غير فارغ كحد أقصى.
  • الحد الأقصى لعدد الأحرف: 100,000 حرف للرؤوس.

إذا تجاوزت المدخلات هذه الحدود، ستظهر رسائل الخطأ المحددة لمنع معالجة البيانات غير الصالحة.


تنسيقات جسم الطلب وأهمية المحتوى الخام

يأتي جسم طلب الويب عادةً بتنسيقات مختلفة، وأكثرها شيوعاً هو JSON أو البيانات المشفرة بترميز عنوان URL (URL-encoded form data). للحصول على تحليل دقيق، يجب دائماً استخدام النص الأولي الدقيق الذي تم التقاطه قبل أي تحليل من جانب الخادم (raw body content).

تتعامل الأداة مع جسم الطلب وفق القواعد التالية:

  • الحد الأقصى لحجم الجسم: 1,000,000 حرف كحد أقصى.
  • تحليل JSON: يتم تحليل نصوص JSON باستخدام JSON.parse وإعادة ترتيبها، مما يعني فقدان المسافات البيضاء الأصلية وترتيب الحقول الأصلي.
  • التنسيقات الأخرى: يتم الكشف عن نصوص JSON والبيانات المشفرة بترميز URL وتنسيقها تلقائياً، بينما تظل التنسيقات الأخرى كنص عادي.
  • الجسم الفارغ: إذا كان الطلب لا يحتوي على محتوى، تعرض الأداة عبارة "(جسم فارغ)".

التحقق من التواقيع والطوابع الزمنية لخطافات الويب

تستخدم العديد من الخدمات الأمنية تواقيع رقمية (Signatures) وطوابع زمنية (Timestamps) في الرؤوس لتمكين المستلم من التحقق من مصدر الطلب ومنع هجمات إعادة التشغيل.

تقوم الأداة بفحص الرؤوس بحثاً عن أنماط الأسماء الشائعة المرتبطة بالتواقيع مثل signature و hmac و digest والطوابع الزمنية الشائعة. ومع ذلك، يجب التمييز بوضوح بين فحص وجود هذه الحقول وبين عملية التحقق الفعلية من صحتها.

إن الأداة لا تقوم بحساب HMAC، ولا تنفذ أي خوارزميات تشفير، ولا تقارن البايتات الأصلية للحمولة، ولا تتحقق من السر أو نافذة إعادة التشغيل. إذا لم يتم العثور على أي من هذه الحقول، تعرض الأداة عبارة "لم يتم العثور على رأس مشترك أو طابع زمني لخطاف الويب.".


استخدام cURL للاختبار المحلي

بعد فحص الطلب وفهم بنيته، يحتاج مهندسو الصيانة والأتمتة إلى إعادة إرسال الطلب محلياً لاختبار كود المعالجة. تولد الأداة أمر cURL مقتبساً وجاهزاً للاستخدام في بيئة التطوير المحلية.

يتم توجيه أمر cURL الناتج دائماً إلى عنوان ثابت ومحدد محلياً وهو: http://localhost:3000/webhooks

يسمح هذا الأمر بمحاكاة وصول طلب الويب إلى خادم التطوير المحلي لديك بنفس الرؤوس والجسم الذي تم فصصه دون الحاجة لإعادة إرساله من الخدمة الخارجية.


معالجة الأخطاء والقيود أثناء الفحص

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

الحالة رسالة الخطأ المعروضة
محاولة الفحص دون إدخال بيانات "الصق رأسًا واحدًا أو نص طلب واحدًا على الأقل أولاً."
تجاوز طول الرؤوس المسموح به "الرؤوس طويلة جدًا بالنسبة لهذه الأداة. قم بإزالة القيم غير المرتبطة أو المتكررة."
تجاوز حجم جسم الطلب للحد الأقصى "الجسم طويل جدًا بالنسبة لهذه الأداة. اجعلها أقل من 1,000,000 حرف."
تجاوز عدد أسطر الرؤوس عن 200 "يوجد عدد كبير جدًا من سطور الرأس. احتفظ بالطلب إلى 200 رأس أو أقل."
كتابة رأس بتنسيق خاطئ "‹line›: سطر الرأس غير صالح. اسم الاستخدام: القيمة."
وجود خطأ في تركيب صيغة JSON "يبدو النص مثل JSON ولكن لا يمكن تحليله."
خطأ في ترميز النسبة المئوية للنموذج "يحتوي نص النموذج على نسبة هروب غير مكتملة."

خصوصية البيانات ومعالجتها

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


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

هل يمكن لهذه الصفحة تلقي رد اتصال مباشر عبر الويب؟

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

ما هي تنسيقات نص خطاف الويب التي يمكنني فحصها؟

تم الكشف عن نصوص النماذج JSON وURL المشفرة وتنسيقها. تظل الهيئات الأخرى كنص عادي حتى لا تتمكن الأداة من تخمين محتوى XML أو متعدد الأجزاء أو الثنائي.

هل العثور على حقل توقيع يثبت صحة الطلب؟

لا. تعرض الأداة فقط التوقيع ورؤوس الطوابع الزمنية ذات الصلة. يحتاج التحقق الحقيقي إلى قواعد التوقيع الدقيقة للمرسل، والمفتاح السري أو العام، ووحدات بايت الطلب الأصلية.