تكوين 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 |
نعم | غير متوفر | نمط المسار المطلوب من قبل المتصل.
|
methods |
لا | جميع الطرق | تعريف صفيف من أساليب الطلب التي تطابق مسارا. تتضمن الأساليب المتوفرة: GET و HEAD POST و PUT و DELETE وOPTIONS . TRACE PATCH CONNECT |
rewrite |
لا | غير متوفر | تعريف الملف أو المسار الذي تم إرجاعه من الطلب.
|
redirect |
لا | غير متوفر | تعريف وجهة إعادة توجيه الملف أو المسار لطلب. |
statusCode |
لا | 301 أو 302 لإعادة التوجيه |
رمز حالة HTTP للاستجابة. |
headers |
لا | غير متوفر | مجموعة من عناوين HTTP المضافة إلى الاستجابة.
|
allowedRoles |
لا | مجهول | تعريف صفيف من أسماء الأدوار المطلوبة للوصول إلى مسار.
|
كل خاصية لها غرض محدد في مسار الطلب/الاستجابة.
الغرض | خصائص |
---|---|
مطابقة المسارات | 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.
تقييد الوصول إلى التطبيق بأكمله
غالبا ما تريد طلب مصادقة لكل مسار في التطبيق الخاص بك. لتأمين المسارات الخاصة بك، أضف قاعدة تطابق جميع المسارات وقم بتضمين الدور المضمن في authenticated
allowedRoles
الصفيف.
يمنع تكوين المثال التالي الوصول المجهول ويعاد توجيه جميع المستخدمين غير المصادق عليهم إلى صفحة تسجيل الدخول إلى 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 | Windows | 3.x | dotnet:3.1 |
3 ديسمبر 2022 |
.NET 6.0 قيد المعالجة | Windows | 4.x | dotnet:6.0 |
- |
.NET 6.0 معزول | Windows | 4.x | dotnet-isolated:6.0 |
- |
.NET 7.0 معزول | Windows | 4.x | dotnet-isolated:7.0 |
- |
.NET 8.0 معزول | Windows | 4.x | dotnet-isolated:8.0 |
- |
Node.js 12.x | Linux | 3.x | node:12 |
3 ديسمبر 2022 |
Node.js 14.x | Linux | 4.x | node:14 |
- |
Node.js 16.x | Linux | 4.x | node:16 |
- |
Node.js 18.x | Linux | 4.x | node:18 |
- |
Node.js 20.x (معاينة) | Linux | 4.x | node:20 |
- |
برنامج Python 3.8 | Linux | 4.x | python:3.8 |
- |
Python 3.9 | Linux | 4.x | python:3.9 |
- |
Python 3.10 | Linux | 4.x | python:3.10 |
- |
.NET
لتغيير إصدار وقت التشغيل في تطبيق .NET، قم بتغيير TargetFramework
القيمة في ملف csproj . على الرغم من أنه اختياري، إذا قمت بتعيين قيمة في ملف staticwebapp.config.json، فتأكد من تطابق القيمة مع ما تحدده في ملف csproj.apiRuntime
يوضح المثال التالي كيفية تحديث TargetFramework
عنصر NET 8.0 كإصدار وقت تشغيل لغة API في ملف csproj .
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
...
</PropertyGroup>
...
Node.js
يوضح تكوين المثال التالي كيفية استخدام الخاصية apiRuntime
لتحديد Node.js 16 كإصدار وقت تشغيل لغة API في ملف staticwebapp.config.json .
{
...
"platform": {
"apiRuntime": "node:16"
}
...
}
Python
يوضح تكوين المثال التالي كيفية استخدام الخاصية apiRuntime
لتحديد Python 3.8 كإصدار وقت تشغيل لغة واجهة برمجة التطبيقات في ملف staticwebapp.config.json .
{
...
"platform": {
"apiRuntime": "python:3.8"
}
...
}
الشبكات
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 |
/عن/ |
/about/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 |
/عن |
/about/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 |
/عن/ |
/about/index.html | ملف /about/index.html | 301 |
/عن/ |
/privacy.html | ملف /privacy.html | 301 |
/الخصوصيه |
للحصول على الأداء الأمثل لموقع الويب، قم بتكوين استراتيجية شرطة مائلة زائدة باستخدام أحد الأوضاع always
never
أو أو .auto
بشكل افتراضي، عند trailingSlash
حذف التكوين، تطبق Static Web Apps القواعد التالية:
طلبات إلى... | ارجاع... | مع الحالة... | والمسار... |
---|---|---|---|
/عن | ملف /about/index.html | 200 |
/عن |
/عن/ | ملف /about/index.html | 200 |
/عن/ |
/about/index.html | ملف /about/index.html | 200 |
/about/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 . |
1 يمكنك توفير صفحة خطأ مخصصة باستخدام قاعدة تجاوز الاستجابة.
القيود
توجد القيود التالية لملف staticwebapp.config.json .
- الحد الأقصى لحجم الملف هو 20 كيلوبايت
- بحد أقصى 50 دور مميز
راجع مقالة الحصص النسبية للحصول على القيود والقيود العامة.