لقد قمت مؤخرًا بترقية نسخة Discourse الخاصة بي إلى Discourse/2.9.0.beta14 أحدث إصدار من Discourse/2.9.0.beta3.
توقفت أحداث Discourse webhook عن العمل الآن.
هذا هو التكوين
عنوان URL للحمولة: http://server-name:port/rest: هذه هي خدمة واجهة برمجة التطبيقات الداخلية التي حددناها.
عندما أحاول حفظ هذه القيمة، فإنها تعطي الخطأ التالي:
“حدث خطأ: لا يمكن استخدام عنوان URL للحمولة لأنه يؤدي إلى عنوان IP محظور أو داخلي”
نفس القيمة لعنوان URL للحمولة: http://server-name:port/rest كانت تعمل بشكل جيد في
إصدار Discourse/2.9.0.beta3 discourse.
هل هناك شيء تم تحديثه في أحدث إصدار من Discourse، أم أن هذه مشكلة؟
هذا لا يبدو صحيحًا. قد يكون عنوان URL للحمولة للخطافات (webhooks) موردًا داخليًا بالفعل إذا كان Discourse مستضافًا ذاتيًا. لست متأكدًا لماذا ترغب في التوقف عن القدرة على تكوين عناوين URL أو العناوين التي يتم حلها داخليًا لمعالجة الخطافات (webhooks). يبدو أن هناك تغييرًا لمنع عناوين URL غير صالحة/سيئة لمواقع الويب في ملفات تعريف المستخدمين. هل تسلل هذا التغيير إلى التحقق من صحة عنوان URL للحمولة للخطافات (webhooks)؟
تتأثر نسختنا المستضافة ذاتيًا بهذا أيضًا. نود استضافة الخدمة التي تتلقى الويب هوك فقط على شبكة دوكر الداخلية؛ لا حاجة لأن تكون قابلة للوصول من الخارج.
هل هناك طريقة للسماح بالويب هوكات الداخلية؟
إذا فهمت المشكلة بشكل صحيح، فلا يُسمح بالويب هوكات الداخلية بحيث لا يمكن لمسؤول ديسكورس، الذي ليس لديه صلاحية مسؤول خادم، التجسس على الشبكة الداخلية. ومع ذلك، هذه ليست مشكلة في نسختنا المستضافة ذاتيًا؛ سيعرف مسؤولو ديسكورس لدينا هيكلنا الداخلي على أي حال.
أقترح إعدادًا في ملف الإعداد app.yml للسماح بالويب هوكات الداخلية، أو توفير قائمة بيضاء بالنطاقات/عناوين IP الداخلية. بهذه الطريقة، يظل مسؤول الخادم (وليس مسؤول ديسكورس) متحكمًا في من يمكنه استخدام الويب هوكات للشبكة الداخلية.