تكوين Azure Static Web Apps

يمكنك تعريف التكوين ل Azure Static Web Apps في ملف staticwebapp.config.json ، والذي يتحكم في الإعدادات التالية:

• التوجيه
• المصادقة
• التفويض
• القواعد الاحتياطية
• تجاوزات استجابة HTTP
• تعريفات رأس HTTP العمومية
• أنواع MIME المخصصة
• التواصل الشبكي

إشعار

يتم إهمال routes.json التي تم استخدامها مسبقا لتكوين التوجيه. استخدم staticwebapp.config.json كما هو موضح في هذه المقالة لتكوين التوجيه والإعدادات الأخرى لتطبيق الويب الثابت.

يصف هذا المستند كيفية تكوين Azure Static Web Apps، وهو منتج مستقل ومنفصل عن ميزة استضافة موقع الويب الثابت في Azure Storage.

موقع الملف

الموقع الموصى به staticwebapp.config.json موجود في المجلد الذي تم تعيينه كما في app_locationملف سير العمل. ومع ذلك، يمكنك وضع الملف في أي مجلد فرعي ضمن المجلد الذي تم تعيينه app_locationك . بالإضافة إلى ذلك، إذا كانت هناك خطوة بناء، يجب عليك التأكد من أن خطوة البناء إخراج الملف إلى جذر output_location.

راجع ملف التكوين المثال للحصول على التفاصيل.

هام

يتم تجاهل ملف routes.json المهمل في حالة وجود staticwebapp.config.json.

مسارات

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

• يتم تعريف القواعد في routes الصفيف، حتى إذا كان لديك مسار واحد فقط.
• يتم تقييم القواعد بالترتيب كما تظهر في routes الصفيف.
• يتوقف تقييم القاعدة عند التطابق الأول. تحدث مطابقة عندما تتطابق الخاصية route والقيمة methods في الصفيف (إذا تم تحديدها) مع الطلب. يمكن أن يتطابق كل طلب على الأكثر مع قاعدة واحدة.

يتعلق التوجيه بالتداخل الكبير مع مفاهيم المصادقة (تحديد المستخدم) والتخويل (تعيين القدرات للمستخدم). تأكد من قراءة دليل المصادقة والتخويل مع هذه المقالة.

تعريف المسارات

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

هام

route يتم استخدام الخاصيتين و methods (إذا تم تحديدهما) فقط لتحديد ما إذا كانت القاعدة تطابق طلبا أم لا.

خاصية القاعدة	المطلوب	القيمة الافتراضية	تعليق
route	‏‏نعم‬	غير متوفر	نمط المسار المطلوب من قبل المتصل. يتم دعم أحرف البدل في نهاية مسارات المسار. على سبيل المثال، يطابق المسار /admin* أي مسار يبدأ ب /admin.
methods	لا	جميع الطرق	تعريف صفيف من أساليب الطلب التي تطابق مسارا. تتضمن الأساليب المتوفرة: GETو HEADPOSTو PUTو DELETEوCONNECT. OPTIONSTRACEPATCH
rewrite	لا	غير متوفر	تعريف الملف أو المسار الذي تم إرجاعه من الطلب. يستبعد redirect أحدهما الآخر قاعدة. لا تغير قواعد إعادة الكتابة موقع المستعرض. يجب أن تكون القيم نسبة إلى جذر التطبيق.
redirect	لا	غير متوفر	تعريف وجهة إعادة توجيه الملف أو المسار لطلب. يستبعد rewrite أحدهما الآخر قاعدة. تقوم قواعد إعادة التوجيه بتغيير موقع المستعرض. رمز الاستجابة 302 الافتراضي هو (إعادة توجيه مؤقتة)، ولكن يمكنك تجاوزه ب 301 (إعادة توجيه دائمة).
statusCode	لا	301 أو 302 لإعادة التوجيه	رمز حالة HTTP للاستجابة.
headers	لا	غير متوفر	مجموعة من عناوين HTTP المضافة إلى الاستجابة. تتجاوز globalHeaders الرؤوس الخاصة بالمسار عندما يكون العنوان الخاص بالمسار هو نفسه العنوان العمومي في الاستجابة. لإزالة رأس، قم بتعيين القيمة إلى سلسلة فارغة.
allowedRoles	لا	مجهول	تعريف صفيف من أسماء الأدوار المطلوبة للوصول إلى مسار. تتضمن a-zالأحرف الصالحة و A-Z0-9و و._ ينطبق الدور المضمن، anonymous، على جميع المستخدمين. ينطبق الدور المضمن، authenticated، على أي مستخدم قام بتسجيل الدخول. يجب أن ينتمي المستخدمون إلى دور واحد على الأقل. تتم مطابقة الأدوار على أساس OR . إذا كان المستخدم في أي من الأدوار المدرجة، منح حق الوصول. يرتبط المستخدمون الفرديون بأدوار من خلال الدعوات.

كل خاصية لها غرض محدد في مسار الطلب/الاستجابة.

الغرض	خصائص
مطابقة المسارات	route، methods
العملية بعد مطابقة قاعدة وتفويضها	rewrite (يعدل الطلب) redirect، headers، statusCode (يعدل الاستجابة)
تخويل بعد مطابقة المسار	allowedRoles

تحديد أنماط المسار

route يمكن أن تكون الخاصية مسارا دقيقا أو نمط حرف بدل.

المسار الدقيق

لتعريف مسار دقيق، ضع المسار الكامل للملف في الخاصية route .

{
  "route": "/profile/index.html",
  "allowedRoles": ["authenticated"]
}

تطابق هذه القاعدة طلبات الملف /profile/index.html. نظرا لأن index.html هو الملف الافتراضي، فإن القاعدة تطابق أيضا طلبات المجلد (/profile أو /profile/).

هام

إذا كنت تستخدم مسار مجلد (/profile أو /profile/) في الخاصية route ، فلن يتطابق مع طلبات الملف /profile/index.html. عند حماية مسار يخدم ملفا، استخدم دائما المسار الكامل للملف مثل /profile/index.html.

نمط حرف البدل

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

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

{
  "route": "/calendar*",
  "rewrite": "/calendar.html"
}

يمكن لملف calendar.html بعد ذلك استخدام التوجيه من جانب العميل لخدمة طريقة عرض مختلفة لتباينات عنوان URL مثل /calendar/january/1و /calendar/2020و/calendar/overview.

إشعار

يطابق نمط /calendar/* مسار جميع الطلبات ضمن المسار /calendar/ . ومع ذلك، فإنه لن يتطابق مع طلبات المسارات /التقويم أو /calendar.html. يستخدم /calendar* لمطابقة جميع الطلبات التي تبدأ ب /calendar.

يمكنك تصفية تطابقات أحرف البدل حسب ملحق الملف. على سبيل المثال، إذا أردت إضافة قاعدة تطابق ملفات HTML فقط في مسار معين، يمكنك إنشاء القاعدة التالية:

{
  "route": "/articles/*.html",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

للتصفية على ملحقات ملفات متعددة، يمكنك تضمين الخيارات في أقواس متعرجة، كما هو موضح في هذا المثال:

{
  "route": "/images/thumbnails/*.{png,jpg,gif}",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

تتضمن حالات الاستخدام الشائعة لمسارات أحرف البدل ما يلي:

• تقديم ملف معين لنمط مسار بأكمله
• فرض قواعد المصادقة والتخويل
• تنفيذ قواعد التخزين المؤقت المتخصصة

تأمين المسارات مع الأدوار

يتم تأمين المسارات عن طريق إضافة اسم دور واحد أو أكثر إلى صفيف القاعدة allowedRoles . راجع مثال ملف التكوين للحصول على أمثلة الاستخدام.

هام

يمكن لقواعد التوجيه تأمين طلبات HTTP فقط إلى المسارات التي يتم تقديمها من Static Web Apps. تستخدم العديد من أطر العمل الأمامية التوجيه من جانب العميل الذي يعدل المسارات في المتصفح دون إصدار طلبات إلى Static Web Apps. لا تؤمن قواعد التوجيه المسارات من جانب العميل. يجب على العملاء استدعاء واجهات برمجة تطبيقات HTTP لاسترداد البيانات الحساسة. تأكد من أن واجهات برمجة التطبيقات تتحقق من صحة هوية المستخدم قبل إرجاع البيانات.

افتراضيًا، ينتمي كل مستخدم إلى الدور anonymous المُضمَّن، وجميع المستخدمين الذين سجلوا الدخول هم أعضاء في الدور authenticated. اختياريا، يرتبط المستخدمون بأدوار مخصصة عبر الدعوات.

على سبيل المثال، لتقييد مسار للمستخدمين المصادق عليهم فقط، أضف الدور المضمن authenticated إلى allowedRoles الصفيف.

{
  "route": "/profile*",
  "allowedRoles": ["authenticated"]
}

يمكنك إنشاء أدوار جديدة حسب الحاجة في allowedRoles الصفيف. لتقييد مسار للمسؤولين فقط، يمكنك تحديد دورك الخاص المسمى administrator، في allowedRoles الصفيف.

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}

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

هام

عند تأمين المحتوى، حدد الملفات الدقيقة عندما يكون ذلك ممكنا. إذا كان لديك العديد من الملفات المراد تأمينها، فاستخدم أحرف البدل بعد بادئة مشتركة. على سبيل المثال: /profile* يؤمن جميع المسارات الممكنة التي تبدأ ب /profile، بما في ذلك /profile.

تقييد الوصول إلى التطبيق بأكمله

غالبا ما تريد طلب مصادقة لكل مسار في التطبيق الخاص بك. لتأمين المسارات الخاصة بك، أضف قاعدة تطابق جميع المسارات وقم بتضمين الدور المضمن في authenticatedallowedRoles الصفيف.

يمنع تكوين المثال التالي الوصول المجهول ويعاد توجيه جميع المستخدمين غير المصادق عليهم إلى صفحة تسجيل الدخول إلى Microsoft Entra.

{
  "routes": [
    {
      "route": "/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

إشعار

بشكل افتراضي، يتم تمكين جميع موفري الهوية المكونة مسبقا. لحظر موفر مصادقة، راجع المصادقة والتخويل.

المسارات الاحتياطية

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

إشعار

لا يتم تطبيق قواعد المسار على الطلبات التي تقوم بتشغيل navigationFallback.

يمكنك تعريف قاعدة احتياطية عن طريق إضافة navigationFallback مقطع. يقوم المثال التالي بإرجاع /index.html لكافة طلبات الملفات الثابتة التي لا تطابق ملفا منشورا.

{
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}

يمكنك التحكم في الطلبات التي ترجع الملف الاحتياطي عن طريق تعريف عامل تصفية. في المثال التالي، يتم استبعاد طلبات مسارات معينة في المجلد /images وكافة الملفات الموجودة في المجلد /css من إرجاع الملف الاحتياطي.

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  }
}

على سبيل المثال، باستخدام بنية الدليل التالية، ستؤدي قاعدة التنقل الاحتياطية أعلاه إلى النتائج المفصلة في الجدول التالي.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
├── about.html
└── index.html

طلبات إلى...	ارجاع...	مع الحالة...
/عن/	الملف /index.html.	200
/images/logo.png	ملف الصورة.	200
/images/icon.svg	ملف /index.html - نظرا لأن ملحق ملف svg غير مدرج في عامل التصفية/images/*.{png,jpg,gif}.	200
/images/unknown.png	لم يتم العثور على خطأ في الملف.	404
/css/unknown.css	لم يتم العثور على خطأ في الملف.	404
/css/global.css	ملف ورقة الأنماط.	200
/about.html	صفحة HTML.	200
أي مسار آخر خارج المجلدات /images أو /css التي لا تتطابق مع المسار إلى ملف منشور.	الملف /index.html.	200

هام

إذا كنت تقوم بالترحيل من ملف routes.json المهمل، فلا تقم بتضمين المسار الاحتياطي القديم ("route": "/*") في قواعد التوجيه.

الرؤوس العمومية

globalHeaders يوفر القسم مجموعة من رؤوس HTTP المطبقة على كل استجابة، ما لم يتم تجاوزها بواسطة قاعدة رأس المسار، وإلا يتم إرجاع اتحاد كل من الرؤوس من المسار والرؤوس العمومية.

راجع مثال ملف التكوين للحصول على أمثلة الاستخدام.

لإزالة رأس، قم بتعيين القيمة إلى سلسلة فارغة ("").

تتضمن بعض حالات الاستخدام الشائعة للعناوين العمومية ما يلي:

• قواعد التخزين المؤقت المخصصة
• نُهج أمان Azure
• إعدادات الترميز
• تكوين مشاركة الموارد عبر المنشأ (CORS)

يقوم المثال التالي بتنفيذ تكوين CORS مخصص.

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "https://example.com",
    "Access-Control-Allow-Methods": "POST, GET, OPTIONS"
  }
}

إشعار

لا تؤثر العناوين العمومية على استجابات واجهة برمجة التطبيقات. يتم الاحتفاظ بالرؤوس في استجابات واجهة برمجة التطبيقات وإعادتها إلى العميل.

تجاوزات الاستجابة

يوفر قسم responseOverrides فرصة لتحديد استجابة مخصصة عندما يقوم الخادم بإرجاع رمز خطأ. راجع مثال ملف التكوين للحصول على أمثلة الاستخدام.

تتوفر رموز HTTP التالية لتجاوز:

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

يوضح تكوين المثال التالي كيفية تجاوز رمز خطأ.

{
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "statusCode": 302,
      "redirect": "/login"
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/custom-404.html"
    }
  }
}

النظام الأساسي

يتحكم platform القسم في إعدادات النظام الأساسي المحددة، مثل إصدار وقت تشغيل لغة واجهة برمجة التطبيقات.

حدد إصدار وقت تشغيل لغة API

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

إصدار وقت تشغيل اللغة	نظام التشغيل	إصدار Azure Functions	apiRuntime قيمة	تاريخ انتهاء الدعم
.NET Core 3.1	بالنسبة لنظام التشغيل	3.x	dotnet:3.1	3 ديسمبر 2022
.NET 6.0 قيد المعالجة	بالنسبة لنظام التشغيل	4.x	dotnet:6.0	30 أبريل 2025
.NET 8.0 قيد المعالجة	بالنسبة لنظام التشغيل	4.x	dotnet:8.0	-
.NET 6.0 معزول	بالنسبة لنظام التشغيل	4.x	dotnet-isolated:6.0	30 أبريل 2025
.NET 7.0 معزول	بالنسبة لنظام التشغيل	4.x	dotnet-isolated:7.0	30 أبريل 2025
.NET 8.0 معزول	بالنسبة لنظام التشغيل	4.x	dotnet-isolated:8.0	-
.NET 9.0 معزول	بالنسبة لنظام التشغيل	4.x	dotnet-isolated:9.0	-
Node.js 12.x	Linux	3.x	node:12	3 ديسمبر 2022
Node.js 14.x	Linux	4.x	node:14	30 أبريل 2025
Node.js 16.x	Linux	4.x	node:16	30 أبريل 2025
Node.js 18.x	Linux	4.x	node:18	31 مايو 2025
Node.js 20.x	Linux	4.x	node:20	-
برنامج Python 3.8	Linux	4.x	python:3.8	30 أبريل 2025
Python 3.9	Linux	4.x	python:3.9	-
Python 3.10	Linux	4.x	python:3.10	-
Python 3.11	Linux	4.x	python:3.11	-

.NET

لتغيير إصدار وقت التشغيل في تطبيق .NET، قم بتغيير TargetFramework القيمة في ملف csproj . على الرغم من أنه اختياري، إذا قمت بتعيين قيمة في apiRuntime، فتأكد من تطابق القيمة مع ما تحدده في ملف csproj.

يوضح المثال التالي كيفية تحديث TargetFramework عنصر NET 8.0 كإصدار وقت تشغيل لغة API في ملف csproj .

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    ...
  </PropertyGroup>
...

Node.js

يوضح تكوين المثال التالي كيفية استخدام الخاصية apiRuntime لتحديد Node.js 20 كإصدار وقت تشغيل لغة API في ملف staticwebapp.config.json .

{
  ...
  "platform": {
    "apiRuntime": "node:20"
  }
  ...
}

Python

يوضح تكوين المثال التالي كيفية استخدام الخاصية apiRuntime لتحديد Python 3.11 كإصدار وقت تشغيل لغة واجهة برمجة التطبيقات في ملف staticwebapp.config.json .

{
  ...
  "platform": {
    "apiRuntime": "python:3.11"
  }
  ...
}

الشبكات

networking يتحكم القسم في تكوين الشبكة لتطبيق الويب الثابت. لتقييد الوصول إلى تطبيقك، حدد قائمة بكتل عناوين IP المسموح بها في allowedIpRanges. لمزيد من المعلومات حول عدد كتل عناوين IP المسموح بها، راجع الحصص النسبية في Azure Static Web Apps.

إشعار

يتوفر تكوين الشبكة فقط في خطة Azure Static Web Apps Standard.

تعريف كل كتلة عنوان IPv4 في رمز التوجيه بين المجالات (CIDR) بدون فئة. لمعرفة المزيد حول رمز CIDR، راجع Classless Inter-Domain Routing. يمكن أن تشير كل كتلة عناوين IPv4 إما إلى مساحة عنوان عامة أو خاصة. إذا كنت تريد السماح بالوصول فقط من عنوان IP واحد، يمكنك استخدام /32 كتلة CIDR.

{
  "networking": {
    "allowedIpRanges": [
      "10.0.0.0/24",
      "100.0.0.0/32",
      "192.168.100.0/22"
    ]
  }
}

عند تحديد كتلة عنوان IP واحدة أو أكثر، يتم رفض الوصول إلى الطلبات التي تنشأ من عناوين IP التي لا تطابق قيمة في allowedIpRanges .

بالإضافة إلى كتل عناوين IP، يمكنك أيضا تحديد علامات الخدمة في allowedIpRanges الصفيف لتقييد حركة المرور إلى خدمات Azure معينة.

"networking": {
  "allowedIpRanges": ["AzureFrontDoor.Backend"]
}

المصادقة

• لا يتطلب موفرو المصادقة الافتراضيون إعدادات في ملف التكوين.

• يستخدم موفرو المصادقة المخصصونauth قسم ملف الإعدادات.

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

تعطيل ذاكرة التخزين المؤقت للمسارات المصادق عليها

إذا قمت بإعداد التكامل اليدوي مع Azure Front Door، فقد تحتاج إلى تعطيل التخزين المؤقت للمسارات الآمنة. مع تمكين الحافة على مستوى المؤسسة، يتم بالفعل تعطيل التخزين المؤقت للمسارات الآمنة.

لتعطيل التخزين المؤقت ل Azure Front Door للمسارات الآمنة، أضف "Cache-Control": "no-store" إلى تعريف رأس المسار.

على سبيل المثال:

{
    "route": "/members",
    "allowedRoles": ["authenticated, members"],
    "headers": {
        "Cache-Control": "no-store"
    }
}

بوابة إعادة التوجيه

forwardingGateway يقوم القسم بتكوين كيفية الوصول إلى تطبيق ويب ثابت من بوابة إعادة توجيه مثل شبكة تسليم المحتوى (CDN) أو Azure Front Door.

إشعار

يتوفر تكوين بوابة إعادة التوجيه فقط في خطة Azure Static Web Apps Standard.

المضيفون الذين تمت إعادة توجيههم المسموح لهم

allowedForwardedHosts تحدد القائمة أسماء المضيفين التي يجب قبولها في رأس X-Forwarded-Host. إذا كان المجال المطابق في القائمة، فإن Static Web Apps تستخدم X-Forwarded-Host القيمة عند إنشاء عناوين URL لإعادة التوجيه، مثل بعد تسجيل دخول ناجح.

لكي تعمل تطبيقات الويب الثابتة بشكل صحيح خلف بوابة إعادة التوجيه، يجب أن يتضمن الطلب من البوابة اسم المضيف الصحيح في X-Forwarded-Host العنوان ويجب إدراج نفس اسم المضيف في allowedForwardedHosts.

"forwardingGateway": {
  "allowedForwardedHosts": [
    "example.org",
    "www.example.org",
    "staging.example.org"
  ]
}

X-Forwarded-Host إذا لم يتطابق العنوان مع قيمة في القائمة، فلا تزال الطلبات ناجحة، ولكن لا يتم استخدام العنوان في الاستجابة.

الرؤوس المطلوبة

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

على سبيل المثال، يوضح التكوين التالي كيف يمكنك إضافة معرف فريد ل Azure Front Door يحد من الوصول إلى موقعك من مثيل Azure Front Door محدد. راجع البرنامج التعليمي تكوين Azure Front Door للحصول على التفاصيل الكاملة.

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}

• يمكن أن تكون أزواج المفاتيح/القيم أي مجموعة من السلاسل العشوائية
• المفاتيح غير حساسة لحالة الأحرف
• القيم حساسة لحالة الأحرف

شرطة مائلة زائدة

الشرطة المائلة اللاحقة / هي في نهاية عنوان URL. بشكل تقليدي، يشير عنوان URL المائل اللاحق إلى دليل على خادم الويب، بينما تشير الشرطة المائلة غير المائلة إلى ملف.

تتعامل محركات البحث مع عنواني URL بشكل منفصل، بغض النظر عما إذا كان ملفا أو دليلا. عند عرض المحتوى نفسه في كل من عناوين URL هذه، يقدم موقع الويب الخاص بك محتوى مكرر، والذي يمكن أن يؤثر سلبا على تحسين محرك البحث (SEO). عند تكوينها بشكل صريح، تطبق Static Web Apps مجموعة من قواعد تسوية عنوان URL وإعادة التوجيه التي تساعد على تحسين أداء موقعك على الويب وأداء SEO.

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

دائمًا

عند الإعداد trailingSlash إلى always، تتم إعادة توجيه جميع الطلبات التي لا تتضمن شرطة مائلة زائدة إلى عنوان URL مائل لاحق. على سبيل المثال، /contact تتم إعادة توجيه إلى /contact/.

"trailingSlash": "always"

طلبات إلى...	ارجاع...	مع الحالة...	والمسار...
/عن	ملف /about/index.html	301	/عن/
/عن/	ملف /about/index.html	200	/عن/
/حول/index.html	ملف /about/index.html	301	/عن/
/privacy.html	ملف /privacy.html	301	/الخصوصيه/

أبدًا

عند الإعداد trailingSlash إلى never، تتم إعادة توجيه جميع الطلبات التي تنتهي في شرطة مائلة لاحقة إلى عنوان URL مائل غير مائل. على سبيل المثال، /contact/ تتم إعادة توجيه إلى /contact.

"trailingSlash": "never"

طلبات إلى...	ارجاع...	مع الحالة...	والمسار...
/عن	ملف /about/index.html	200	/عن
/عن/	ملف /about/index.html	301	/عن
/حول/index.html	ملف /about/index.html	301	/عن
/privacy.html	ملف /privacy.html	301	/الخصوصيه

تلقائي

عند التعيين trailingSlash إلى auto، تتم إعادة توجيه جميع الطلبات إلى المجلدات إلى عنوان URL مع شرطة مائلة لاحقة. تتم إعادة توجيه جميع طلبات الملفات إلى عنوان URL مائل غير مائل.

"trailingSlash": "auto"

طلبات إلى...	ارجاع...	مع الحالة...	والمسار...
/عن	ملف /about/index.html	301	/عن/
/عن/	ملف /about/index.html	200	/عن/
/حول/index.html	ملف /about/index.html	301	/عن/
/privacy.html	ملف /privacy.html	301	/الخصوصيه

للحصول على الأداء الأمثل لموقع الويب، قم بتكوين استراتيجية شرطة مائلة زائدة باستخدام أحد الأوضاع alwaysneverأو أو .auto

بشكل افتراضي، عند trailingSlash حذف التكوين، تطبق Static Web Apps القواعد التالية:

طلبات إلى...	ارجاع...	مع الحالة...	والمسار...
/عن	ملف /about/index.html	200	/عن
/عن/	ملف /about/index.html	200	/عن/
/حول/index.html	ملف /about/index.html	200	/حول/index.html
/privacy.html	ملف /privacy.html	200	/privacy.html

مثال لملف التكوين

{
  "trailingSlash": "auto",
  "routes": [
    {
      "route": "/profile*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/admin/index.html",
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/images/*",
      "headers": {
        "cache-control": "must-revalidate, max-age=15770000"
      }
    },
    {
      "route": "/api/*",
      "methods": ["GET"],
      "allowedRoles": ["registeredusers"]
    },
    {
      "route": "/api/*",
      "methods": ["PUT", "POST", "PATCH", "DELETE"],
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/customers/contoso*",
      "allowedRoles": ["administrator", "customers_contoso"]
    },
    {
      "route": "/login",
      "rewrite": "/.auth/login/github"
    },
    {
      "route": "/.auth/login/x",
      "statusCode": 404
    },
    {
      "route": "/logout",
      "redirect": "/.auth/logout"
    },
    {
      "route": "/calendar*",
      "rewrite": "/calendar.html"
    },
    {
      "route": "/specials",
      "redirect": "/deals",
      "statusCode": 301
    }
  ],
  "navigationFallback": {
    "rewrite": "index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  },
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "redirect": "/login",
      "statusCode": 302
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/404.html"
    }
  },
  "globalHeaders": {
    "content-security-policy": "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
  },
  "mimeTypes": {
    ".json": "text/json"
  }
}

استنادا إلى التكوين أعلاه، راجع السيناريوهات التالية.

طلبات إلى...	النتائج في...
/ملف تعريف	يتم تقديم الملف /profile/index.html للمستخدمين المصادق عليهم. تتم إعادة توجيه المستخدمين غير المصادق عليهم إلى /login بواسطة 401 قاعدة تجاوز الاستجابة.
/admin أو /admin/أو /admin/index.html	يتم تقديم الملف /admin/index.html للمستخدمين المصادق عليهم في دور المسؤول. يتم تقديم خطأ 1 للمستخدمين المصادق عليهم غير الموجودين في دور المسؤول.403 تتم إعادة توجيه المستخدمين غير المصادق عليهم إلى /login
/images/logo.png	يخدم الصورة مع قاعدة ذاكرة التخزين المؤقت المخصصة حيث يكون الحد الأقصى للعمر أكثر قليلا من 182 يوما (15770000 ثانية).
/api/admin	GET يتم إرسال الطلبات من المستخدمين المصادق عليهم في دور المستخدمين المسجلين إلى واجهة برمجة التطبيقات. يتم تقديم خطأ للمستخدمين المصادق عليهم غير الموجودين في 401 والمستخدمين غير المصادق عليهم. POST PUT PATCHيتم إرسال طلبات و و DELETE من المستخدمين المصادق عليهم في دور المسؤول إلى واجهة برمجة التطبيقات. يتم تقديم خطأ للمستخدمين المصادق عليهم غير الموجودين 401 والمستخدمين غير المصادق عليهم.
/customers/contoso	يتم تقديم الملف /customers/contoso/index.html للمستخدمين المصادق عليهم الذين ينتمون إلى أدوار المسؤول أو customers_contoso. يتم تقديم خطأ 1 للمستخدمين المصادق عليهم غير الموجودين في أدوار المسؤول أو customers_contoso.403 تتم إعادة توجيه المستخدمين غير المصادق عليهم إلى /login.
/تسجيل الدخول	يتم تحدي المستخدمين غير المصادق عليهم للمصادقة مع GitHub.
_/.auth/login/x	نظرا لأن قاعدة المسار تقوم بتعطيل تخويل X، 404 يتم إرجاع خطأ. ثم يعود هذا الخطأ إلى تقديم /index.html مع رمز 200 الحالة.
/الخروج	يتم تسجيل خروج المستخدمين من أي موفر مصادقة.
/calendar/2021/01	يتم تقديم المستعرض ملف /calendar.html .
/خاصه	تتم إعادة توجيه المتصفح بشكل دائم إلى /deals.
/data.json	الملف الذي يتم تقديمه text/json مع نوع MIME.
/حول، أو أي مجلد يطابق أنماط التوجيه من جانب العميل	يتم تقديم ملف /index.html مع رمز 200 الحالة.
ملف غير موجود في المجلد /images/	خطأ 404 .

¹ يمكنك توفير صفحة خطأ مخصصة باستخدام قاعدة تجاوز الاستجابة.

القيود

توجد القيود التالية لملف staticwebapp.config.json .

• الحد الأقصى لحجم الملف هو 20 كيلوبايت
• بحد أقصى 50 دور مميز

راجع مقالة الحصص النسبية للحصول على القيود والقيود العامة.

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

إعداد المصادقة والتخويل

المقالات ذات الصلة

• تعيين الإعدادات على مستوى التطبيق ومتغيرات البيئة المستخدمة من قبل واجهات برمجة التطبيقات الخلفية
• تحديد الإعدادات التي تتحكم في عملية الإنشاء