[موسيقى]
دعونا نتحدث في بعض لغة كورس الآن.
الآن ما هو بالضبط تبادل النتائج عبر الأصل،
ولماذا هو ذات الصلة عندما ننظر إلى تطبيقات الويب
والتطبيقات فائقة المحمول كما كنا نفعل في هذا التخصص؟
كما تفهم، فإن معظم صفحات الويب تسحب الآن البيانات من
العديد من المواقع المختلفة من أجل إنشاء صفحة ويب.
الآن، من أجل فرض سياسة صارمة للوصول إلى الموارد من مواقع مختلفة،
تم فرض نفس سياسة الأصل من قبل العديد من المتصفحات.
سنتحدث قليلاً عن ذلك بمزيد من التفصيل في الشرائح القليلة القادمة، ولكن في
سياق الأطر التي كنا نناقشها في هذا
التخصص الخاص، مثل Angular و Ionic و NativeScript،
فإن العديد من هذه تتضمن نصوص برمجية، شفرة جافا سكريبت،
التي قد تضطر إلى الوصول إلى الموارد من مواقع مختلفة.
وهذا هو المكان الذي تزرع فيه مشكلة CORS بسهولة كبيرة.
دعونا نرى كيف سنتناول هذه المسألة بمزيد من التفصيل في هذه المحاضرة
والممارسة التالية.
ألمحت بإيجاز إلى سياسة الأصل نفسه التي بدأت هذه المحاضرة.
الآن، سياسة المصدر نفسه هي نموذج أمان تطبيق ويب
يقيد كيفية
تفاعل مستند أو برنامج نصي تم تحميله من أصل واحد مع الموارد من أصل آخر.
والغرض من ذلك هو عزل الوثائق التي يحتمل أن تكون ضارة.
من الواضح الآن أنه عندما يكون لديك صفحة ويب تتضمن نصًا برمجيًا
، شفرة جافا سكريبت، والتي قد تصل إلى الموارد من موقع آخر،
يمكن حقن الشفرة الضارة في صفحة الويب الخاصة بك
، حيث الوصول إلى أصل مختلف عن المكان الذي يتم فيه الحصول على صفحة الويب الخاصة بك.
الآن، هذا هو السبب في أن العديد من المتصفحات تفرض سياسة المصدر نفسه.
الآن، عندما نتحدث عن نفس الأصل، كيف نحدد أصل؟
الآن في هذا السياق، يتم تعريف أصل لأي مورد من خلال ثلاث مجموعات.
أولاً، البروتوكول المستخدم للوصول إلى المورد.
ثانياً، اسم المضيف للمورد أو مجال هذا المورد.
وثالثا، رقم المنفذ الذي يتم فيه الوصول إلى هذا المورد.
إذن هذه هي الطريقة التي نحدد بها أصل أي مورد.
يمكن أن يكون المورد في هذه الحالة صفحة html، وصورة،
وبيانات JSON التي يتم الحصول عليها من نقطة نهاية REST API، وغيرها الكثير.
لمزيد من التفاصيل حول سياسة المصدر نفسه، دعونا ننظر إلى مثال.
لنفترض أن لدينا صفحة ويب يتم تحميلها من هذا الموقع المدرج هنا،
www.abc.com، وفي مجلد xyz،
ويتم تحميل page.html هنا.
قد تتضمن هذه الصفحة روابط أو حتى شفرة جافا سكريبت التي قد
تصدر XMLHttpRequest إلى موارد أخرى على صفحة الويب.
الآن، في هذه الحالة، إذا حاولنا الوصول إلى عنوان URL آخر
، على سبيل المثال، أول عنوان مدرج هنا، والذي من الواضح أنك تراه
من نفس الموقع ولكن من مجلد مختلف.
هذا مقبول، لأن الأصل، في هذه الحالة،
البروتوكول المستخدم ورقم المنفذ، لا يزال هو نفسه.
لذلك، هذا مقبول للوصول إلى هذا المورد.
وبالمثل في الحالة الثانية، قد يكون لدينا تحت
عدة مستويات من المجلدات الفرعية مورد يتم الوصول إليه.
ولكن مرة أخرى، لأن أصلهم لا يزال هو نفسه، وهو أمر مقبول.
ولكن دعونا ننظر إلى المثال الثالث هنا.
في هذا المثال، نرى أننا نحاول الوصول إلى مورد هنا باستخدام
بروتوكول https، والذي ينتهك بوضوح الأصل نفسه
لأننا نستخدم بروتوكول مختلف للوصول إلى هذا المورد في هذه المرحلة.
بحيث يعتبر ذلك فشلاً في هذه الحالة.
الحالة الرابعة هي المكان الذي نصل فيه إلى مورد برقم منفذ مختلف.
والحالة الخامسة هي حيث نصل إلى مورد في مضيف مختلف.
الآن، سيتم وضع علامة على كل هذه الثلاثة على أنها غير صالحة أو
لا يمكن الوصول إليها بموجب سياسة المصدر نفسه.
لذلك إذا فرضت سياسة المصدر نفسه للوصول من، على سبيل المثال،
XMLHttpRequest الخاص بك، فلن يُسمح بالثلاثة الأخيرة في هذه الحالة.
ولكن بالطبع، هناك العديد من الحالات التي
قد يستضيف فيها مصمم الموقع بالفعل موارد على مواقع مختلفة، ربما على نطاقات مختلفة،
ولا يزال قادرًا على سحب البيانات من أجل إنشاء صفحة
الويب أو تشغيل تطبيق الويب أو تشغيل تطبيق الجوال الهجين .
لذا لاستيعاب هذه المواقف، فإن
معالجة الطلبات عبر الأصل هي طريقة تسمح لنا بالوصول إلى هذه الموارد.
لذلك نعتبر الطلب طلبًا عبر أصل
إذا كنت تحاول الوصول إلى مورد من نطاق مختلف،
أو عند رقم منفذ مختلف، أو باستخدام بروتوكول مختلف.
إذن كيف نستوعب المواقف التي يكون فيها هذا وصولاً شرعيًا إلى مورد،
ولكن بسبب سياسة المصدر نفسه،
سيرفض متصفحك تحميل هذا المورد؟
الآن هذا هو المكان، كما ذكرت،
العديد من المتصفحات تقييد طلبات http عبر الأصل،
وخاصة تلك التي يتم بدأها من قبل XMLHttpRequest أو
بروتوكول Fetch لجلب البيانات.
هذه هي ذات الصلة عندما نصل إلى هذه من داخل شفرة جافا سكريبت لدينا.
لذلك، في هذه الظروف، من المنطقي فرض سياسة المصدر نفسه،
ولكن بعد ذلك ينبغي أن يكون لدينا وسيلة للتعامل
مع الوضع حيث يمكن إصدار طلب مشروع.
هذا هو المكان الذي
يأتي فيه نهج CORS، نهج تقاسم الموارد عبر الأصل، لمساعدتنا.
لذلك هذا CORS هو آلية تمكن خوادم الويب من تنفيذ
طلبات عبر النطاقات، أو طلبات عبر الأصل.
حتى هنا المتصفح والخادم
من حيث كنت تحاول إصلاح المورد سوف تتفاعل مع بعضها البعض ومن
ثم التوصل إلى اتفاق يقول أن هذا الوصول مقبول ويسمح.
لذلك بمجرد التوصل إلى الاتفاق،
يمكن السماح بهذا الطلب من قبل متصفحك.
وبالتالي فإن المتصفح والخادم سوف تتفاعل مع بعضها البعض من أجل
تحديد ما إذا كان هذا الوصول إلى هذا المورد هو موقف مقبول.
لذلك هذا هو المكان الذي تم فيه
إدخال مجموعة جديدة من رؤوس HTTP في رسائل رد HTTP القادمة من جانب الخادم.
تسمح هذه الرؤوس للخوادم بوصف مجموعة الأصول
المسموح بها من قبل الخادم للوصول إليها بواسطة المستعرض.
وبدوره يدرك المتصفح أن وصول هذه الموارد
مقبول، على الرغم من أنها تنتهك
سياسة المصدر نفسه التي رأيناها سابقًا.
لذلك في هذه الحالة، لدينا رؤوس مثل، على سبيل المثال،
Access-Control-Allow-Origin،
Access-Control-Allow-Headers، Access-Control-Allow-Methods،
وعدد قليل من الآخرين التي يستخدمها الخادم لإبلاغ المتصفح، قائلا إن
هذه طريقة مقبولة للوصول إلى المورد من جانب المتصفح.
وعندما يرى المتصفح رسالة الرد الواردة هذه من جانب الخادم،
يقبل المتصفح ويسمح بتنفيذ هذا الطلب عبر الأصل.
الآن، هذا يعني أيضًا أنه يجب إعداد الخادم ليكون قادرًا على
الاستجابة مع حقول الرأس هذه
ومعلومات الرأس المضمنة في رسالة الرد القادمة من جانب الخادم.
الآن، هذا هو المكان الذي نقسم فيه جميع الطلبات عبر الأصل إلى
عدة فئات.
لدينا أول واحد هو طلب بسيط عبر الموقع.
في طلبات بسيطة عبر المواقع، قد تستخدم إما GET أو
POST مع نص الطلب.
ولكن عندما تستخدم POST، يجب أن يحتوي نص الطلب على
تطبيق/X-WW-urlencoded،
أو بيانات متعددة الأجزاء/النموذج، أو نص/عادي.
ثم يتم التعامل معها كطلب بسيط عبر المواقع
ولن يسمح بأي رؤوس مخصصة في هذه الحالة.
لذلك في هذه الحالة، من المقبول أن يقوم الخادم بإبلاغ العميل،
قائلا إن هذا مسموح به ويجب أن يسمح المتصفح بمثل هذه الطلبات.
لذلك، على سبيل المثال، بالنسبة للموارد التي يمكن الوصول إليها على نطاق واسع، على سبيل المثال،
إذا قمت بإجراء طلب GET إلى خادم من أجل جلب البيانات من أجل
إنشاء واجهة المستخدم، فربما يكون طلب GET مقبولًا
بغض النظر عن الأصل الذي ينشأ منه الطلب.
لذا في هذه الحالة، سيرد الخادم الخاص بك على العميل،
قائلا Access-Conrol-Allow-Origin، مع نجم أحرف البدل هذا هنا،
مما يعني أن أي أصل ينشأ الطلب مقبول،
ويجب أن يسمح المتصفح بتنفيذ الطلب إلى هذا الخادم.
والآن، يمكنك أيضًا تقييد الوصول إلى الأصل.
في هذه الحالة، يمكنك أن تقول على وجه التحديد أنه إذا كان الأصل هو
موقع معين، فمن المقبول لخدمة هذا الطلب.
لذلك يرى المتصفح أن إرسال الطلبات
مع هذا الموقع الأصلي معين في الطلب مقبول
وسنسمح بطلب عبر الأصل.
حتى تتمكن من التحكم في الطريقة التي يتم بها
تحديد الأصل في رسالة الطلب القادمة من جانب العميل.
وبالتالي فإن الخادم قادر على قبول مثل هذه الطلبات. و
ستدرج طلبات أخرى معينة في فئة الطلبات السابقة.
في الطلب التجريبي، تتوقع أنه قبل أن
يرسل العميل الطلب الفعلي، سيقوم العميل بإرسال طلب اختبار مبدئي،
مما يعني أنه يتصل بالخادم للحصول على
معلومات من الخادم قبل إصدار الطلب الفعلي.
هذه هي الحالة التي تقوم فيها بإصدار طلبات PUT و DELETE
لأن طلبات PUT و DELETE قد تتسبب في تغييرات على جانب الخادم.
وبالتالي فإن أي طريقة تسبب آثارًا جانبية على بيانات الخادم، مثل PUT
وطلب DELETE، يتم تكليفها خصيصًا باتباع نهج الاختبار المبدئي.
في نهج الاختبار المبدئي، فإن الفكرة هي أن العميل سيقوم
أولاً بإرسال طلب HTTP OPTIONS إلى جانب الخادم،
وردًا على رسالة طلب OPTIONS من جانب العميل،
سيستجيب الخادم مع Access-Control-Allow-Headers المقابلة،
Access-Control-Allow-Origin،
ومعلومات رأس Access-Control-Allow-Cedentis في الرد على رسالة OPTI
بعد ذلك، سيقرر العميل ما إذا كان يمكنه إصدار طلب عبر الأصل أم
لا بناءً على الاستجابة لطلب الاختبار المبدئي OPTIONS الذي أرسله العميل.
لذلك هذا هو المكان الذي يجب أن تذهب من خلال خطوتين قبل
أن يسمح طلبك وخدمته من جانب الخادم.
الفئة الثالثة من طلبات CORS هي ما يسمى الطلبات المعتمدة،
حيث تتوقع من العميل تضمين بيانات الاعتماد
في رأس رسالة الطلب.
لذا فإن الطلبات المصحوبة بملفات تعريف الارتباط، على سبيل المثال،
للتعرف على الجلسة على جانب الخادم، أو نوع من
معلومات مصادقة HTTP في رأس التفويض في رسالة الطلب.
لذلك في هذه الحالة، يحتاج الخادم إلى الاستجابة باستخدام
Access-Control-Allow-Credences: true إلى جانب العميل.
لذلك في هذه الحالة، سوف يستجيب الخادم مع هذا ومن
ثم سيتم السماح للعميل بإرسال
معلومات بيانات الاعتماد الخاصة بهم في الطلب الوارد من جانب العميل.
الآن، في هذه الحالة، لا يُسمح لـ Access-Control-Allow-Origin
بالحصول على البطاقة البرية، النجم، في رسالة الرد.
ومن المتوقع أن يحدد بوضوح المصدر
الذي يمكن البدء في الطلب من أجله.
الآن، من الواضح، يمكننا تنفيذ الكثير من العمل،
ما نحتاج إلى القيام به على جانب الخادم، من خلال تنفيذ البرامج الوسيطة الخاصة بنا إذا
اخترنا ذلك للتعامل مع الردود المتعلقة بـ CORS من جانب الخادم.
انها واضحة جدا، كما رأينا في التعليمات البرمجية التي قمنا بتنفيذها.
بالطبع، هذه طريقة واحدة للتعامل مع الردود ذات الصلة بـ
Cors من جانب الخادم، ولكن لحسن الحظ، لدينا NodeModule محددة
تم تصميمها للتعامل مع هذا النوع من
العمل الذي يحتاج الخادم إلى القيام به لتلبية متطلبات CORS.
لذا فإن CORS NodeModule يسمح لنا بتكوين CORS على جانب الخادم،
بما في ذلك تحديد معلومات الأصل حيث سيتم قبول بيانات الاعتماد
والعديد من المعلومات الأخرى بحيث يمكنك تكوين الخادم
لتكون قادرة على التعامل مع الردود ذات الصلة CORS التي يحتاج إلى إعطائها
إلى المتصفح استجابة لرسالة الطلب.
لتثبيت CORS NodeModule، من الواضح أنك ترى npm تثبيت cors،
ثم قم بتكوين البرامج الوسيطة CORS داخل التطبيق السريع الخاص بك.
توفر وحدة CORS نفسها طريقة بسيطة للغاية لتمكين CORS.
يمكنك ببساطة تضمين استخدام التطبيق CORS مع أقواس فارغة، وهذا
يعني بشكل أساسي أنك تفتح الخادم الخاص بك، وسترد باستخدام
Access-Control-Allow-Origin مع نجمة البطاقة البرية لكل طلب وارد.
ولكن عندما تقوم بتكوين الخادم الخاص بك، قد تحتاج إلى مزيد من التحكم في
ذلك، بحيث يمكننا تحديد خيارات إضافية لـ CORS.
وليس ذلك فقط، يمكنك فرض CORS التعامل
بشكل مختلف للطرق المختلفة داخل جانب الخادم الخاص بك.
لذلك كما سنرى في التمرين، سنفرض متطلبات CORS مختلفة على
المسارات المختلفة على جانب الخادم الخاص بنا، ويتم تكوين كل هذا باستخدام
خيارات التكوين المختلفة التي تدعمها CORS NodeModule بالنسبة لنا.
لذلك، باستخدام CORS NodeModule، من السهل جدًا إعداد الخادم الخاص بك للتعامل
مع أي طلبات عبر الأصل القادمة من جانب العميل ثم الاستجابة بمعلومات الرأس المناسبة إلى جانب العميل
باستخدام رؤوس CORS المناسبة في رسالة الرد من جانب الخادم.
مع هذا الفهم السريع لـ CORS،
أنا متأكد من أن لديك أسئلة أكثر في هذه المرحلة من الإجابات من هذه المحاضرة.
ولكن إذا كنت ترغب في قراءة المزيد من التفاصيل حول CORS،
فقد قدمت لك موارد إضافية في نهاية هذا الدرس،
والتي تمكنك من قراءة المزيد عن CORS نفسها.
ولكن من منظور هذه الدورة، نود تكوين
تطبيقنا الصريح الذي قمنا بتطويره حتى
الآن للتعامل مع المسائل المتعلقة بـ CORS على جانب الخادم.
لذا ننتقل إلى التمرين، سنقوم بتثبيت وحدة CORS npm
ثم تكوينه على طرق مختلفة داخل خادمنا الإضافي.
[ موسيقى]