مشاركة الموارد المتعدّدة المصادر (CORS)

مشاركة المراجع المشتركة المنشأ بأمان

Mariko Kosaka
X

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

غالبًا ما تحتاج تطبيقات الويب الحديثة إلى الحصول على موارد من مصدر مختلف، على سبيل المثال، استرجاع بيانات JSON من نطاق مختلف أو تحميل صور من موقع إلكتروني آخر إلى عنصر <canvas>. يمكن أن تكون هذه موارد عامة يُفترَض أن تكون متاحة لأي شخص لقراءتها، ولكن سياسة المصدر نفسه تحظر استخدامها. في السابق، كان المطوّرون يستخدمون حلولًا بديلة، مثل JSONP.

يحلّ بروتوكول مشاركة الموارد المتعدّدة المصادر (CORS) هذه المشكلة بطريقة موحّدة. يتيح تفعيل سياسة مشاركة الموارد المتعددة المصادر (CORS) للخادم إعلام المتصفّح بأنّه يمكنه استخدام مصدر إضافي.

كيف يعمل طلب الموارد على الويب؟

الطلب والاستجابة
طلب العميل الموضح واستجابة الخادم

يمكن للمتصفح والخادم تبادل البيانات عبر الشبكة باستخدام بروتوكول نقل الروابط النصية (HTTP). يحدِّد بروتوكول HTTP قواعد التواصل بين العميل والمسؤول عن الاستجابة، بما في ذلك المعلومات المطلوبة للحصول على مورد.

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

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

نموذج لعنوان الطلب

Accept: text/html
Cookie: Version=1

يعادل هذا العنوان قول "أريد تلقّي محتوى HTML في الردّ. إليك ملف تعريف ارتباط لديّ."

نموذج لعنوان الاستجابة

Content-Encoding: gzip
Cache-Control: no-store

يعادل هذا العنوان قول "البيانات في هذه الاستجابة مشفرة باستخدام gzip. لا تخزِّن هذا المحتوى مؤقتًا".

الجسم

الرسالة نفسها ويمكن أن يكون هذا النص العادي أو ملف ثنائي لصورة أو JSON أو HTML أو العديد من التنسيقات الأخرى.

كيف تعمل سياسة مشاركة الموارد المتعددة المصادر (CORS)؟

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

الخطوة 1: طلب العميل (المتصفّح)

عندما يُرسل المتصفّح طلبًا من مصدر آخر، يضيف المتصفّح عنوان Origin مع المصدر الحالي (البروتوكول والمضيف والمنفذ).

الخطوة 2: استجابة الخادم

عندما يرى الخادم هذا العنوان ويريد السماح بالوصول، يضيف عنوان Access-Control-Allow-Origin إلى الاستجابة لتحديد مصدر العميل المُقدّم للطلب (أو * للسماح بأي مصدر).

الخطوة 3: يتلقّى المتصفّح الردّ

عندما يتلقّى المتصفّح هذه الاستجابة مع عنوان Access-Control-Allow-Origin مناسب، يشارك بيانات الاستجابة مع موقع العميل الإلكتروني.

مشاركة بيانات الاعتماد مع سياسة مشاركة الموارد المتعددة المصادر (CORS)

لأسباب تتعلّق بالخصوصية، يتم استخدام سياسة مشاركة الموارد المتعددة المصادر (CORS) عادةً للطلبات المجهولة المصدر، والتي لا يتم فيها تحديد هوية مقدم الطلب. إذا كنت تريد إرسال ملفات تعريف الارتباط عند استخدام واجهة برمجة التطبيقات CORS التي يمكنها تحديد المُرسِل، عليك إضافة رؤوس إضافية إلى الطلب والردّ.

الطلب

أضِف credentials: 'include' إلى خيارات الجلب كما هو موضّح في المثال التالي. ويشمل هذا ملف تعريف الارتباط مع الطلب على النحو التالي:

fetch('https://example.com', {
  mode: 'cors',
  credentials: 'include'
})

الرد

يجب ضبط Access-Control-Allow-Origin على مصدر محدّد (بدون استخدام العلامة النائبة *) وAccess-Control-Allow-Credentials على true.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

طلبات الفحص المُسبَق لطلبات HTTP المعقّدة

عندما يُقدّم تطبيق ويب طلب HTTP معقّدًا، يُضيف المتصفّح طلب التحقّق من الإعداد إلى بداية سلسلة الطلبات.

تحدد مواصفات CORS الطلب المعقد على النحو التالي:

  • يشير هذا المصطلح إلى طلب يستخدم طرقًا أخرى غير GET أو POST أو HEAD.
  • طلب يتضمّن عناوين غير Accept أو Accept-Language أو Content-Language
  • طلب يتضمّن عنوان Content-Type غير application/x-www-form-urlencoded أو multipart/form-data أو text/plain

تنشئ المتصفّحات تلقائيًا أي طلبات فحص ما قبل النشر ضرورية وترسلها قبل رسالة الطلب الفعلية. طلب الفحص المُسبَق هو طلب OPTIONS مثل المثال التالي:

OPTIONS /data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: DELETE

من جهة الخادم، يستجيب التطبيق الذي يتلقّى الطلب لطلب التحقّق من التشغيل الآمن مع تضمين معلومات عن الطرق التي يقبلها التطبيق من هذا المصدر:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

يمكن أن يتضمّن ردّ الخادم أيضًا عنوان Access-Control-Max-Age لتحديد المدة بالثواني لتخزين نتائج التحقّق من التوافق مؤقتًا. يتيح ذلك لل العميل إرسال طلبات معقدة متعددة بدون الحاجة إلى تكرار طلب التحقّق من الإعدادات.