تكوين الإعدادات HTTP لبوابة التطبيق
توجه بوابة التطبيق نسبة استخدام الشبكة إلى الخوادم الخلفية باستخدام التكوين الذي تحدده هنا. بعد إنشاء إعداد HTTP، يجب عليك ربطه بواحد أو أكثر من قاعد تحويل الطلبات.
التقارب المستند إلى ملفات تعريف الارتباط
تستخدم بوابة التطبيق Azure ملفات تعريف الارتباط المدارة عبر البوابة للحفاظ على جلسات المستخدم. عندما يرسل مستخدم الطلب الأول إلى "بوابة التطبيق"، فإنه يقوم بتعيين ملف تعريف ارتباط تقارب في الاستجابة بقيمة تجزئة الذي يحتوي على تفاصيل جلسة العمل، بحيث سيتم توجيه الطلبات اللاحقة التي تحمل ملف تعريف ارتباط تقارب إلى نفس الخادم الخلفي للحفاظ على الالتصاق.
هذه الميزة مفيدة عندما تريد الاحتفاظ بجلسة مستخدم على نفس الخادم وعندما يتم حفظ حالة الجلسة محليًا على الخادم لجلسة المستخدم. إذا لم يتمكن التطبيق من معالجة التقارب القائم إلى ملفات تعريف الارتباط، فلا يمكنك استخدام هذه الميزة. لكي يمكنك استخدامها، تأكد من أن العملاء دعم ملفات تعريف الارتباط.
إشعار
قد تضع بعض عمليات فحص الثغرات الأمنية علامة على ملف تعريف ارتباط ترابط بوابة التطبيق لأنه لم يتم تعيين علامات Secure أو HttpOnly. لا تأخذ عمليات الفحص في الاعتبار أن البيانات الموجودة في ملف تعريف الارتباط يتم إنشاؤها باستخدام تجزئة أحادية الاتجاه. لا يحتوي ملف تعريف الارتباط على أي معلومات مستخدم ويستخدم فقط للتوجيه.
جلب تحديث متصفحChromium v80 تفويضا حيث يجب التعامل مع ملفات تعريف الارتباط HTTP بدون سمة SameSite على أنها SameSite=Lax. بالنسبة لطلبات CORS (مشاركة الموارد عبر المنشأ)، إذا كان يجب إرسال ملف تعريف الارتباط في سياق جهة خارجية، فيجب عليه استخدام SameSite=None؛ يجب إرسال السمات الآمنة عبر HTTPS فقط. وإلا، في سيناريو HTTP فقط، لا يرسل المستعرض ملفات تعريف الارتباط في سياق الجهة الخارجية. الهدف من هذا التحديث من Chrome هو تعزيز الأمان وتجنب هجمات التزوير عبر الموقع (CSRF).
لدعم هذا التغيير، بدءًا من 17 فبراير 2020، ستقوم بوابة التطبيق (جميع أنواع SKU) بحقن ملف تعريف ارتباط آخر يسمى ApplicationGatewayAffinityCORS بالإضافة إلى ملف تعريف الارتباط ApplicationGatewayAffinity الحالي. يحتوي ملف تعريف ارتباط ApplicationGatewayAffinityCORS على سمتين إضافيتين تمت إضافتهما إليه ("SameSite=None; آمن") بحيث يتم الاحتفاظ بجلسات العمل الملصقة حتى للطلبات عبر المنشأ.
لاحظ أن اسم ملف تعريف الارتباط التقارب الافتراضي هو ApplicationGatewayAffinity ويمكنك تغييره. في حال كنت تستخدم اسم ملف تعريف ارتباط تقارب مخصص، تتم إضافة ملف تعريف ارتباط إضافي مع CORS كلاحقة. على سبيل المثال، Custom Cookie Name CORS .
إشعار
إذا تم تعيين السمة SameSite = None ، فمن الضروري أن يحتوي ملف تعريف الارتباط أيضًا على علامة Secure ، ويجب إرسالها عبر HTTPS. إذا كان تقارب الجلسة مطلوبًا عبر CORS، فيجب عليك ترحيل عبء العمل إلى HTTPS. يرجى الرجوع إلى إلغاء تحميل TLS ووثائق TLS الشاملة لبوابة التطبيق هنا - نظرة عامة و تكوين بوابة تطبيق مع إنهاء TLS باستخدام مدخل Microsoft Azure و تكوين النهاية- إلى نهاية TLS باستخدام Application Gateway مع المدخل .
استنزاف الاتصال
يساعدك الاتصال الاستنزاف على إزالة أعضاء تجمع الواجهة الخلفية بأمان أثناء تحديثات الخدمة المخطط لها. ينطبق على مثيلات الواجهة الخلفية التي
- تمت إزالته بشكل صريح من تجمع الواجهة الخلفية،
- تمت إزالته أثناء عمليات التحجيم، أو
- تم الإبلاغ عنها على أنها غير صحية من قبل الفحوصات الصحية.
يمكنك تطبيق هذا الإعداد على جميع أعضاء تجمع الخلفية عن طريق تمكين الاتصال استنزاف في إعداد الواجهة الخلفية. يضمن أن جميع مثيلات إلغاء التسجيل في تجمع الخلفية لا تتلقى أي طلبات/اتصالات جديدة مع الحفاظ على الاتصالات الموجودة حتى قيمة المهلة المكونة. ينطبق هذا أيضا على اتصالات WebSocket.
| نوع التكوين | القيمة |
|---|---|
| القيمة الافتراضية عند عدم تمكين استنزاف الاتصال في إعداد الواجهة الخلفية | 30 seconds |
| القيمة المعرفة من قبل المستخدم عند تمكين الاتصال استنزاف في إعداد الواجهة الخلفية | من 1 إلى 3600 ثانية |
الاستثناء الوحيد لهذا طلبات منضمة إلى إلغاء تسجيل مثيلات بسبب تقارب جلسة عمل إدارة البوابة و سوف يستمر إلى إعادة توجيه إلى مثيلات إلغاء التسجيل.
بروتوكول
تدعم بوابة التطبيق كلا من HTTP وHTTPS لتوجيه الطلبات إلى خوادم الواجهة الخلفية. إذا اخترت HTTP، فإن نسبة استخدام الشبكة إلى الخوادم الخلفية غير مشفرة. إذا لم يكن الاتصال غير المشفر مقبولًا، قم باختيار HTTPS.
هذا الإعداد مع HTTPS في المستمع يدعم نهاية إلى نهاية TLS . يتيح لك ذلك نقل البيانات الحساسة المشفرة إلى النهاية الخلفية بأمان. يجب تكوين كل خادم خلفي في تجمع الواجهة الخلفية الذي تم تمكين TLS من طرف إلى طرف بشهادة للسماح بالاتصال الآمن.
المنفذ
يحدد هذا الإعداد المنفذ حيث تستمع خوادم الواجهة الخلفية إلى نسبة استخدام الشبكة من بوابة التطبيق. يمكنك تكوين منافذ تتراوح من 1 إلى 65535.
شهادة الجذر الموثوق بها
إذا قمت بتحديد HTTPS كبروتوكول الواجهة الخلفية، تتطلب بوابة التطبيق شهادة جذر موثوق بها للثقة في تجمع الواجهة الخلفية ل SSL من طرف إلى طرف. بشكل افتراضي، يتم تعيين خيار استخدام شهادة المرجع المصدق المعروفة جيدا إلى لا. إذا كنت تخطط لاستخدام شهادة موقعة ذاتيا، أو شهادة موقعة من قبل مرجع مصدق داخلي، فيجب عليك توفير Application Gateway الشهادة العامة المطابقة التي سيستخدمها تجمع الواجهة الخلفية. يجب تحميل هذه الشهادة مباشرة إلى بوابة التطبيق في . تنسيق CER.
إذا كنت تخطط لاستخدام شهادة على تجمع الخلفية التي تم توقيعها من قبل مرجع مصدق عام موثوق به، يمكنك تعيين الخيار استخدام شهادة المرجع المصدق المعروفة جيدا إلى نعم وتخطي تحميل شهادة عامة.
انتهي وقت الطلب
هذا الإعداد هو عدد الثوابت التي تنتظرها بوابة التطبيق لتلقي استجابة من الخادم الخلفي.
تجاوز مسار الواجهة الخلفية
يتيح لك هذا الإعداد تكوين مسار إعادة توجيه مخصص اختياري لاستخدامه عندما يتم إعادة توجيه الطلب إلى النهاية الخلفية. يتم نسخ أي جزء من المسار الوارد الذي يطابق المسار المخصص في الحقل مسار الواجهة الخلفية للتجاوز إلى المسار المعاد توجيهه. يوضح الجدول الآتي كيفية عمل هذه الميزة:
عند إرفاق إعداد HTTP بقاعدة التحويل الطلب الأساسية:
طلب أصلي تجاوز مسار الواجهة الخلفية أطلب إعادة توجيهه إلى النهاية الخلفية /الصفحة الرئيسية/ /التجاوز/ / التجاوز /الصفحة الرئيسية / / الصفحة الرئيسية / الصفحة الرئيسية الثانية / /التجاوز/ / تجاوز / الصفحة الرئيسية / الصفحة الرئيسية الثانية / عند إرفاق إعداد HTTP إلى قاعدة التحويل الطلب القائمة إلى المسار:
طلب أصلي تصفية المسار تجاوز مسار الواجهة الخلفية أطلب إعادة توجيهه إلى النهاية الخلفية /تصفية المسار/الصفحة الرئيسية/ /تصفية المسار* /التجاوز/ / التجاوز /الصفحة الرئيسية / /تصفية المسار/الصفحة الرئيسية/الصفحة الرئيسية الثانية/ /تصفية المسار* /التجاوز/ / تجاوز / الصفحة الرئيسية / الصفحة الرئيسية الثانية / /الصفحة الرئيسية/ /تصفية المسار* /التجاوز/ / التجاوز /الصفحة الرئيسية / / الصفحة الرئيسية / الصفحة الرئيسية الثانية / /تصفية المسار* /التجاوز/ / تجاوز / الصفحة الرئيسية / الصفحة الرئيسية الثانية / /تصفية المسار/الصفحة الرئيسية/ /تصفية المسار/الصفحة الرئيسية* /التجاوز/ /التجاوز/ /تصفية المسار/الصفحة الرئيسية/الصفحة الرئيسية الثانية/ /تصفية المسار/الصفحة الرئيسية* /التجاوز/ /التجاوز/الصفحة الرئيسية/ /تصفية المسار/ /تصفية المسار/ /التجاوز/ /التجاوز/
استخدم التحقيق المخصص
يتم ربط هذا الإعداد تحقيقًا مخصصًا بإعداد HTTP. يمكنك إقران تحقيق مخصص واحد فقط بإعداد HTTP. إذا لم تقم بربط تحقيق مخصص بشكل صريح، يتم استخدام التحقيق الافتراضي لمراقبة صحة الطرف الخلفي. نوصي بإنشاء تحقيق مخصص لمزيد من التحكم في مراقبة صحة النهايات الخلفية.
إشعار
لا يراقب الفحص المخصص صحة تجمع الواجهة الخلفية ما لم يكن إعداد HTTP المقابل مقترنا بشكل صريح بمستمع.
تكوين اسم المضيف
تسمح بوابة التطبيق بالاتصال الذي تم إنشاؤه بالواجهة الخلفية لاستخدام اسم مضيف مختلف عن الاسم المستخدم من قبل العميل للاتصال ب Application Gateway. في حين أن هذا التكوين يمكن أن يكون مفيدا في بعض الحالات، يجب أن يتم تجاوز اسم المضيف ليكون مختلفا بين العميل وبوابة التطبيق وبوابة التطبيق إلى هدف الواجهة الخلفية بعناية.
في الإنتاج، يوصى بالاحتفاظ باسم المضيف المستخدم من قبل العميل تجاه بوابة التطبيق مثل نفس اسم المضيف المستخدم من قبل بوابة التطبيق إلى هدف الواجهة الخلفية. وهذا يتجنب المشكلات المحتملة مع عناوين URL المطلقة وعناوين URL لإعادة التوجيه وملفات تعريف الارتباط المرتبطة بالمضيف.
قبل إعداد Application Gateway التي ينحرف عنها، يرجى مراجعة الآثار المترتبة على هذا التكوين كما تمت مناقشته بمزيد من التفصيل في Architecture Center: الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي الخاص به
هناك جانبان من إعداد HTTP يؤثران على Host عنوان HTTP الذي تستخدمه بوابة التطبيق للاتصال بالواجهة الخلفية:
- "اختر اسم المضيف من عنوان الواجهة الخلفية"
- "تجاوز اسم المضيف"
اختيار اسم المضيف من عنوان الواجهة الخلفية
تعين هذه الإمكانية رأس المضيف ديناميكيا في الطلب إلى اسم مضيف تجمع الواجهة الخلفية. يستخدم عنوان IP أو FQDN.
تساعد هذه الميزة عندما يختلف اسم المجال للنهاية الخلفية عن اسم DNS لبوابة التطبيق، ويعتمد النهاية الخلفية على عنوان مضيف معين لحله إلى نقطة النهاية الصحيحة.
مثال على ذلك هو الخدمات متعددة المستأجرين باعتبارها النهاية الخلفية. خدمة التطبيق هي خدمة متعددة المستأجرين تستخدم مساحة مشتركة بعنوان IP موحد. لذلك، لا يمكن الوصول إلى خدمة التطبيق إلا من خلال أسماء المضيفين التي تم تكوينها في إعدادات المجال المخصصة.
بشكل افتراضي، اسم المجال المخصص هو example.azurewebsites.net . للوصول إلى خدمة التطبيق باستخدام بوابة تطبيق من خلال اسم مضيف غير مسجل بشكل صريح في خدمة التطبيق أو من خلال FQDN الخاص ببوابة التطبيق، يمكنك تجاوز اسم المضيف في الطلب الأصلي إلى اسم مضيف خدمة التطبيق. للقيام بذلك، قم بتمكين اختيار اسم المضيف من إعداد عنوان الخلفية.
بالنسبة لمجال مخصص تم تعيين اسم DNS المخصص الموجود له إلى خدمة التطبيق، فإن التكوين الموصى به ليس لتمكين اختيار اسم المضيف من عنوان الواجهة الخلفية.
إشعار
هذا الإعداد غير مطلوب لـ App Service Environment، وهو توزيع مخصص.
تجاوز اسم مضيف
يستبدل هذه الإمكانية عنوان المضيف في الطلب الوارد على بوابة التطبيق مع اسم المضيف الذي تحدده.
على سبيل المثال، إذا تم تحديد www.contoso.com في إعداد اسم المضيف، يتم تغيير الطلب الأصلي *https://appgw.eastus.cloudapp.azure.com/path1 إلى *https://www.contoso.com/path1 عند إعادة توجيه الطلب إلى الخادم الخلفي.