إعداد سلوك الاستضافة

باستخدام Firebase Hosting، يمكنك ضبط سلوك استضافة مخصّص لطلبات موقعك الإلكتروني.

ما هي الإعدادات التي يمكنك ضبطها في Hosting؟

• حدِّد الملفات في دليل المشاريع المحلية التي تريد نشرها في Firebase Hosting. التعرّف على كيفية إجراء ذلك

• عرض صفحة 404/لم يتم العثور عليها مخصصة. التعرّف على كيفية إجراء ذلك

• اضبط الرمز redirects للصفحات التي نقلتها أو حذفتها. تعرَّف على كيفية إجراء ذلك.

• يمكنك إعداد rewrites لأيّ من الأغراض التالية:

  • عرض المحتوى نفسه على عناوين URL متعددة: تعرَّف على كيفية إجراء ذلك.

  • يمكنك عرض دالة أو الوصول إلى حاوية Cloud Run من عنوان URL للسمة Hosting. تعرَّف على كيفية: دالة أو حاوية.

  • أنشئ نطاقًا مخصّصًا Dynamic Link. تعرَّف على كيفية إجراء ذلك.

• أضِف headers لنقل معلومات إضافية عن طلب أو استجابة، مثل كيفية تعامل المتصفّحات مع الصفحة ومحتواها (المصادقة والتخزين المؤقت والترميز وما إلى ذلك). تعرَّف على كيفية إجراء ذلك.

• يمكنك إعداد عمليات إعادة الكتابة للغة (i18n) لعرض محتوى معيّن استنادًا إلى اللغة المفضّلة للمستخدم و/أو بلده. التعرّف على كيفية إجراء ذلك (صفحة مختلفة)

أين يمكنك تحديد إعدادات Hosting؟

يمكنك تحديد إعدادات Firebase Hosting في ملف firebase.json. تنشئ Firebase تلقائيًا ملف firebase.json في جذر دليل مشروعك عند تشغيل الأمر firebase init.

تحذير: في حال تشغيل firebase init مرة أخرى واختيار Hosting، سيؤدي الأمر إلى استبدال قسم hosting من ملف firebase.json بالملف الإعدادات التلقائية.

يمكنك العثور على مثال كامل لإعدادات firebase.json (يتضمّن Firebase Hosting فقط) في أسفل هذه الصفحة. يُرجى العلم أنّ ملف firebase.json يمكن أن يحتوي أيضًا على إعدادات لخدمات Firebase الأخرى.

يمكنك الاطّلاع على محتوى firebase.json الذي تم نشره باستخدام Hosting REST API.

ترتيب أولوية Hosting ردّ

يمكن أن تتداخل أحيانًا خيارات ضبط Firebase Hosting المختلفة الموضّحة في هذه الصفحة . في حال حدوث تعارض، يحدّد Hosting استجابته باستخدام ترتيب الأولوية التالي:

1. مساحات الاسم المعرِّفة المحجوزة التي تبدأ بشريحة مسار /__/*
2. عمليات إعادة التوجيه التي تم ضبطها
3. المحتوى الثابت الذي يتطابق تمامًا
4. عمليات إعادة الكتابة التي تم ضبطها
5. صفحة 404 المخصّصة
6. الصفحة 404 التلقائية

ملاحظة مهمة: ضمن كلّ من السمتَين redirects وrewrites، تطبّق Hosting إعادة التوجيه أو إعادة الكتابة المحدّدة من خلال القاعدة first باستخدام نمط عنوان URL يتطابق مع المسار المطلوب. لذلك، عليك ترتيب القواعد عمدًا ضمن كلّ من السمتَين redirects وrewrites. يبقى redirects الذي تم ضبطه له الأولوية على rewrites.

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

تحديد الملفات المطلوب نشرها

السمات التلقائية، public وignore، المضمّنة في ملف firebase.json التلقائي، تحدّد الملفات التي يجب إرسالها إلى مشروعك على Firebase في دليل مشروعك.

تظهر إعدادات hosting التلقائية في ملف firebase.json على النحو التالي:

"hosting": {
  "public": "public",  // the only required attribute for Hosting
  "ignore": [
    "firebase.json",
    "**/.*",
    "**/node_modules/**"
  ]
}

عامة

مطلوبة
تحدِّد السمة public الدليل الذي سيتم نشر التطبيق فيه Firebase Hosting. القيمة التلقائية هي دليل يحمل اسم public، ولكن يمكنك تحديد مسار أي دليل، ما دام متوفّرًا في دليل مشروعك.

فيما يلي هو الاسم التلقائي المحدد للدليل لنشره:

"hosting": {
  "public": "public"

  // ...
}

يمكنك تغيير القيمة التلقائية إلى الدليل الذي تريد نشره:

"hosting": {
  "public": "dist/app"

  // ...
}

تجاهل

اختياري
تحدّد السمة ignore الملفات التي سيتم تجاهلها عند النشر. ويمكن أن يأخذ مجموعات بالطريقة نفسها التي يتعامل بها Git مع .gitignore.

في ما يلي القيم التلقائية للملفات التي سيتم تجاهلها:

"hosting": {
  // ...

  "ignore": [
    "firebase.json",  // the Firebase configuration file (the file described on this page)
    "**/.*",  // files with a leading period should be hidden from the system
    "**/node_modules/**"  // contains dependencies used to create your site but not run it
  ]
}

تخصيص صفحة 404/لم يتم العثور على الصفحة

اختياري
يمكنك عرض خطأ 404 Not Found مخصّص عندما يحاول مستخدم الوصول إلى صفحة غير متوفّرة.

أنشئ ملفًا جديدًا في دليل public الخاص بمشروعك، واسمه 404.html، ثم أضِف محتوى 404 Not Found المخصّص إلى الملف.

ستعرِض Firebase Hosting محتوى صفحة 404.html المخصّصة هذه إذا أدّى أحد المتصفّحات إلى ظهور خطأ 404 Not Found في نطاقك أو نطاقك الفرعي.

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

اختياري
يمكنك استخدام إعادة توجيه عنوان URL لمنع ظهور روابط غير صالحة في حال نقلت صفحة، أو لتقصير عناوين URL. على سبيل المثال، يمكنك إعادة توجيه متصفّح من example.com/team إلى example.com/about.html.

حدِّد عمليات إعادة التوجيه لعناوين URL من خلال إنشاء سمة redirects تحتوي على صفيف من الكائنات (يُشار إليها باسم "قواعد إعادة التوجيه"). في كل قاعدة، حدِّد نمط عنوان URL الذي، في حال مطابقته مع مسار عنوان URL للطلب، يؤدي إلى تنشيط Hosting للردّ من خلال إعادة توجيه العميل إلى عنوان URL المقصود المحدّد.

في ما يلي البنية الأساسية للسمة redirects. يعيد هذا المثال توجيه الطلبات إلى /foo من خلال تقديم طلب جديد إلى /bar.

"hosting": {
  // ...

  // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
  "redirects": [ {
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  } ]
}

عرض مثال أكثر تفصيلاً لسمة redirects

"hosting": {
  // ...

  // Add the "redirects" attribute within "hosting"
  "redirects": [ {
    // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  }, {
    // Returns a permanent redirect to "/bar" for requests to both "/foo" and "/foo/**"
    "source": "/foo{,/**}"
    "destination": "/bar"
    "type": 301
  }, {
    // Returns a temporary redirect for all requests to files or directories in the "firebase" directory
    "source": "/firebase/**",
    "destination": "https://firebase.google.com/",
    "type": 302
  }, {
    // A regular expression-based redirect equivalent to the above behavior
    "regex": "/firebase/.*",
    "destination": "https://firebase.google.com/",
    "type": 302
  } ]
}

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

تقارن Firebase Hosting قيمة source أو regex بجميع ملفّات عناوين URL المسارات في بداية كل طلب (قبل أن يحدّد المتصفّح ما إذا كان هناكملفّ أو مجلد في هذا المسار). في حال العثور على مطابقة، يرسل خادم المصدر Firebase Hosting استجابة إعادة توجيه HTTPS تطلب من المتصفّح إرسال طلب جديد على عنوان URL الخاص بـ destination.

الحقل		الوصف
redirects
	source (إجراء مُقترَح) أو regex	نمط عنوان URL الذي يؤدي إلى تنشيط Hosting لتطبيق إعادة التوجيه في حال تطابقه مع عنوان URL للطلب الأولي استخدِم source لتحديد تعبير عادي (إجراء مقترَح). استخدِم regex لتحديد تعبير عادي RE2.
	destination	عنوان URL ثابت يجب أن يقدّم المتصفّح طلبًا جديدًا عليه وقد يكون عنوان URL هذا مسارًا نسبيًا أو مسارًا مطلقًا.
	type	رمز استجابة HTTPS استخدِم النوع 301 للإشارة إلى "تم نقله نهائيًا". استخدِم النوع 302 للإشارة إلى "تم العثور عليه" (إعادة توجيه مؤقتة).

ملاحظة مهمة: ضمن السمة redirects، تطبّق Hosting عملية إعادة التوجيه التي تحدّدها القاعدة الأولى باستخدام نمط عنوان URL يتطابق مع المسار المطلوب. عليك ترتيب القواعد عمدًا ضمن السمة redirects.

تسجيل شرائح عناوين URL لعمليات إعادة التوجيه

اختياري
قد تحتاج أحيانًا إلى تسجيل أجزاء معيّنة من نمط عنوان URL لقاعدة إعادة التوجيه (قيمة source أو regex)، ثم إعادة استخدام هذه الأجزاء في مسار destination للقاعدة.

التقاط أقسام عناوين URL عند استخدام glob

إذا كنت تستخدِم حقل source (أي تحديد نطاق شامل لنمط عنوان URL)، يمكنك تسجيل الشرائح من خلال تضمين بادئة : لتحديد الشريحة. إذا كنت بحاجة أيضًا إلى تسجيل مسار عنوان URL المتبقّي بعد المقطع، أدرِج * بعد المقطع مباشرةً. على سبيل المثال:

"hosting": {
  // ...

  "redirects": [ {
    "source": "/blog/:post*",  // captures the entire URL segment beginning at "post"
    "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the "source" value
    "type": 301
  }, {
    "source": "/users/:id/profile",  // captures only the URL segment "id", but nothing following
    "destination": "/users/:id/newProfile",  // includes the URL segment identified and captured by the "source" value
    "type": 301
  } ]
}

تسجيل أجزاء عناوين URL عند استخدام التعبيرات العادية RE2

إذا كنت تستخدِم حقل regex (أي تحديد تعبير عادي RE2 لنمط عنوان URL)، يمكنك تسجيل شرائح باستخدام مجموعات اصطياد RE2 إما مُسمّاة أو غير مُسمّاة. يمكن استخدام مجموعات الالتقاط المُسمّاة في الحقل destination مع البادئة :، في حين يمكن الإشارة إلى مجموعات الالتقاط غير المُسمّاة من خلال فهرسها الرقمي في قيمة regex، مع الفهرسة من 1. على سبيل المثال:

"hosting": {
  // ...

  "redirects": [ {
    "regex": "/blog/(?P<post>.+)",  // if you're familiar with PCRE, be aware that RE2 requires named capture groups to begin with ?P
    "destination": "https://blog.myapp.com/:post",  // includes the entire URL segment identified and captured by the `regex` value
    "type": 301
  }, {
    "regex": "/users/(\d+)/profile",  // uses the \d directive to only match numerical path segments
    "destination": "/users/:1/newProfile",  // the first capture group to be seen in the `regex` value is named 1, and so on
    "type": 301
  } ]
}

ضبط عمليات إعادة الكتابة

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

يمكنك أيضًا استخدام عمليات إعادة الكتابة لتتوافق مع التطبيقات التي تستخدم HTML5 pushState للتنقّل. عندما يحاول المتصفّح فتح مسار عنوان URL يتطابق مع نمط عنوان URL المحدّد source أو regex، سيتم منح المتصفّح محتوى الملف المتوفّر على عنوان URL destination بدلاً من ذلك.

حدِّد عمليات إعادة كتابة عناوين URL من خلال إنشاء سمة rewrites تحتوي على صفيف من الكائنات (يُشار إليها باسم "قواعد إعادة الكتابة"). في كل قاعدة، حدِّد نمط عنوان URL إذا كان مطابقًا لمسار عنوان URL الخاص بالطلب، يؤدّي إلى تشغيل Hosting للاستجابة كما لو تم منح الخدمة عنوان URL المقصود المحدّد.

في ما يلي البنية الأساسية لسمة rewrites. يعرض هذا المثال index.html لطلبات الملفات أو الأدلة غير المتوفّرة.

"hosting": {
  // ...

  // Serves index.html for requests to files or directories that do not exist
  "rewrites": [ {
    "source": "**",
    "destination": "/index.html"
  } ]
}

عرض مثال أكثر تفصيلاً لسمة rewrites

"hosting": {
// ...

// Add the "rewrites" attribute within "hosting"
"rewrites": [ {
  // Serves index.html for requests to files or directories that do not exist
  "source": "**",
  "destination": "/index.html"
}, {
  // Serves index.html for requests to both "/foo" and "/foo/**"
  // Using "/foo/**" only matches paths like "/foo/xyz", but not "/foo"
  "source": "/foo{,/**}",
  "destination": "/index.html"
}, {
  // A regular expression-based rewrite equivalent to the above behavior
  "regex": "/foo(/.*)?",
  "destination": "/index.html"
}, {
  // Excludes specified pathways from rewrites
  "source": "!/@(js|css)/**",
  "destination": "/index.html"
} ]
}

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

لا تطبِّق Firebase Hosting قاعدة إعادة كتابة إلا إذا لم يكن هناك ملف أو دليل في مسار عنوان URL يتطابق مع نمط عنوان URL المحدد source أو regex. عندما يؤدي طلب إلى تنشيط قاعدة إعادة كتابة، يعرض المتصفّح المحتوى الفعلي لملف destination المحدّد بدلاً من إعادة توجيه HTTP.

الحقل		الوصف
rewrites
	source (إجراء مُقترَح) أو regex	نمط عنوان URL الذي يؤدي إلى بدء Hosting لتطبيق إعادة الكتابة في حال مطابقته لعنوان URL للطلب الأولي استخدِم source لتحديد تعبير عادي (إجراء مقترَح). استخدِم regex لتحديد تعبير عادي RE2.
	destination	يجب أن يكون هناك ملف محلي وقد يكون عنوان URL هذا مسارًا نسبيًا أو مسارًا مطلقًا.

ملاحظة مهمة: ضمن السمة rewrites، تُطبِّق Hosting عملية إعادة الكتابة التي تحدّدها القاعدة الأولى باستخدام نمط عنوان URL يتطابق مع المسار المطلوب. عليك ترتيب القواعد عمدًا ضمن السمة rewrites.

توجيه الطلبات إلى دالة

يمكنك استخدام rewrites لعرض دالة من عنوان URL Firebase Hosting. المثال التالي هو مقتطف من عرض محتوى ديناميكي باستخدام Cloud Functions.

على سبيل المثال، لتوجيه جميع الطلبات من صفحة /bigben على موقع Hosting الإلكتروني لتنفيذ الدالة bigben:

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": {
      "functionId": "bigben",
      "region": "us-central1"  // optional (see note below)
      "pinTag": true           // optional (see note below)
    }
  } ]
}

طريقة عمل region ضمن العنصر function

في حال حذف region من كتلة function في ملف hosting.rewrites الإعدادات، تحاول وحدة تحكم Firebase لخط الأوامر رصد المنطقة تلقائيًا من رمز المصدر للدالة، والذي يكون تلقائيًا us-central1 في حال عدم تحديده. إذا كان رمز مصدر الدالة غير متاح، يحاول واجهة سطر الأوامر (CLI) اكتشاف المنطقة من الدالة المنشورة. إذا كانت الدالة متوفّرة في مناطق متعدّدة، تتطلّب واجهة برمجة التطبيقات تحديد region في ملف hosting.rewrites الإعدادات.

آلية عمل pinTag ضمن العنصر function

لا تتوفّر ميزة pinTag إلا في Cloud Functions for Firebase (الجيل الثاني). باستخدام هذه الميزة، يمكنك التأكّد من أنّ كل وظيفة لإنشاء المحتوى الديناميكي لموقعك الإلكتروني تتم مزامنتها مع موارد Hosting الثابتة وإعدادات Hosting. تسمح لك هذه الميزة أيضًا بمعاينة إعادة الكتابة إلى الدوال على قنوات معاينة Hosting.

إذا أضفت "pinTag": true إلى كتلة function من hosting.rewrites الإعداد، سيتم نشر الدالة "مُثبَّت" مع موارد Hosting الثابتة وإعداداتها، حتى عند تشغيل firebase deploy --only hosting. في حال العودة إلى نسخة سابقة من موقعك الإلكتروني، يتم أيضًا العودة إلى الحالة "مثبت".

ملاحظة: في حال إضافة pinTag إلى إعادة كتابة حالية، عليك أولاً نشر إعادة الكتابة المعدّلة في القناة "العلنية". بعد هذا النشر، يمكنك بعد ذلك معاينة التغييرات التي تم إجراؤها على رمز الوظيفة في Hosting قنوات المعاينة بدون التأثير في قناة الإصدار العلني.

تعتمد هذه الميزة على علامات Cloud Run، التي يبلغ الحدّ الأقصى لها 1,000 علامة لكل خدمة و2,000 علامة لكل منطقة. ويعني ذلك أنّه بعد إجراء مئات عمليات النشر، قد تتوقف الإصدارات الأقدم من الموقع الإلكتروني عن العمل.

بعد إضافة قاعدة إعادة الكتابة هذه والنشر على Firebase (باستخدام firebase deploy)، يمكن الوصول إلى وظيفتك عبر عناوين URL التالية:

• نطاقك الفرعي في Firebase:
  PROJECT_ID.web.app/bigben و PROJECT_ID.firebaseapp.com/bigben

• أي نطاقات مخصّصة مرتبطة:
  CUSTOM_DOMAIN/bigben

عند إعادة توجيه الطلبات إلى الدوال التي تحتوي على Hosting، تكون طُرق طلبات HTTP المتوافقة هي GET وPOST وHEAD وPUT وDELETE وPATCH وOPTIONS. لا تتوفّر طرق أخرى مثل REPORT أو PROFIND.

توجيه الطلبات مباشرةً إلى حاوية Cloud Run

يمكنك استخدام rewrites للوصول إلى حاوية Cloud Run من عنوان URL للعلامة Firebase Hosting. المثال التالي هو مقتطف من عرض محتوى ديناميكي باستخدام Cloud Run.

على سبيل المثال، لتوجيه جميع الطلبات من الصفحة /helloworld على موقعك الإلكترونيHosting لبدء تشغيل مثيل حاويةhelloworld وتشغيله:

"hosting": {
 // ...

 // Directs all requests from the page `/helloworld` to trigger and run a `helloworld` container
 "rewrites": [ {
   "source": "/helloworld",
   "run": {
     "serviceId": "helloworld",  // "service name" (from when you deployed the container image)
     "region": "us-central1"  // optional (if omitted, default is us-central1)
   }
 } ]
}

طريقة عمل pinTag ضمن مجموعة run

باستخدام هذه الميزة، يمكنك التأكّد من أنّ مراجعة Cloud Run خدمة إنشاء المحتوى الديناميكي لموقعك الإلكتروني تتم مزامنتها مع موارد Hosting الثابتة وإعدادات Hosting. تتيح لك هذه الميزة أيضًا معاينة النصوص المعدَّلة في Cloud Run على Hosting قناة معاينة.

في حال إضافة "pinTag": true إلى كتلة run من hosting.rewrites الإعداد، سيتم تثبيت موارد Hosting الثابتة وإعداداتها في أحدث إصدار من خدمة Cloud Run، في وقت النشر. في حال العودة إلى إصدار سابق من موقعك الإلكتروني، يتم أيضًا العودة إلى الإصدار السابق من خدمة "Cloud Run" "المثبتة".

تعتمد هذه الميزة على علامات Cloud Run، التي يبلغ الحدّ الأقصى لها 1,000 علامة لكل خدمة و2,000 علامة لكل منطقة. ويعني ذلك أنّه بعد إجراء مئات عمليات النشر، قد تتوقف الإصدارات الأقدم من الموقع الإلكتروني عن العمل.

بعد إضافة قاعدة إعادة الكتابة هذه ونشرها على Firebase (باستخدام firebase deploy)، يمكن الوصول إلى صورة الحاوية من خلال عناوين URL التالية:

• النطاقات الفرعية في Firebase:
  PROJECT_ID.web.app/helloworld و PROJECT_ID.firebaseapp.com/helloworld

• أي نطاقات مخصّصة مرتبطة:
  CUSTOM_DOMAIN/helloworld

عند إعادة توجيه الطلبات إلى حاويات Cloud Run باستخدام Hosting، تكون طُرق طلب HTTP المتوافقة هي GET وPOST وHEAD وPUT وDELETE PATCH وOPTIONS. لا يمكن استخدام طرق أخرى مثل REPORT أو PROFIND.

للحصول على أفضل أداء، ضَع خدمة Cloud Run بالقرب من Hosting باستخدام المناطق التالية:

• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

يمكن إعادة الكتابة من Hosting إلى Cloud Run في المناطق التالية:

• asia-east1
• asia-east2
• asia-northeast1
• asia-northeast2
• asia-northeast3
• asia-south1
• asia-south2
• asia-southeast1
• asia-southeast2
• australia-southeast1
• australia-southeast2
• europe-central2
• europe-north1
• europe-southwest1
• europe-west1
• europe-west12
• europe-west2
• europe-west3
• europe-west4
• europe-west6
• europe-west8
• europe-west9
• me-central1
• me-west1
• northamerica-northeast1
• northamerica-northeast2
• southamerica-east1
• southamerica-west1
• us-central1
• us-east1
• us-east4
• us-east5
• us-south1
• us-west1
• us-west2
• us-west3
• us-west4
• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

إنشاء نطاق مخصّص Dynamic Links

يمكنك استخدام rewrites لإنشاء النطاق المخصّص Dynamic Links. يُرجى الانتقال إلى Dynamic Links مستندات للحصول على معلومات مفصّلة حول إعداد نطاق مخصّص لخدمة Dynamic Links.

• استخدِم نطاقك المخصّص فقط لخدمة Dynamic Links.

  "hosting": {
    // ...
  
    "appAssociation": "AUTO",  // required for Dynamic Links (default is AUTO if not specified)
  
    // Add the "rewrites" attribute within "hosting"
    "rewrites": [ {
      "source": "/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/"
      "dynamicLinks": true
    } ]
  }

• تحديد بادئات مسارات النطاق المخصّصة لاستخدامها مع Dynamic Links

  "hosting": {
    // ...
  
    "appAssociation": "AUTO",  // required for Dynamic Links (default is AUTO if not specified)
  
    // Add the "rewrites" attribute within "hosting"
    "rewrites": [ {
      "source": "/promos/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/promos/"
      "dynamicLinks": true
    }, {
      "source": "/links/share/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/links/share/"
      "dynamicLinks": true
    } ]
  }

لإعداد Dynamic Links في ملف firebase.json، يجب ما يلي:

الحقل		الوصف
appAssociation		يجب ضبطه على AUTO في حال عدم تضمين هذه السمة في الإعدادات، تكون القيمة الافتراضية لسمة appAssociation هي AUTO. من خلال ضبط هذه السمة على AUTO، يستطيع Hosting إنشاء ملفات assetlinks.json وapple-app-site-association ديناميكيًا عند طلبها.
rewrites
	source	مسار تريد استخدامه مع Dynamic Links على عكس القواعد التي تعيد كتابة المسارات إلى عناوين URL، لا يمكن أن تحتوي قواعد إعادة الكتابة الخاصة بـ Dynamic Links على تعبيرات منتظمة.
	dynamicLinks	يجب الضبط على true

ملاحظة مهمة: بالنسبة إلى Dynamic Links، يجب الانتباه بشكل خاص إلى ترتيب أولوية الاستضافة.

• تأكَّد من أنّ بادئة عنوان URL للسمة Dynamic Links لا تتعارض مع إعدادات الاستضافة ذات الأولوية الأعلى (على سبيل المثال، تكون الأولوية دائمًا للمحتوى الثابت المستضاف على عمليات إعادة الكتابة).
• ضمن كل من السمتَين redirects وrewrites، يطبِّق Hosting عملية إعادة التوجيه أو إعادة الكتابة المحدّدة في القاعدة الأولى بنمط عنوان URL يتطابق مع المسار المطلوب. لذلك، عليك ترتيب القواعد عمدًا ضمن كل من سمتَي redirects وrewrites.

للحصول على معلومات تفصيلية، يُرجى الرجوع إلى مستندات Dynamic Links .

ضبط العناوين

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

حدِّد عناوين استجابة مخصّصة خاصة بالملف من خلال إنشاء سمة headers تحتوي على صفيف من عناصر العنوان. في كل عنصر، حدِّد نمط عنوان URL يؤدي، في حال مطابقته مع مسار عنوان URL للطلب، إلى تنشيط Hosting لتطبيق عناوين الاستجابة المخصّصة المحدّدة.

في ما يلي البنية الأساسية للسمة headers. يطبّق هذا المثال عنوان CORS على جميع ملفات الخطوط.

"hosting": {
  // ...

  // Applies a CORS header for all font files
  "headers": [ {
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  } ]
}

عرض مثال أكثر تفصيلاً لسمة headers

"hosting": {
  // ...

  // Add the "headers" attribute within "hosting"
  "headers": [ {
    // Applies a CORS header for all font files
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  }, {
    // Overrides the default 1 hour browser cache with a 2 hour cache for all image files
    "source": "**/*.@(jpg|jpeg|gif|png)",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=7200"
    } ]
  }, {
    // A regular expression-based rewrite equivalent to the above behavior
    "regex": ".+/\w+\.(jpg|jpeg|gif|png)$",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=7200"
    } ]
  }, {
    // Sets the cache header for 404 pages to cache for 5 minutes
    "source": "404.html",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=300"
    } ]
  } ]
}

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

الحقل			الوصف
headers
	source (إجراء مُقترَح) أو regex		نمط عنوان URL الذي يؤدي إلى بدء Hosting لتطبيق العنوان المخصّص في حال تطابقه مع عنوان URL للطلب الأولي استخدِم source لتحديد تعبير عادي (إجراء مقترَح). استخدِم regex لتحديد تعبير عادي RE2. لإنشاء عنوان لمطابقته مع صفحة 404 المخصّصة، استخدِم 404.html كقيمة source أو regex.
	صفيف من (العنصر الفرعي)headers		العناوين المخصّصة التي تطبّقها Hosting على مسار الطلب يجب أن يتضمّن كل عنوان فرعي زوجًا من key وvalue (راجِع الصفَين التاليَين).
		key	اسم العنوان، على سبيل المثال Cache-Control
		value	قيمة العنوان، على سبيل المثال max-age=7200

ملاحظة: يتم مطابقة نمط عنوان URL للرؤوس المخصّصة قبل تطبيق أي قواعد إعادة كتابة.

يمكنك الاطّلاع على مزيد من المعلومات حول Cache-Control في القسم Hosting الذي يصف عرض المحتوى الديناميكي واستضافة الخدمات المصغرة. يمكنك أيضًا الاطّلاع على مزيد من المعلومات حول عناوين CORS.

ملاحظة مهمة: تلغي Firebase Hosting إعدادات Strict-Transport-Security في النطاقات الفرعية التلقائية Hosting (مثل *.web.app). ومع ذلك، ستعرض أي نطاقات مخصّصة متصلة القيمة التي تم ضبطها.

التحكّم في .html إضافة

اختيارية
تتيح لك سمة cleanUrls التحكّم في ما إذا كان يجب أن تتضمّن عناوين URL إضافة .html أم لا.

عند استخدام true، يزيل Hosting تلقائيًا امتداد .html من عناوين URL لملف التحميل. إذا تمت إضافة امتداد .html في الطلب، يُجري Hosting عملية إعادة توجيه 301 إلى المسار نفسه، ولكنّه يزيل امتداد .html.

إليك كيفية التحكّم في تضمين .html في عناوين URL من خلال تضمين السمة cleanUrls:

"hosting": {
  // ...

  // Drops `.html` from uploaded URLs
  "cleanUrls": true
}

التحكّم في الشُرطات المائلة في نهاية العنوان

اختيارية
تتيح لك سمة trailingSlash التحكّم في ما إذا كان يجب أن تتضمّن عناوين URL للمحتوى الساكن شرطات سفلية أم لا.

• عندما يكون true، يعيد Hosting توجيه عناوين URL لإضافة الشرطة المائلة للخلف.
• عند false، تعيد Hosting توجيه عناوين URL لإزالة الشرطة المائلة اللاحقة.
• في حال عدم تحديدها، لا يستخدم Hosting الشرطات المائلة للخلف اللاحقة إلا لملفات فهرس الدليل (مثل about/index.html).

في ما يلي كيفية التحكّم في الشُرطات المائلة للخلف من خلال إضافة سمة trailingSlash:

"hosting": {
  // ...

  // Removes trailing slashes from URLs
  "trailingSlash": false
}

لا تؤثّر سمة trailingSlash في عمليات إعادة الكتابة للمحتوى الديناميكي الذي يعرضه Cloud Functions أو Cloud Run.

مطابقة أنماط الكرة الأرضية

تستفيد خيارات إعدادات Firebase Hosting بشكل كبير من رمز مطابقة نمط globbing مع extglob، على غرار الطريقة التي يعالج بها Git قواعد gitignore وBower قواعد ignore. صفحة الموسوعة هذه هي مرجع أكثر تفصيلاً، ولكن في ما يلي تفسيرات للأمثلة المستخدَمة في هذه الصفحة:

• firebase.json - لا يتطابق إلا مع ملف firebase.json في الجذر للدليل public

• **: تطابق أي ملف أو مجلد في دليل فرعي عشوائي

• ‫* - لا تتطابق إلا مع الملفات والمجلدات في جذر دليل public

• **/.* - تطابق أي ملف يبدأ بالرمز . (عادةً الملفات المخفية، مثل الملفات في المجلد .git) في دليل فرعي عشوائي

• **/node_modules/**: تطابق أي ملف أو مجلد في دليل فرعي محدد مسبقًا من مجلد node_modules، والذي يمكن أن يكون هو نفسه في دليل فرعي محدد مسبقًا من دليل public

• **/*.@(jpg|jpeg|gif|png) - تطابق أي ملف في ملف فرعي عشوائي ينتهي بأحد العناصر التالية بالضبط: .jpg أو .jpeg أو .gif أو .png

مثال على الإعداد الكامل لـ Hosting

في ما يلي مثال كامل على إعدادات firebase.json لملف Firebase Hosting. يُرجى العلم أنّ ملف firebase.json يمكن أن يحتوي أيضًا على إعدادات لخدمات Firebase الأخرى.

{
  "hosting": {

    "public": "dist/app",  // "public" is the only required attribute for Hosting

    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],

    "redirects": [ {
      "source": "/foo",
      "destination": "/bar",
      "type": 301
    }, {
      "source": "/firebase/**",
      "destination": "https://www.firebase.com",
      "type": 302
    } ],

    "rewrites": [ {
      // Shows the same content for multiple URLs
      "source": "/app/**",
      "destination": "/app/index.html"
    }, {
      // Configures a custom domain for Dynamic Links
      "source": "/promos/**",
      "dynamicLinks": true
    }, {
      // Directs a request to Cloud Functions
      "source": "/bigben",
      "function": "bigben"
    }, {
      // Directs a request to a Cloud Run containerized app
      "source": "/helloworld",
      "run": {
        "serviceId": "helloworld",
        "region": "us-central1"
      }
    } ],

    "headers": [ {
      "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
      "headers": [ {
        "key": "Access-Control-Allow-Origin",
        "value": "*"
      } ]
    }, {
      "source": "**/*.@(jpg|jpeg|gif|png)",
      "headers": [ {
        "key": "Cache-Control",
        "value": "max-age=7200"
      } ]
    }, {
      "source": "404.html",
      "headers": [ {
        "key": "Cache-Control",
        "value": "max-age=300"
      } ]
    } ],

    "cleanUrls": true,

    "trailingSlash": false,

    // Required to configure custom domains for Dynamic Links
    "appAssociation": "AUTO",

  }
}