استكشاف مشكلات خدمة التطبيقات وإصلاحها فيApplication Gateway
تعرف على كيفية تشخيص وحل المشكلات التي قد تواجهها عند استخدام Azure App Service كهدف خلفي مع Azure Application Gateway.
نظرة عامة
في هذه المقالة، ستتعلم كيفية استكشاف المشكلات التالية وإصلاحها، كما هو موضح بمزيد من التفصيل في Architecture Center: الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي الخاص به
- عناوين URL مطلقة غير صحيحة
- عناوين URL غير صحيحة لإعادة التوجيه
- يتم عرض عنوان URL لخدمة التطبيق في المستعرض عند وجود إعادة توجيه
- مثال على ذلك: تدفق مصادقة OIDC مقطوع بسبب إعادة توجيه مع اسم مضيف خاطئ؛ يتضمن ذلك استخدام مصادقة خدمة التطبيقات والتخويل
- ملفات تعريف الارتباط المقطوعة
- لا يتم نشر ملفات تعريف الارتباط بين المستعرض وخدمة التطبيقات
- مثال على ذلك: يتم تعيين مجال ملف تعريف الارتباط ARRAffinity لخدمة التطبيق إلى اسم مضيف خدمة التطبيق ويرتبط ب "example.azurewebsites.net"، بدلا من المضيف الأصلي. ونتيجة لذلك، يتم قطع ترابط الجلسة.
السبب الجذري للأعراض المذكورة أعلاه هو إعداد يتجاوز اسم المضيف كما هو مستخدم من قبل Application Gateway تجاه App Service في اسم مضيف مختلف كما يراه المستعرض. غالبا ما يتم تجاوز اسم المضيف إلى مجال "azurewebsites.net" الافتراضي لخدمة التطبيقات.
عينة التكوين
في حالة تطابق التكوين مع حالة من الحالات التالية، يخضع الإعداد للإرشادات الواردة في هذه المقالة:
- تم تمكين اختيار اسم المضيف من عنوان الواجهة الخلفية في HTTP الإعدادات
- يتم تعيين التجاوز باسم مجال معين إلى قيمة مختلفة عن ما يحتوي عليه طلب المستعرض
السبب
خدمة التطبيقات هي خدمة متعددة المستأجرين؛ لذا فهي تستخدم رأس المضيف في الطلب لتوجيه الطلب إلى نقطة النهاية الصحيحة. اسم المجال الافتراضي لخدمات التطبيقات، * .azurewebsites.net (على سبيل المثال: contoso.azurewebsites.net)، يختلف عن اسم مجال بوابة التطبيق (على سبيل المثال: contoso.com). تفتقد خدمة تطبيق الواجهة الخلفية للسياق المطلوب لإنشاء عناوين URL أو ملفات تعريف الارتباط لإعادة التوجيه التي تتوافق مع المجال كما يراها المستعرض.
Solution
الحل الموصى به للإنتاج هو تكوين Application Gateway وApp Service لعدم تجاوز اسم المضيف. اتبع إرشادات "المجال المخصص (مستحسن)" في تكوين خدمة التطبيقات باستخدام بوابة التطبيق
فكر فقط في تطبيق حل بديل آخر (مثل إعادة كتابة عنوان الموقع كما هو موضح أدناه) بعد تقييم الآثار كما هو موضح في المقالة: الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي الخاص به. تتضمن هذه الآثار المحتملة لملفات تعريف الارتباط المرتبطة بالمجال وبالنسبة لعنوان URL المطلق خارج عنوان الموقع، للبقاء معطلا.
الحل البديل: إعادة كتابة رأس الموقع
تحذير
يأتي هذا التكوين مع قيود. نوصي بمراجعة الآثار المترتبة على استخدام أسماء مضيفين مختلفة بين العميل وبوابة التطبيق وبين التطبيق وخدمة التطبيقات في الخلفية. لمزيد من المعلومات، يرجى مراجعة المقالة في Architecture Center: الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي الخاص به
قم بتعيين اسم المضيف في رأس الموقع على اسم مجال بوابة التطبيق. للقيام بذلك، قم بإنشاء قاعدة إعادة كتابة بشرط يقيم ما إذا كان عنوان الموقع في الاستجابة يحتوي على azurewebsites.net. يجب أيضًا تنفيذ إجراء لإعادة كتابة رأس الموقع للحصول على اسم مضيف بوابة التطبيق. لمزيد من المعلومات، راجع إرشادات حول كيفية إعادة كتابة عنوان الموقع.
إشعار
يتوفر دعم إعادة كتابة عنوان HTTP فقط Standard_v2 WAF_v2 SKU لبوابة التطبيق. نوصي بالترحيل إلى الإصدار 2 لإعادة كتابة العنوان والقدرات المتقدمة الأخرى المتوفرة مع v2 SKU.