Loading...

مساعدة CDN.com.tr

ترويسات CORS على الحافة

أضف Access-Control-Allow-Origin وترويسات CORS الأخرى إلى استجابات قاعدة تسليم، ودع خادمك الأصلي يجيب على طلبات preflight من نوع OPTIONS، واسمح في WAF بالطرق التي يستخدمها الـAPI الخاص بك.

ترويسات CORS على الحافة

أضف Access-Control-Allow-Origin وترويسات CORS الأخرى إلى استجابات قاعدة تسليم، ودع خادمك الأصلي يجيب على طلبات preflight من نوع OPTIONS، واسمح في WAF بالطرق التي يستخدمها الـAPI الخاص بك.

أدلة ذات صلة

كيف يعمل CORS في المتصفح، وكيف تقرأ طلبًا رفضته الحافة، وما الذي يتلقاه خادمك الأصلي أيضًا من الحافة.

خلفية

ما هو CORS؟ قاعدة المتصفح وراء كل خطأ cross-origin

الطلبات البسيطة وطلبات preflight وبيانات الاعتماد، مع اختبارات curl.

اقرأ الدليل
استجابة 403 من الحافة

قراءة سجلات WAF

اعثر على طلب مرفوض بحسب الوقت أو Reference ID، واعرف أي قاعدة حظرته.

افتح الموضوع
خادمك الأصلي

اتصال الخادم الأصلي: عنوان IP الحقيقي للزائر، وتأمين خادمك الأصلي، وWebSocket، ومهلات الانتظار

الترويسات المرسلة إلى خادمك الأصلي، وطرق WAF التي يحتاجها الـAPI.

افتح الموضوع

مسار اللوحة

  1. لوحة الإدارة
  2. قواعد التسليم
  3. القواعد
  4. تعديل
  5. الرؤوس
  6. إضافة رؤوس للاستجابة

المتطلبات المسبقة

  • قاعدة تسليم تقدّم المسارات التي يطلبها الموقع الآخر.
  • الأصل الدقيق للموقع الطالب، مثل https://app.example.com، أو * للملفات التي يحق لأي أحد تحميلها.
  • لاستدعاءات API التي ترسل طلب preflight: يجيب خادمك الأصلي على OPTIONS في تلك المسارات بـ200 أو 204.
  • دور المالك أو المحرّر: يستطيع المشاهدون رؤية القواعد، لكن لا يستطيعون تغييرها.

نموذج القرار

ملفات عامة أم API؟

ما يرسله المتصفح يحدد أين يجري العمل.

  • الخطوط والصور وJSON العام التي تُحمَّل بطلب GET عادي: لا يوجد طلب preflight، ويكفيها Access-Control-Allow-Origin في القاعدة. وما دام تحسين الصور على مستوى الحساب مفعّلًا، تأخذ ملفات .jpg و.jpeg و.png ترويسات الاستجابة الخاصة بأقدم قاعدة للنطاق، لا بالقاعدة الخاصة بمسارها.
  • استدعاءات API بأجسام JSON أو ترويسات مخصّصة أو PUT وPATCH وDELETE: يرسل المتصفح طلب preflight أولًا؛ يجيب عليه خادمك الأصلي، ويمكن للقاعدة أن تضيف ترويسات CORS إلى تلك الاستجابة.
  • الطلبات التي تحمل ملفات تعريف الارتباط أو بيانات اعتماد أخرى: أصل واحد محدَّد بالاسم، لا *، إضافةً إلى Access-Control-Allow-Credentials true.

كل ترويسة من الحافة أم من خادمك الأصلي؟

اختر مصدرًا واحدًا لكل ترويسة.

  • الحافة (القاعدة): قيمة ثابتة واحدة في كل استجابة 2xx و3xx، بما فيها الاستجابات المقدَّمة من التخزين المؤقت، وفي استجابات 4xx و5xx من خادمك الأصلي أيضًا إذا انتهى السطر بـalways.
  • الخادم الأصلي: قيمة تعتمد على الموقع الطالب، تُرسل مع Vary: Origin.
  • يرسلها الاثنان: حدّدها ضمن إزالة رؤوس، لتخرج قيمة القاعدة وحدها.

دليل خطوة بخطوة

1

أضف الترويسات إلى القاعدة

مثال لـAPI ضمن /api/ يستدعيه تطبيق ويب واحد. اكتب ترويسة واحدة في كل سطر؛ والقيمة التي تحتوي مسافات تُكتب بين علامتي اقتباس مزدوجتين.

  • افتح قواعد التسليم ← القواعد واضغط تعديل على قاعدة /api/.
  • ضمن عندئذٍ ← الرؤوس، اكتب في إضافة رؤوس للاستجابة، كلًّا في سطر مستقل: Access-Control-Allow-Origin https://app.example.com وAccess-Control-Allow-Methods "GET, POST, PUT, OPTIONS" وAccess-Control-Allow-Headers "Content-Type, Authorization" وAccess-Control-Max-Age 600.
  • ضمن إزالة رؤوس، حدّد أيًّا من هذه الأسماء يرسله خادمك الأصلي أيضًا.
  • اضغط حفظ القاعدة.

النتيجة المتوقعة: تُظهر القاعدة شارة مثل +4 من ترويسات الاستجابة، وتُظهر الصفحة منشور بمجرد أن تقدّمها الحافة.

2

اسمح بطرق الـAPI في WAF

مطلوب ما دام WAF على مستوى الموقع مفعّلًا وكان الـAPI يستخدم طرقًا غير GET وHEAD وPOST وOPTIONS.

  • في الشريط الجانبي، افتح WAF Logs ضمن Protection.
  • ضمن طرق HTTP المسموح بها، حدّد PUT أو PATCH أو DELETE بحسب حاجة الـAPI الخاص بك، وأبقِ OPTIONS محدَّدة، واضغط Save.

النتيجة المتوقعة: تؤكد اللوحة الحفظ، وينتشر التغيير خلال 1-2 دقيقة.

3

تحقق من طلب بسيط ومن طلب preflight

لا يفرض curl قواعد CORS، لذا يُظهر بالضبط ما تجيب به الحافة.

  • اطلب نقطة النهاية مع ترويسة Origin.
  • أرسل طلب preflight كما يرسله المتصفح: OPTIONS مع Origin وAccess-Control-Request-Method وAccess-Control-Request-Headers.

النتيجة المتوقعة: يحمل الطلب البسيط access-control-allow-origin واحدة. ويجيب طلب preflight بـ200 أو 204 مع الأصل والطرق والترويسات المسموح بها.

cdnctl equivalent
curl -s -o /dev/null -D - -H 'Origin: https://app.example.com' https://www.example.com/api/items | grep -iE '^(HTTP|access-control)'
curl -s -o /dev/null -D - -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type' https://www.example.com/api/items | grep -iE '^(HTTP|access-control|x-mt-blocked-by)'

التحقق

  • curl -s -o /dev/null -D - -H 'Origin: https://app.example.com' https://www.example.com/api/items | grep -iE '^(HTTP|access-control)' → 2xx وaccess-control-allow-origin واحدة بالضبط: https://app.example.com
  • curl -s -o /dev/null -D - -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: PUT' -H 'Access-Control-Request-Headers: content-type' https://www.example.com/api/items | grep -iE '^(HTTP|access-control|x-mt-blocked-by)' → 200 أو 204 مع access-control-allow-origin وaccess-control-allow-methods وaccess-control-allow-headers
  • استجابة 403 مع x-mt-blocked-by: cdn-edge-security على طلب → رفضته الحافة (WAF، أو حظر IP أو بلد أو شبكة أو hotlink)؛ تحقق من طرق HTTP المسموح بها ومن سجلات WAF

حالات الاستخدام

يحمّل تطبيق ويب على app.example.com خطوطًا أو JSON أو استجابات API من www.example.com، فيحظرها المتصفح بخطأ CORS.

سير عمل سريع

  1. افتح قواعد التسليم، وانتقل إلى تبويب القواعد واضغط تعديل على القاعدة التي تقدّم المسارات التي يطلبها الموقع الآخر، أو إضافة قاعدة لمسار جديد.
  2. ضمن عندئذٍ، افتح الرؤوس واكتب في إضافة رؤوس للاستجابة ترويسة واحدة في كل سطر بصيغة Header-Name value، دون نقطتين، مثل Access-Control-Allow-Origin https://app.example.com. والقيمة التي تحتوي مسافات تُكتب بين علامتي اقتباس مزدوجتين.
  3. إذا كان خادمك الأصلي يرسل بالفعل ترويسة Access-Control-* لهذه المسارات، فحدّد الاسم نفسه ضمن إزالة رؤوس، ليتلقى المتصفح قيمة واحدة.
  4. اضغط حفظ القاعدة (إنشاء القاعدة لقاعدة جديدة) وانتظر حتى تُظهر الصفحة منشور.
  5. إذا كان الـAPI الخاص بك يستخدم PUT أو PATCH أو DELETE وكان WAF على مستوى الموقع مفعّلًا، فحدّدها ضمن طرق HTTP المسموح بها في صفحة Security.
  6. تحقق من طلب بسيط ومن طلب preflight باستخدام curl.

الفحوصات

  • تُضاف ترويسات القاعدة إلى الاستجابات الناجحة واستجابات إعادة التوجيه (2xx و3xx)، بما فيها الاستجابات المقدَّمة من التخزين المؤقت، منذ لحظة نشر القاعدة. والسطر الذي ينتهي بـalways يُضاف أيضًا إلى استجابات 4xx و5xx من خادمك الأصلي.
  • تذهب طلبات preflight من نوع OPTIONS إلى خادمك الأصلي ولا تُخزَّن مؤقتًا أبدًا. عندما يجيب خادمك الأصلي على طلب preflight بـ200 أو 204، تُضاف ترويسات القاعدة إلى تلك الاستجابة؛ أما طلب preflight الذي يُجاب بـ401 أو 404 أو 405 فيصل إلى المتصفح دونها، ما لم ينتهِ السطر بـalways. وفي قاعدة فيها الحماية بكلمة مرور أو قائمة السماح لعناوين IP، تجيب الحافة بنفسها على طلب preflight الذي لا تسمح بمروره، بـ401 أو 403.
  • تصل إلى المتصفح ترويسة Access-Control-Allow-Origin واحدة بالضبط: إذا وصلت قيمتان، يرفض المتصفح الاستجابة.
  • إذا كان خادمك الأصلي يغيّر Access-Control-Allow-Origin بحسب الموقع الطالب، فيجب أن يرسل أيضًا Vary: Origin. وتُبقي الحافة هذه النسخ منفصلة ما دام احتفظ بنسخة مخزنة واحدة مهما كان رأس Vary معطّلًا في القاعدة.
  • اترك Access-Control-Request-Method وAccess-Control-Request-Headers دون تحديد ضمن إزالة رؤوس: الأسماء المحدَّدة هناك تُزال أيضًا من الطلبات المرسلة إلى خادمك الأصلي، وخادمك الأصلي يقرأ هاتين الترويستين ليجيب على طلب preflight.
  • مع تفعيل WAF على مستوى الموقع، يُسمح افتراضيًا بـGET وHEAD وPOST وOPTIONS. والطلب الذي يستخدم طريقة غير موجودة في القائمة يتلقى 403 دون ترويسات CORS ومع X-MT-Blocked-By: cdn-edge-security، ويعرضه المتصفح على أنه خطأ CORS.
  • ما دام تحسين الصور على مستوى الحساب مفعّلًا، تحصل ملفات .jpg و.jpeg و.png على ترويسات الاستجابة الخاصة بأقدم قاعدة للنطاق، لا بالقاعدة الخاصة بمسارها: ضع ترويسة CORS لهذه الصور في تلك القاعدة، مع قيمة ثابتة لـAccess-Control-Allow-Origin. وعندما تكون تلك القاعدة الأقدم هي قاعدة التحقق من الشهادة، لا تحصل على أي ترويسات من القواعد.

الأسئلة الشائعة

هل تجيب الحافة على طلبات preflight بنفسها؟

تمرّر الحافة طلبات OPTIONS إلى خادمك الأصلي ولا تخزّنها مؤقتًا أبدًا، لذا يجب أن يجيب خادمك الأصلي على طلب preflight بـ200 أو 204. وتُضاف ترويسات الاستجابة الخاصة بالقاعدة إلى تلك الاستجابة: يمكن أن تأتي ترويسات CORS من القاعدة، ولا يلزم خادمك الأصلي سوى قبول OPTIONS. الاستثناء: في قاعدة فيها الحماية بكلمة مرور أو قائمة السماح لعناوين IP، تجيب الحافة بنفسها على طلب preflight الذي لا تسمح بمروره، بـ401 أو 403.

هل يمكن لقاعدة واحدة أن تسمح لعدة مواقع؟

تضيف القاعدة القيمة نفسها إلى كل استجابة: * أو أصلًا واحدًا مثل https://app.example.com. وللسماح بعدة أصول، دع تطبيقك يرسل الأصل المطابق مع Vary: Origin، ولا تضع Access-Control-Allow-Origin في القاعدة. والطلبات التي تحمل ملفات تعريف الارتباط أو بيانات اعتماد أخرى تحتاج إلى أصل محدَّد بالاسم، لا *.

لا يزال المتصفح يُبلغ عن خطأ CORS. ما الذي أتحقق منه؟

ابدأ بحالة الطلب الفاشل في لوحة الشبكة في المتصفح. استجابة 403 مع X-MT-Blocked-By: cdn-edge-security تأتي من الحافة: ابحث عنها في سجلات WAF، وإذا كانت طريقتها غير موجودة في القائمة، فأضفها ضمن طرق HTTP المسموح بها. وأي استجابة 4xx أو 5xx أخرى تصل افتراضيًا دون ترويسات القاعدة، فأصلح تلك الاستجابة أولًا. والسطر الذي ينتهي بـalways، مثل Access-Control-Allow-Origin https://app.example.com always، يُضاف أيضًا إلى استجابات 4xx و5xx من خادمك الأصلي. ثم تحقق من وصول Access-Control-Allow-Origin واحدة بالضبط وأنها تطابق الموقع الطالب، بما في ذلك المخطط (scheme).

يستخدم الـAPI الخاص بي PUT أو PATCH أو DELETE. ماذا أغيّر؟

ما دام WAF على مستوى الموقع مفعّلًا، افتح صفحة Security، وحدّد الطرق ضمن طرق HTTP المسموح بها واضغط Save؛ ينتشر التغيير خلال 1-2 دقيقة. ويفتح أساليب الطلب المسموح بها في تبويب الأمان في قواعد التسليم البطاقةَ نفسها. أبقِ OPTIONS محدَّدة: ترسلها المتصفحات لطلبات preflight.