سياسة المنشأ المشتركة و CORS: دليل مرئي

يوم جيد ، أيها الأصدقاء!



أقدم انتباهكم إلى ترجمة مقال "CS Visualized: CORS" بقلم ليديا هالي.



كان على كل مطور أن يتعامل مع خطأ Access to fetched has been blocked by CORS policy. هناك عدة طرق لحل هذه المشكلة بسرعة. ومع ذلك ، فلنأخذ وقتنا ونلقي نظرة فاحصة على ماهية سياسة CORS.



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



لنفترض أننا نريد الحصول على معلومات حول مستخدم على موقعنا www.mywebsite.comمن خادم موجود على الموقع api.website.com.







ممتاز! لقد أرسلنا للتو طلبًا إلى الخادم وتلقينا بيانات JSON في المقابل.



لنحاول الآن إرسال طلب مماثل إلى مجال آخر. بدلاً من إرسال طلب باستخدام ، دعنا www.mywebsite.comنرسله مع www.anotherdomain.com.







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



نحن نرى CORS قيد التنفيذ. لماذا حدث هذا الخطأ وماذا يعني؟

سياسة المنشأ المشتركة

هناك شيء ما على الويب يسمى سياسة المنشأ العامة (يشار إليها فيما يلي باسم POP). بشكل افتراضي ، لدينا فقط إمكانية الوصول إلى تلك الموارد التي هي من نفس أصل أصل طلبنا. على سبيل المثال ، يمكننا تحميل صورة موجودة في https://mywebsite.com/image1.png.



يختلف المصدر عندما يكون موجودًا في مجال أو بروتوكول أو منفذ مختلف (فرعي).







رائع ، لكن لماذا تحتاج إلى بروتوكول POP؟



لنفترض أنه غير موجود ، ونقرت بطريق الخطأ على رابط فيروسي نشرته عمتك على Facebook. يقوم هذا الارتباط بإعادة توجيهك إلى "موقع ضار" يحتوي على إطار iframe مضمن يقوم بتحميل موقع البنك الذي تتعامل معه ويسجّل الدخول إليه بنجاح باستخدام ملف تعريف ارتباط.



تأكد مطورو "الموقع الشرير" من أنه يمكنه الوصول إلى iframe ويمكنه التفاعل مع محتوى DOM الخاص بموقع البنك الذي تتعامل معه لتحويل الأموال إلى حسابه نيابة عنك.







نعم ... هذه مشكلة أمنية خطيرة. لا نريد لأي شخص الوصول إلى أي شيء دون علمنا.



لحسن الحظ ، يوجد EPP. هذه السياسة تقيد الوصول إلى الموارد من مصادر أخرى.







في هذه الحالة ، www.evilwebsite.comيحاول المصدر الوصول إلى المورد من المصدر www.bank.com. يحظر EPP هذا الوصول ويمنع مطوري المواقع السيئين من الوصول إلى بياناتك المصرفية.



حسنًا ، لكن ... كيف يعمل؟

جانب العميل CORS

على الرغم من حقيقة أن EPP ينطبق فقط على البرامج النصية ، إلا أن المتصفحات "توسعها" لتشمل أي طلبات JavaScript: افتراضيًا ، لا يمكننا الوصول إلا إلى الموارد من مصدر واحد.







حسنًا ، لكن ... غالبًا ما نحتاج إلى الحصول على موارد من مصدر آخر. ربما تحتاج الواجهة الأمامية لدينا إلى الانتقال إلى خادم API لتحميل البيانات. لاسترداد الموارد بأمان من مصادر أخرى ، تنفذ المتصفحات آلية تسمى CORS.



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



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



عند تقديم طلب إلى مصدر آخر ، يضيف العميل تلقائيًا رأسًا لطلب HTTP Origin. قيمة هذا الرأس هي أصل الطلب.







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

جانب الخادم CORS

بصفتنا مطوري الواجهة الخلفية ، يمكننا السماح لمصادر أخرى بالحصول على مواردنا من خلال تضمين رؤوس خاصة تبدأ بـ Access-Control-*. بناءً على قيمة هذه الرؤوس ، يسمح المستعرض بمشاركة الموارد.



هناك العديد من CORS الرؤوس، ولكن واحد منهم أمر لا بد منه: Access-Control-Allow-Origin.



يحدد معنى هذا العنوان المصادر التي يمكن أن تتلقاها مواردنا.



إذا كنا نطور خادمًا يحتاج إلى الوصول إليه https://mywebsite.com، فعلينا إضافة هذا المجال إلى العنوان Access-Control-Allow-Origin.







عظيم. تتم إضافة هذا الرأس الآن إلى استجابة الخادم المرسلة إلى العميل. لم يعد EPP يمنعنا من تلقي الموارد من https://api.mywebsite.comخلال الطلبات المرسلة من https://mywebsite.com.







تتحقق آلية CORS في المستعرض من تطابق Access-Control-Allow-Originرأس الاستجابة وقيم رأس الطلب Origin.



في هذه الحالة ، يكون مصدر طلبنا هو عنوان https://www.mywebsite.comالاستجابة المحدد في القائمة Access-Control-Allow-Origin.







ممتاز. الآن يمكننا الحصول على الموارد من مصادر أخرى. ماذا يحدث إذا حاولنا القيام بذلك من مصدر غير مدرج في القائمة Access-Control-Allow-Origin؟







نعم ، حظر CORS الوصول إلى الموارد.

The 'Access-Control-Allow-Origin' header has a value
  'https://www.mywebsite.com' that is not equal 
to the supplied origin. 

في هذه الحالة ، https://www.anotherwebsite.comلا يتم سرد المصدر في Access-Control-Allow-Origin. رفض CORS بنجاح البيانات المطلوبة.



يسمح CORS بتحديد *المصادر المسموح بها كقيمة. هذا يعني أن الموارد ستكون متاحة لأي مصدر ، لذا كن حذرًا.



Access-Control-Allow-Originهو واحد من العديد من العناوين التي يمكننا تعيينها. يمكن لمطور الواجهة الخلفية تكوين CORS للسماح (رفض) الطلبات المحددة.



عنوان مشترك آخر هو Access-Control-Allow-Methods. يسمح CORS فقط بالطلبات من المصادر الأخرى التي تم إرسالها باستخدام الطرق المحددة.







في هذه الحالة ، يُسمح فقط بالطلبات المرسلة باستخدام طرق GET أو POST أو PUT. سيتم حظر طرق أخرى مثل PATCH أو DELETE.



يعاملهم CORS بطريقة خاصة عندما يتعلق الأمر بالطلبات المرسلة باستخدام طرق PUT و PATCH و DELETE. يشار إلى هذه الاستعلامات "الصعبة" أحيانًا باسم استعلامات الاختبار المبدئي.

الطلبات الأولية

يعمل CORS مع نوعين من الطلبات: بسيط ومؤقت. يعتمد ماهية الاستعلام على بعض قيمه.



يكون الطلب بسيطًا إذا تم إرساله باستخدام طرق GET أو POST ولا يحتوي على رؤوس إضافية. أي طلب آخر أولي.



حسنًا ، ولكن ماذا يعني الطلب المسبق ولماذا هناك حاجة لمثل هذه الطلبات؟



قبل إرسال الطلب الفعلي ، يرسل العميل طلبًا أوليًا إلى الخادم مع معلومات حول الطلب الفعلي: حول طريقته ، والعناوين الإضافية ، بما في ذلك Access-Control-Request-*، إلخ.







يتلقى الخادم طلبًا مؤقتًا ويرسل ردًا مؤقتًا فارغًا يحتوي على رؤوس CORS. يتلقى المتصفح استجابة مؤقتة ويتحقق مما إذا كان الطلب الفعلي سيسمح به.







إذا كان الأمر كذلك ، فإن المتصفح يرسل الطلب الفعلي ويتلقى البيانات في المقابل.







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



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

شهاداته

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



على الرغم من أن CORS لا تحتوي على أذونات افتراضيًا ، يمكننا تغيير ذلك باستخدام رأس Access-Control-Allow-Credentials.



إذا أردنا تضمين ملفات تعريف الارتباط ورؤوس التفويض الأخرى في طلبنا من مصدر آخر ، فنحن بحاجة إلى تعيين الحقل إلى withCredentialsقيمة trueفي الطلب وإضافة العنوان Access-Control-Allow-Credentialsإلى الاستجابة.







انتهى ، يمكننا الآن تضمين بيانات الاعتماد في طلباتنا من مصدر آخر.



آمل أن تكون هذه المقالة مفيدة لك. شكرآ لك على أهتمامك.