إعادة كتابة عناوين HTTP وعنوان URL مع بوابة التطبيق

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

تتوفر ميزات إعادة كتابة عنوان HTTP وعنوان URL فقط ل Application Gateway v2 SKU.

عناوين الطلب والاستجابة

تسمح لك بوابة التطبيق بإضافة عناوين طلب واستجابة HTTP أو إزالتها أو تحديثها أثناء انتقال حزم الطلب والاستجابة بين مجموعات العميل والواجهة الخلفية. رؤوس HTTP تسمح للعميل والخادم بتمرير معلومات إضافية مع طلب أو رد. من خلال إعادة كتابة هذه الرؤوس، يمكنك إنجاز مهام مهمة تشمل:

• إضافة حقول الرأس المتعلقة بالأمان مثل HSTS و X-XSS-Protection
• إزالة حقول رأس الاستجابة التي قد تكشف معلومات حساسة
• إزالة معلومات المنافذ من رؤوس X-Forwarded-For

يمكنك إعادة كتابة جميع الرؤوس في الطلبات والردود، باستثناء الرؤوس Connection و Upgrade . يمكنك أيضا استخدام بوابة التطبيق لإنشاء عناوين مخصصة وإضافتها إلى الطلبات والاستجابات التي يتم توجيهها من خلالها. لتعلم كيفية إعادة كتابة رؤوس الطلبات والرد باستخدام Application Gateway باستخدام بوابة Azure، راجع هنا.

مسار URL وسلسلة الاستعلام

مع إمكانية إعادة كتابة URL في Application Gateway، يمكنك:

• أعد كتابة اسم المضيف، المسار، وسلسلة الاستعلام في رابط الطلب

• اختر إعادة كتابة عنوان URL لجميع الطلبات على وحدة استماع أو فقط تلك الطلبات التي تطابق شرطا واحدا أو أكثر من الشروط التي قمت بتعيينها. تستند هذه الشروط إلى خصائص الطلب (عنوان الطلب ومتغيرات الخادم).

• اختر مسار الطلب (حدد تجمع الخلفية) استنادا إلى عنوان URL الأصلي أو عنوان URL المعاد كتابته

لتعلم كيفية إعادة كتابة عنوان URL باستخدام Application Gateway باستخدام بوابة Azure، راجع هنا.

فهم عمليات إعادة الكتابة في بوابة التطبيقات

مجموعة إعادة الكتابة هي مجموعة من قاعدة توجيه، شرط، وفعل.

• طلب ربط قواعد التوجيه: يرتبط تكوين إعادة الكتابة بالمستمع المصدر من خلال قاعدة التوجيه الخاصة به. عندما تستخدم قاعدة توجيه من النوع Basic، يرتبط تكوين إعادة الكتابة بالمستمع ويعمل كإعادة كتابة شاملة. عندما تستخدم قاعدة توجيه تعتمد على المسار، فإنك تعرف تكوين إعادة الكتابة وفقا لخريطة مسار URL. في الحالة الأخيرة، يتم تطبيقه فقط على منطقة مسار معينة من الموقع. يمكنك تطبيق مجموعة إعادة كتابة على عدة قواعد توجيه، لكن قاعدة التوجيه يمكن أن يكون لها إعادة كتابة واحدة فقط مرتبطة بها.

• شرط إعادة الكتابة: هذا التكوين اختياري. استنادا إلى الشروط التي تحددها، تقوم بوابة التطبيق بتقييم محتويات طلبات وردود HTTP(S). يحدث إجراء "إعادة الكتابة" التالي إذا كان طلب أو استجابة HTTP(S) تطابق هذا الحالة. إذا ربطت أكثر من شرط بإجراء، يحدث الإجراء فقط عند استيفاء جميع الشروط. بعبارة أخرى، هي عملية منطقية وأخرى. يمكنك استخدام شروط إعادة الكتابة لتقييم محتوى طلبات واستجابات HTTP(S). يمكنك هذا التكوين الاختياري من إجراء إعادة كتابة فقط عند استيفاء شرط واحد أو أكثر. تستخدم application gateway هذه الأنواع من المتغيرات لتقييم محتوى الطلبات والاستجابات:

  يمكنك اختيار الأنواع التالية للبحث عن شرط:

  • عنوان HTTP (الطلب والاستجابة)
  • متغيرات الخادم المدعومة

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

• إعادة كتابة العمل: مجموعة إجراءات إعادة الكتابة تتيح لك إعادة كتابة الرؤوس (طلب أو استجابة) أو مكونات الURL.

  يمكن أن يحتوي الإجراء على أنواع القيم التالية أو مجموعاتها:

  • نص
  • قيمة رأس الطلب - لاستخدام قيمة رأس الطلب الملتقط، حدد الصياغة ك {http_req_headerName}.
  • قيمة رأس الاستجابة - لاستخدام قيمة رأس الاستجابة الملتقطة من الشرط السابق، حدد الصيغة ك {http_resp_headerName}. تدعم كتلة إجراء إعادة الكتابة أيضا حقل "مطابقة قيمة الرأس" لرأس Set-Cookie. يتيح لك هذا الحقل الاختياري مطابقة والتقاط قيمة رأس معين عندما توجد عدة رؤوس Set-Cookie تحمل نفس الاسم. لمعالجة القيمة الملتقطة لملفات تعريف الارتباط المحددة، يمكنك بعد ذلك استخدام {capt_header_value_matcher}. تعرف على المزيد حول الالتقاط تحت مجموعة الأكشن.
  • متغير الخادم - لاستخدام متغير خادم، حدد بناء الجملة ك {var_serverVariable}. قائمة متغيرات الخادم المدعومة.

إشعار

استخدام حقل مطابقة قيمة الرأس {capt_header_value_matcher} غير مدعوم حاليا من خلال البوابة. لذلك، تحتاج إلى استخدام طريقة غير بوابة لأي عمليات PUT إذا استخدمت هذا الحقل.

عند استخدام إجراء لإعادة كتابة عنوان URL، تدعم العمليات التالية:

• مسار الرابط: القيمة الجديدة التي يجب تعيينها كمسار.
• سلسلة استعلام URL: القيمة الجديدة التي يجب إعادة كتابة سلسلة الاستعلام إليها.
• إعادة تقييم مخطط المسار: حدد ما إذا كان يجب إعادة تقييم مخطط مسار URL بعد إعادة الكتابة. إذا لم تقم باختيار هذا الخيار، يتم استخدام مسار URL الأصلي لمطابقة نمط المسار في خريطة مسار URL. إذا ضبطت هذا الخيار على true، يتم إعادة تقييم خريطة مسار URL للتحقق من المطابقة مع المسار المعاد كتابته. يساعد تمكين هذا التبديل في توجيه الطلب إلى إعادة كتابة منشور لتجمع خلفي مختلف.

مطابقة النمط والتقاطه

يدعم بوابة التطبيق مطابقة الأنماط والالتقاط تحت قسم الحالة والعمل. تحت وضع الإجراء، يدعم مطابقة الأنماط والالتقاط فقط لرأس معين.

مطابقة النمط

تستخدم بوابة التطبيق تعبيرات عادية لمطابقة النمط. استخدم تعبيرات متوافقة مع Regular Expression 2 (RE2) عند كتابة صياغة مطابقة النمط.

يمكنك استخدام مطابقة النمط ضمن كل من الشرط والإجراء.

• الشرط: استخدم هذا الإعداد لمطابقة قيم الرأس أو متغير الخادم. لمطابقة نمط تحت "الشروط"، استخدم خاصية "النمط".
• الإجراء: مطابقة النمط تحت مجموعة الإجراءات متاحة فقط لرأس Set-Cookieالرد . لمطابقة نمط تحت Set-Cookie إجراء، استخدم الخاصية HeaderValueMatcher . إذا تم التقاط، يمكن استخدام قيمته ك {capt_header_value_matcher}. نظرا لوجود عدة Set-Cookie رؤوس، فإن مطابقة الأنماط هنا تتيح لك البحث عن كوكيز معين. على سبيل المثال، لإصدار معين من user-agent، تريد إعادة كتابة set-cookie رأس الاستجابة ل cookie2 ( max-age=3600 ساعة واحدة). في هذه الحالة، يمكنك استخدام
  • Condition - النوع: عنوان الطلب، اسم العنوان: عامل المستخدم، النمط المراد مطابقته: *2.0
  • إجراء - نوع إعادة الكتابة: رأس الرد، نوع الإجراء: المجموعة، اسم الرأس: Set-Cookie، مطابق قيمة الرأس: cookie2=(.*)، قيمة الرأس: cookie2={capt_header_value_matcher_1};Max-Age=3600

إشعار

إذا كنت تستخدم جدار حماية تطبيق الويب (WAF) مع مجموعة قواعد أساسية 3.1 أو أقدم، قد تواجه مشاكل عند استخدام التعبيرات المنتظمة المتوافقة مع Perl (PCRE) أثناء تنفيذ تأكيدات lookahead وlookbehind (سلبية أو إيجابية).

بناء الجملة لالتقاط

يمكنك استخدام الأنماط لالتقاط خيط فرعي لاستخدامه لاحقا. ضع الأقواس حول نمط فرعي في تعريف regex. يخزن الزوج الأول من الأقواس سلسلة فرعية في 1، والزوج الثاني في 2، وهلم جرا. يمكنك استخدام عدد من الأقواس كما تشاء. يعرف بيرل المزيد من المتغيرات المرقمة لتمثيل هذه السلاسل الملتقطة بذلك. يمكنك العثور على بعض الأمثلة في إرشادات برمجة بيرل هذه.

• (\d)(\d) # مطابقة رقمين، والتقاطهما في المجموعتين 1 و2
• (\d+) # مطابقة رقم واحد أو أكثر، والتقاطها جميعا في المجموعة 1
• (\d)+ # مطابقة رقم مرة واحدة أو أكثر، مع تسجيل الأخير في المجموعة 1

بمجرد التقاطها، يمكنك استخدامها في قيمة مجموعة الإجراءات باستخدام التنسيق التالي:

• لالتقاط عنوان طلب، عليك استخدام {http_req_headerName_groupNumber}. على سبيل المثال، {http_req_User-Agent_1} أو {http_req_User-Agent_2}
• لالتقاط عنوان استجابة، يجب استخدام {http_resp_headerName_groupNumber}. على سبيل المثال، {http_resp_Location_1} أو {http_resp_Location_2}. بينما بالنسبة لعنوان الاستجابة Set-Cookie الذي تم التقاطه من خلال الخاصية "HeaderValueMatcher"، يجب استخدام {capt_header_value_matcher_groupNumber}. على سبيل المثال، {capt_header_value_matcher_1} أو {capt_header_value_matcher_2}.
• بالنسبة إلى متغير الخادم، عليك استخدام {var_serverVariableName_groupNumber}. على سبيل المثال، {var_uri_path_1} أو {var_uri_path_2}

إشعار

• استخدام / لبادئة ولاحقة النمط لا يجب أن يحدد في النمط ليطابق القيمة. على سبيل المثال، سيتطابق (\d)(\d) مع رقمين. /(\d)(\d)/ لن يتطابق مع رقمين.
• يجب أن تتطابق حالة متغير الشرط مع حالة متغير الالتقاط. على سبيل المثال، إذا كان متغير الحالة هو وكيل المستخدم، يجب أن يكون متغير الالتقاط الخاص بي ل User-Agent (أي {http_req_User-Agent_2}). إذا كان متغير الحالة معرفا كوكيل مستخدم، يجب أن يكون متغير الالتقاط الخاص بي هو وكيل المستخدم (أي {http_req_user-agent_2}).
• إذا أردت استخدام القيمة كاملة، فلا يجب ذكر الرقم. ببساطة استخدام تنسيق {http_req_headerName}، وما إلى ذلك دون groupNumber.

متغيرات الخادم

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

تدعم بوابة التطبيق متغيرات الخادم التالية:

اسم المتغير	‏‏الوصف
add_x_forwarded_for_proxy	حقل عنوان طلب العميل X-Forwarded-For مع client_ipالمتغير (راجع الشرح لاحقا في هذا الجدول) الملحق به في نموذجIP1 IP2 IP3 وهلم جرا. إذا لم يكن الحقل X-Forwarded-For في عنوان طلب العميل، فإن add_x_forwarded_for_proxyالمتغير يساوي $client_ip المتغير. يكون هذا المتغير مفيدا عندما تريد إعادة كتابة رأس X-Forwarded-For الذي تم تعيينه بواسطة بوابة التطبيق بحيث يحتوي العنوان على عنوان IP فقط بدون معلومات المنفذ.
الأصفار_المدعومة	قائمة الأصفار المعتمدة من قبل العميل.
الأصفار_المستخدمة	سلسلة الأصفار المستخدمة في اتصال TLS ثابت.
client_ip	عنوان IP للعميل الذي تلقت بوابة التطبيق الطلب منه. إذا كان هناك وكيل عكسي قبل بوابة التطبيق والعميل الأصلي، client_ip فسترجع عنوان IP للوكيل العكسي.
منفذ_العميل	منفذ العميل.
client_tcp_rtt	معلومات حول اتصال TCP العميل. متوفر على الأنظمة التي تدعم خيار مأخذ التوصيل TCP_INFO.
المستخدم_العميل	عند استخدام مصادقة HTTP يتم توفير اسم المستخدم للمصادقة.
مضيف	في ترتيب الأسبقية هذا: اسم المضيف من خط الطلب أو اسم المضيف من حقل عنوان طلب المضيف أو اسم الخادم المطابق للطلب. مثال: في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam، تكون قيمة المضيف contoso.com
ملف تعريف الارتباط_الاسم	ملف تعريف الارتباط الخاص ب الاسم.
http_method	الأسلوب المستخدم في إجراء طلب عنوان URL. على سبيل المثال، احصل على أو انشر.
حالة_http	حالة الجلسة. على سبيل المثال، 200, 400 أو 403.
إصدار	بروتوكول الطلب. عادة HTTP/1.0 أو HTTP/1.1 أو HTTP/2.0.
سلسلة_الاستعلام	قائمة أزواج المتغيرات/القيم التي تتبع في ? العنوان المطلوب. مثال: في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam، query_string القيمة هي id=123&title=fabrikam
البايت التي تم تسليمها	طول الطلب (بما في ذلك خط الطلب وعنوانه ونص الطلب).
طلب_الاستعلام	الوسيطات في خط الطلب.
نظام_الطلب	نظام الطلب: http أو https.
طلب uri	طلب URI الأصلي الكامل (مع الوسائط). مثال: في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam*، request_uri القيمة هي /article.aspx?id=123&title=fabrikam
البايت_المرسلة	عدد البايت المرسلة إلى عميل.
منفذ_الخادم	منفذ الخادم الذي قبل طلبا.
بروتوكول_اتصال_ssl	بروتوكول اتصال TLS المؤسس.
ssl_ممكّن	"تشغيل" إذا كان الاتصال يعمل في وضع TLS. وإلا، سلسلة فارغة.
مسار_uri	يعرّف المورد المحدد في المضيف الذي يريد عميل الويب الوصول إليه. يشير المتغير إلى مسار URL الأصلي قبل أي تعديل. هذا هو جزء من عنوان URI للطلب دون الوسيطات. على سبيل المثال، في الطلب http://contoso.com:8080/article.aspx?id=123&title=fabrikam، تكون قيمة uri_path هي /article.aspx.

متغيرات خادم المصادقة المتبادلة

تدعم بوابة التطبيق متغيرات الخادم التالية لسيناريوهات المصادقة المتبادلة. استخدم هذه المتغيرات في الخادم كما تفعل مع متغيرات الخادم الأخرى.

اسم المتغير	‏‏الوصف
شهادة_العميل	شهادة العميل بنموذج PEM لاتصال SSL مؤسس.
تاريخ_انتهاء_شهادة_العميل	تاريخ انتهاء شهادة العميل.
بصمة_شهادة_العميل	بصمة لوغاريتم التجزئة الآمن 1 لشهادة العميل لاتصال SSL المؤسس.
مُصدر_شهادة_العميل	سلسلة "المُصدر DN" لشهادة العميل لاتصال SSL المؤسس.
الرقم التسلسلي_لشهادة_العميل	الرقم التسلسلي لشهادة العميل لاتصال SSL المؤسس.
تاريخ_بداية_شهادة_العميل	تاريخ بدء شهادة العميل.
موضوع_شهادة_العميل	سلسلة "الموضوع DN" من شهادة العميل لاتصال SSL المؤسس.
التحقق من صحة_شهادة_العميل	نتيجة التحقق من شهادة العميل: نجاح، فشل:< سبب>، أو لا شيء إذا لم تكن هناك شهادة.

سيناريوهات شائعة لإعادة كتابة العنوان

إزالة معلومات المنفذ من X-Forwarded-For للعنوان

إدراج بوابة التطبيق X-Forwarded-For للعنوان في كافة الطلبات قبل أن يعيد توجيه الطلبات إلى الخلفية. هذا العنوان هو قائمة مفصولة بفاصلة لمنافذ IP. قد تكون هناك سيناريوهات تحتاج فيها خوادم الواجهة الخلفية فقط إلى العناوين لاحتواء عناوين IP. يمكنك استخدام إعادة كتابة الرأس لإزالة معلومات المنفذ من X-Forwarded-For للعنوان. إحدى الطرق للقيام بذلك هي تعيين العنوان إلى متغير الخادم add_x_forwarded_for_proxy. بدلا من ذلك، يمكنك أيضا استخدام المتغير client_ip:

تعديل عنوان URL لإعادة التوجيه

تعديل رابط إعادة التوجيه يمكن أن يكون مفيدا في ظروف معينة. على سبيل المثال، قد تقوم في البداية بإعادة توجيه العملاء إلى مسار مثل "/blog" لكنك الآن تريد إرسالهم إلى "/updates" بسبب تغيير في هيكل المحتوى.

تحذير

قد تحتاج إلى تعديل عنوان إعادة توجيه URL عند تكوين Application Gateway لتجاوز اسم المضيف نحو الخلفية. في هذا التكوين، ترى الواجهة الخلفية اسم مضيف مختلف عن المتصفح. إعادة التوجيه لا تستخدم اسم المضيف الصحيح. هذا التكوين غير مستحسن.

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

عندما ترسل خدمة التطبيق استجابة إعادة توجيه، فإنها تستخدم نفس اسم المضيف في عنوان الموقع الخاص لاستجابتها مثل اسم المضيف في الطلب الذي تتلقاه من بوابة التطبيق. لذلك يقوم العميل بإجراء الطلب مباشرة إلى contoso.azurewebsites.net/path2 بدلا من المرور عبر بوابة التطبيق (contoso.com/path2). من غير المرغوب تجاوز بوابة التطبيق.

يمكنك حل هذه المشكلة عن طريق تعيين اسم المضيف في عنوان الموقع إلى اسم مجال بوابة التطبيق.

فيما يلي الخطوات لاستبدال اسم المضيف:

1. أنشئ قاعدة إعادة كتابة بشرط يتحقق مما إذا كان رأس الموقع في الاستجابة يحتوي على azurewebsites.net. هنا يأتي النمط '(https?)://. azurewebsites.net(.).

2. تنفيذ إجراء لإعادة كتابة عنوان الموقع بحيث يكون لديه اسم مضيف بوابة التطبيق. أدخل {http_resp_Location_1}://contoso.com{http_resp_Location_2} كقيمة الرأس. بدلا من ذلك، يمكنك أيضا استخدام متغير الخادمhostلتعيين اسم المضيف لمطابقة الطلب الأصلي.

   

تنفيذ عناوين أمان HTTP لمنع الثغرات الأمنية

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

حذف العناوين غير المرغوب فيها

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

لا يمكنك إنشاء قاعدة إعادة كتابة لحذف رأس المضيف. إذا حاولت إنشاء قاعدة إعادة كتابة مع تعيين نوع الإجراء إلى حذف وتعيين العنوان إلى المضيف، فإنه ينتج عنه خطأ.

التحقق من وجود عنوان

يمكنك تقييم عنوان طلب HTTP أو استجابة لوجود متغير عنوان أو ملقم شبكة. هذا التقييم مفيد عندما تريد إجراء إعادة كتابة عنوان فقط عند وجود عنوان معين.

السيناريوهات الشائعة لإعادة كتابة عنوان URL

تحديد مسار يستند إلى المعلمة

لتحقيق سيناريوهات ترغب في اختيار تجمع الخلفية بناء على قيمة الرأس، أو جزء من الURL، أو سلسلة الاستعلام في الطلب، استخدم مزيجا من قدرة إعادة كتابة الرابط والتوجيه المعتمد على المسار.

أنشئ مجموعة إعادة كتابة بشرط يتحقق من معامل معين (سلسلة استعلام، رأس، إلخ) ثم يقوم بإجراء يغير مسار URL (تأكد من تفعيل خريطة إعادة تقييم المسارات ). ربط مجموعة إعادة الكتابة بقاعدة تعتمد على المسار. يجب أن تحتوي القاعدة المستندة إلى المسار على نفس مسارات URL المحددة في مجموعة إعادة الكتابة وتجمع الخلفية المقابل لها.

لذا، تتيح لك مجموعة إعادة الكتابة التحقق من معلمة معينة وتعيين مسار جديد له، وقاعدة المسار تسمح لك بتعيين مجموعات الخلفية لتلك المسارات. طالما تم تفعيل "إعادة تقييم خريطة المسار"، فإن حركة المرور ترسل بناء على المسار المحدد في مجموعة إعادة الكتابة.

للحصول على مثال حالة استخدام باستخدام سلاسل الاستعلام، راجع توجيه نسبة استخدام الشبكة باستخدام تحديد المسار المستند إلى المعلمة في المدخل.

إعادة كتابة معلمات سلسلة الاستعلام استنادا إلى عنوان URL

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

في هذه الحالة، يمكن لبوابة التطبيق التقاط المعلمات من عنوان URL وإضافة أزواج مفاتيح وقيمة سلاسل الاستعلام من تلك المعاملات في الرابط. على سبيل المثال، إذا أراد المستخدم إعادة الكتابة https://www.contoso.com/fashion/shirts إلى https://www.contoso.com/buy.aspx?category=fashion&product=shirts، يمكنك تحقيق هذا الهدف من خلال تكوين إعادة كتابة الرابط التالي.

الشرط - إذا كان متغير uri_path الخادم يساوي النمط /(.+)/(.+)

الإجراء - تعيين مسار عنوان URL إلى buy.aspx سلسلة الاستعلام إلى category={var_uri_path_1}&product={var_uri_path_2}

للحصول على دليل خطوة بخطوة لتحقيق السيناريو المذكور سابقا، راجع إعادة كتابة عنوان URL باستخدام بوابة التطبيق باستخدام بوابة Azure.

أعد كتابة الأخطاء الشائعة في التكوين

• لا يمكنك تفعيل 'إعادة تقييم خريطة المسار' لقواعد توجيه الطلبات الأساسية. هذا القيد يمنع حلقة تقييم لا نهائية لقاعدة توجيه أساسية.

• بالنسبة لقواعد التوجيه المعتمدة على المسار، تحتاج إلى قاعدة إعادة كتابة شرطية واحدة على الأقل أو قاعدة إعادة كتابة واحدة بدون تفعيل 'إعادة تقييم خريطة المسار'. هذا الشرط يمنع حلقة تقييم لا نهائية لقاعدة توجيه تعتمد على المسار.

• إذا تم إنشاء حلقة ديناميكية بناء على مدخلات العميل، تنتهي الطلبات الواردة برمز خطأ 500. تستمر بوابة التطبيق في خدمة طلبات أخرى دون أي تدهور في هذا السيناريو.

استخدام إعادة كتابة عنوان URL أو إعادة كتابة عنوان المضيف باستخدام جدار حماية تطبيق ويب (WAF_v2 SKU)

عند تكوين إعادة كتابة عنوان URL أو إعادة كتابة عنوان المضيف، يحدث تقييم WAF بعد التعديل على عنوان الطلب أو معلمات URL (بعد إعادة الكتابة). عندما تزيل إعادة كتابة عنوان URL أو تكوين إعادة كتابة رأس المضيف من بوابة التطبيق، يحدث تقييم WAF قبل إعادة كتابة الرأس (إعادة كتابة مسبقة). يضمن هذا الأمر أن قواعد WAF تنطبق على الطلب النهائي الذي تستلمه مجموعة الخلفية الخاصة بك.

على سبيل المثال، افترض أن لديك قاعدة إعادة كتابة الرأس التالية للرأس "Accept" : "text/html" - إذا كانت قيمة الرأس "Accept" تساوي "text/html"، فأعد كتابة القيمة إلى "image/png".

مع إعادة كتابة الرأس فقط، يتم تقييم WAF على "Accept" : "text/html". ولكن عند تكوين إعادة كتابة عنوان URL أو إعادة كتابة رأس المضيف، يحدث تقييم WAF على "Accept" : "image/png".

إعادة كتابة عنوان URL مقابل إعادة توجيه عنوان URL

لإعادة كتابة العنوان، يعيد Application Gateway كتابة الرابط قبل إرسال الطلب إلى الخلفية. هذا الإجراء لا يغير ما يراه المستخدمون في المتصفح لأن التغييرات مخفية عن المستخدم.

لإعادة توجيه عنوان URL، ترسل بوابة التطبيق استجابة إعادة توجيه إلى العميل بعنوان URL الجديد. يتطلب هذا الرد من العميل إعادة إرسال طلبه إلى عنوان URL الجديد المقدم في إعادة التوجيه. يتم تحديث عنوان URL الذي يراه المستخدم في المستعرض إلى عنوان URL الجديد.

القيود

• لا يتم دعم عمليات إعادة الكتابة عند تكوين بوابة التطبيق لإعادة توجيه الطلبات أو لإظهار صفحة خطأ مخصصة.
• يمكن أن تحتوي أسماء عناوين الطلب على أحرف أبجدية رقمية وواصلات. يتم التخلص من أسماء الرؤوس التي تحتوي على أحرف أخرى عند إرسال طلب إلى هدف الواجهة الخلفية.
• يمكن أن تحتوي أسماء عناوين الاستجابة على أي أحرف أبجدية رقمية ورموز محددة كما هو محدد في RFC 7230.
• لا يمكنك إعادة كتابة X-Original-Host، Connection، و upgrade الرؤوس.
• إعادة الكتابة غير مدعومة للردود على 4xx و5xx التي يتم توليدها مباشرة من Application Gateway.

الخطوات التالية

• تعلم كيفية إعادة كتابة عناوين HTTP مع بوابة التطبيق باستخدام مدخل Azure
• تعلم كيفية إعادة كتابة عناوين URL مع بوابة التطبيق باستخدام مدخل Azure