آمل أن يتمكن شخص ما من إخباري بما أفعله بشكل خاطئ هنا.
لقد قمت بإعداد Discourse Webhook وهو يعمل كما هو متوقع بدون سر. ثم أكتب سلسلة نصية في السر، ثم أنسخ تلك السلسلة النصية إلى Webhook المستقبل كرأس، على النحو التالي:
X-Discourse-Event-Signature: secret_here
ينتج عن هذا الخطأ التالي في الجسم عند إرسال Webhook المرسل:
{"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}
أتوقع أنني فقط لا أفعل ذلك بشكل صحيح، لذا يرجى إرشادي!
أدرك أن السر مشفر باستخدام sha256، لذا فإن الرأس المرسل هو:
X-Discourse-Event-Signature: sha256=XXX
لكنني لست متأكدًا مما يجب أن أفعله بهذه المعلومات في رؤوس أمان Webhook المستقبل.
لست متأكدًا مما إذا كانت هذه هي الطريقة التي تكتب بها المنشور، ولكن العنوان الفعلي سيكون
X-Discourse-Event-Signature: XXX
يمكنك (اختياريًا) استخدام هذا في الطرف المستقبل للتحقق من أن Discourse أرسل بالفعل طلب الويب. إذا لم تقم بالتحقق، فقد يقوم طرف خبيث بتزوير أحداث طلب الويب.
قد يتم تضمين رؤوس أمان مخصصة في مشغل خطاف الويب الوارد، ولكن هناك ملاحظة مهمة حول كيفية قيام ووردبريس بتغيير الشرطات إلى شرطات سفلية. على سبيل المثال، قد يتطلب استخدام “x-api-key” استخدام “x_api_key” بدلاً من ذلك.
لدي سؤال ذو صلة على الرغم من ذلك @RGJ . لنفترض أن سري هو “1234”. في خطاف الويب المستلم، هل يجب أن تكون قيمة X-Discourse-Event-Signature هي:
لقد اكتشفت منذ ذلك الحين أن قيمة sha تتغير في كل مرة يتم فيها إرسال الـ webhook، لذا فإن وضع قيمة sha في الـ webhook المستقبل لن ينجح. أعتقد أنه يجب أن يكون المثال رقم 1، وكما أعتقد أنك تقترح (رأس ثابت)، هل سيحتاج المكون الإضافي فعليًا إلى فك تشفير التجزئة قبل إنشاء استجابة الرأس؟
في الختام، لا أعتقد أنه يمكنني استخدام X-Discourse-Event-Signature المجزأة في هذا المكون الإضافي، لأنه سيقبل فقط القيم الثابتة.
هل من غير الآمن استخدام webhook بدون سر؟ سأقوم بإرسال أحداث المستخدم من Discourse الخاص بي إلى موقعي الرئيسي، باستخدام عنوان URL غير واضح مثل main-site.com/wp-json/fol/fil/532563-5312534. يمكنني أيضًا إضافة رؤوس ثابتة يجب أن تتطابق في الخطاف المستقبل.
هل يمكنك إعطائي مثالاً لتطبيق يمكنه التعامل مع hmac متغير ديناميكيًا؟
يتم حساب القيمة مقابل حمولة الـ webhook، لذا ستكون مختلفة لكل طلب.
هذا سؤال مثير للاهتمام. التطبيق الوحيد الذي أعرفه هو إضافة WP Discourse، لكن تم تكوينه خصيصًا للتعامل مع webhooks الخاصة بـ Discourse. إذا كان تطبيق Discourse يمنع الأشخاص من التحقق من صحة webhooks باستخدام الأسرار، فقد يحتاج ذلك إلى التحقيق.
سأترك ذلك للآخرين للإجابة عليه.
إذا كنت قلقًا بشأن عدم التحقق من صحة الـ webhook، فربما تحتوي إضافة Incoming Webhook Triggers على خطاف إجراء في رمز استقبال الـ webhook الخاص بها والذي يتم تشغيله قبل معالجة بيانات الـ webhook. إذا كان الأمر كذلك، فيجب أن يكون من الممكن كتابة دالة تتصل به، وتتحقق مما إذا كانت البيانات خاصة بـ webhook Discourse، ثم تتحقق من صحة السر باستخدام شيء مثل الكود الذي ربطته في منشوري السابق.
كنت فضوليًا، لذلك بحثت في هذا الأمر قليلاً. لست متأكدًا من التطبيقات التي تم تكوينها للتعامل مع استلام توقيع HMAC متغير ديناميكيًا، ولكن المصادقة على طلبات الويب هوك باستخدام توقيع HMAC الذي يتم حسابه مقابل الحمولة هو ممارسة قياسية إلى حد ما للتطبيقات التي ترسل طلبات الويب هوك. على سبيل المثال، تستخدم GitHub و Stripe و Shopify هذه الطريقة.
هناك أيضًا عدد غير قليل من التطبيقات الشائعة التي تستخدم طريقة الرمز السري للمصادقة على طلبات الويب هوك. على سبيل المثال (حتى عام 2021) تستخدم Mailchimp و Trello و Slack و Discord هذا النهج. يبدو أن Slack لا تزال تستخدم هذه الطريقة: Slack developer FAQ | Slack Developer Docs. يمكنني أن أرى كيف أن ذلك سيسهل الأمور على التطبيق الذي يتلقى طلب الويب هوك.
أعتقد أن هناك مفاضلة بين الأمان والراحة فيما يتعلق بتحديد الطريقة التي سيستخدمها التطبيق المرسل. قلقي بشأن طريقة توقيع HMAC الخاصة بـ Discourse هو أنها قد تؤدي إلى قيام الأشخاص بتكوين طلبات الويب هوك بدون مفاتيح سرية للتغلب على صعوبة التعامل مع توقيعات HMAC المتغيرة. على سبيل المثال، هناك عدد قليل من الإشارات في Meta لإرسال طلبات الويب هوك الخاصة بـ Discourse إلى Zapier دون أي ذكر لكيفية التحقق من صحة التوقيع على Zapier. (يجب أن يكون من الممكن تقنيًا التحقق من صحة التوقيعات على Zapier على الرغم من ذلك. أنا لست مستعدًا لاختبار ذلك في الوقت الحالي.)
