1
00:00:00,000 --> 00:00:04,746
[موسيقى]

2
00:00:04,746 --> 00:00:08,050
دعونا نتحدث في بعض لغة كورس الآن.

3
00:00:08,050 --> 00:00:11,500
الآن ما هو بالضبط تبادل النتائج عبر الأصل،

4
00:00:11,500 --> 00:00:15,325
ولماذا هو ذات الصلة عندما ننظر إلى تطبيقات الويب

5
00:00:15,325 --> 00:00:21,010
والتطبيقات فائقة المحمول كما كنا نفعل في هذا التخصص؟

6
00:00:21,010 --> 00:00:25,260
كما تفهم، فإن معظم صفحات الويب تسحب الآن البيانات من

7
00:00:25,260 --> 00:00:29,790
العديد من المواقع المختلفة من أجل إنشاء صفحة ويب.

8
00:00:29,790 --> 00:00:38,470
الآن، من أجل فرض سياسة صارمة للوصول إلى الموارد من مواقع مختلفة،

9
00:00:38,470 --> 00:00:44,220
تم فرض نفس سياسة الأصل من قبل العديد من المتصفحات.

10
00:00:44,220 --> 00:00:49,410
سنتحدث قليلاً عن ذلك بمزيد من التفصيل في الشرائح القليلة القادمة، ولكن في

11
00:00:49,410 --> 00:00:55,950
سياق الأطر التي كنا نناقشها في هذا

12
00:00:55,950 --> 00:01:00,640
التخصص الخاص، مثل Angular و Ionic و NativeScript،

13
00:01:00,640 --> 00:01:05,650
فإن العديد من هذه تتضمن نصوص برمجية، شفرة جافا سكريبت،

14
00:01:05,650 --> 00:01:11,220
التي قد تضطر إلى الوصول إلى الموارد من مواقع مختلفة.

15
00:01:11,220 --> 00:01:16,790
وهذا هو المكان الذي تزرع فيه مشكلة CORS بسهولة كبيرة.

16
00:01:16,790 --> 00:01:22,290
دعونا نرى كيف سنتناول هذه المسألة بمزيد من التفصيل في هذه المحاضرة

17
00:01:22,290 --> 00:01:24,050
والممارسة التالية.

18
00:01:25,940 --> 00:01:31,446
ألمحت بإيجاز إلى سياسة الأصل نفسه التي بدأت هذه المحاضرة.

19
00:01:31,446 --> 00:01:36,510
الآن، سياسة المصدر نفسه هي نموذج أمان تطبيق ويب

20
00:01:36,510 --> 00:01:40,170
يقيد كيفية

21
00:01:40,170 --> 00:01:45,380
تفاعل مستند أو برنامج نصي تم تحميله من أصل واحد مع الموارد من أصل آخر.

22
00:01:45,380 --> 00:01:50,270
والغرض من ذلك هو عزل الوثائق التي يحتمل أن تكون ضارة.

23
00:01:50,270 --> 00:01:54,940
من الواضح الآن أنه عندما يكون لديك صفحة ويب تتضمن نصًا برمجيًا

24
00:01:54,940 --> 00:02:00,900
، شفرة جافا سكريبت، والتي قد تصل إلى الموارد من موقع آخر،

25
00:02:00,900 --> 00:02:05,185
يمكن حقن الشفرة الضارة في صفحة الويب الخاصة بك

26
00:02:05,185 --> 00:02:12,800
، حيث الوصول إلى أصل مختلف عن المكان الذي يتم فيه الحصول على صفحة الويب الخاصة بك.

27
00:02:12,800 --> 00:02:17,220
الآن، هذا هو السبب في أن العديد من المتصفحات تفرض سياسة المصدر نفسه.

28
00:02:17,220 --> 00:02:22,230
الآن، عندما نتحدث عن نفس الأصل، كيف نحدد أصل؟

29
00:02:22,230 --> 00:02:28,540
الآن في هذا السياق، يتم تعريف أصل لأي مورد من خلال ثلاث مجموعات.

30
00:02:28,540 --> 00:02:32,980
أولاً، البروتوكول المستخدم للوصول إلى المورد.

31
00:02:32,980 --> 00:02:39,410
ثانياً، اسم المضيف للمورد أو مجال هذا المورد.

32
00:02:39,410 --> 00:02:43,480
وثالثا، رقم المنفذ الذي يتم فيه الوصول إلى هذا المورد.

33
00:02:43,480 --> 00:02:48,700
إذن هذه هي الطريقة التي نحدد بها أصل أي مورد.

34
00:02:48,700 --> 00:02:53,626
يمكن أن يكون المورد في هذه الحالة صفحة html، وصورة،

35
00:02:53,626 --> 00:03:00,720
وبيانات JSON التي يتم الحصول عليها من نقطة نهاية REST API، وغيرها الكثير.

36
00:03:00,720 --> 00:03:05,410
لمزيد من التفاصيل حول سياسة المصدر نفسه، دعونا ننظر إلى مثال.

37
00:03:05,410 --> 00:03:12,315
لنفترض أن لدينا صفحة ويب يتم تحميلها من هذا الموقع المدرج هنا،

38
00:03:12,315 --> 00:03:17,330
www.abc.com، وفي مجلد xyz،

39
00:03:17,330 --> 00:03:21,210
ويتم تحميل page.html هنا.

40
00:03:21,210 --> 00:03:26,890
قد تتضمن هذه الصفحة روابط أو حتى شفرة جافا سكريبت التي قد

41
00:03:26,890 --> 00:03:33,200
تصدر XMLHttpRequest إلى موارد أخرى على صفحة الويب.

42
00:03:33,200 --> 00:03:38,310
الآن، في هذه الحالة، إذا حاولنا الوصول إلى عنوان URL آخر

43
00:03:38,310 --> 00:03:42,690
، على سبيل المثال، أول عنوان مدرج هنا، والذي من الواضح أنك تراه

44
00:03:42,690 --> 00:03:47,860
من نفس الموقع ولكن من مجلد مختلف.

45
00:03:47,860 --> 00:03:51,820
هذا مقبول، لأن الأصل، في هذه الحالة،

46
00:03:51,820 --> 00:03:55,420
البروتوكول المستخدم ورقم المنفذ، لا يزال هو نفسه.

47
00:03:55,420 --> 00:04:00,660
لذلك، هذا مقبول للوصول إلى هذا المورد.

48
00:04:00,660 --> 00:04:05,470
وبالمثل في الحالة الثانية، قد يكون لدينا تحت

49
00:04:07,040 --> 00:04:10,570
عدة مستويات من المجلدات الفرعية مورد يتم الوصول إليه.

50
00:04:10,570 --> 00:04:15,850
ولكن مرة أخرى، لأن أصلهم لا يزال هو نفسه، وهو أمر مقبول.

51
00:04:15,850 --> 00:04:18,260
ولكن دعونا ننظر إلى المثال الثالث هنا.

52
00:04:18,260 --> 00:04:23,930
في هذا المثال، نرى أننا نحاول الوصول إلى مورد هنا باستخدام

53
00:04:23,930 --> 00:04:31,230
بروتوكول https، والذي ينتهك بوضوح الأصل نفسه

54
00:04:31,230 --> 00:04:35,580
لأننا نستخدم بروتوكول مختلف للوصول إلى هذا المورد في هذه المرحلة.

55
00:04:35,580 --> 00:04:39,030
بحيث يعتبر ذلك فشلاً في هذه الحالة.

56
00:04:39,030 --> 00:04:44,840
الحالة الرابعة هي المكان الذي نصل فيه إلى مورد برقم منفذ مختلف.

57
00:04:44,840 --> 00:04:50,300
والحالة الخامسة هي حيث نصل إلى مورد في مضيف مختلف.

58
00:04:50,300 --> 00:04:54,830
الآن، سيتم وضع علامة على كل هذه الثلاثة على أنها غير صالحة أو

59
00:04:54,830 --> 00:04:58,110
لا يمكن الوصول إليها بموجب سياسة المصدر نفسه.

60
00:04:58,110 --> 00:05:02,710
لذلك إذا فرضت سياسة المصدر نفسه للوصول من، على سبيل المثال،

61
00:05:02,710 --> 00:05:10,970
XMLHttpRequest الخاص بك، فلن يُسمح بالثلاثة الأخيرة في هذه الحالة.

62
00:05:10,970 --> 00:05:16,270
ولكن بالطبع، هناك العديد من الحالات التي

63
00:05:16,270 --> 00:05:22,510
قد يستضيف فيها مصمم الموقع بالفعل موارد على مواقع مختلفة، ربما على نطاقات مختلفة،

64
00:05:22,510 --> 00:05:27,128
ولا يزال قادرًا على سحب البيانات من أجل إنشاء صفحة

65
00:05:27,128 --> 00:05:32,120
الويب أو تشغيل تطبيق الويب أو تشغيل تطبيق الجوال الهجين .

66
00:05:32,120 --> 00:05:38,914
لذا لاستيعاب هذه المواقف، فإن

67
00:05:38,914 --> 00:05:44,798
معالجة الطلبات عبر الأصل هي طريقة تسمح لنا بالوصول إلى هذه الموارد.

68
00:05:44,798 --> 00:05:50,410
لذلك نعتبر الطلب طلبًا عبر أصل

69
00:05:50,410 --> 00:05:56,290
إذا كنت تحاول الوصول إلى مورد من نطاق مختلف،

70
00:05:56,290 --> 00:06:01,240
أو عند رقم منفذ مختلف، أو باستخدام بروتوكول مختلف.

71
00:06:01,240 --> 00:06:06,920
إذن كيف نستوعب المواقف التي يكون فيها هذا وصولاً شرعيًا إلى مورد،

72
00:06:06,920 --> 00:06:08,800
ولكن بسبب سياسة المصدر نفسه،

73
00:06:08,800 --> 00:06:12,930
سيرفض متصفحك تحميل هذا المورد؟

74
00:06:12,930 --> 00:06:15,790
الآن هذا هو المكان، كما ذكرت،

75
00:06:15,790 --> 00:06:20,220
العديد من المتصفحات تقييد طلبات http عبر الأصل،

76
00:06:20,220 --> 00:06:26,420
وخاصة تلك التي يتم بدأها من قبل XMLHttpRequest أو

77
00:06:26,420 --> 00:06:30,570
بروتوكول Fetch لجلب البيانات.

78
00:06:30,570 --> 00:06:36,980
هذه هي ذات الصلة عندما نصل إلى هذه من داخل شفرة جافا سكريبت لدينا.

79
00:06:36,980 --> 00:06:41,950
لذلك، في هذه الظروف، من المنطقي فرض سياسة المصدر نفسه،

80
00:06:41,950 --> 00:06:46,490
ولكن بعد ذلك ينبغي أن يكون لدينا وسيلة للتعامل

81
00:06:46,490 --> 00:06:49,980
مع الوضع حيث يمكن إصدار طلب مشروع.

82
00:06:49,980 --> 00:06:52,184
هذا هو المكان الذي

83
00:06:52,184 --> 00:06:56,960
يأتي فيه نهج CORS، نهج تقاسم الموارد عبر الأصل، لمساعدتنا.

84
00:06:56,960 --> 00:07:02,021
لذلك هذا CORS هو آلية تمكن خوادم الويب من تنفيذ

85
00:07:02,021 --> 00:07:06,741
طلبات عبر النطاقات، أو طلبات عبر الأصل.

86
00:07:06,741 --> 00:07:10,400
حتى هنا المتصفح والخادم

87
00:07:10,400 --> 00:07:14,375
من حيث كنت تحاول إصلاح المورد سوف تتفاعل مع بعضها البعض ومن

88
00:07:14,375 --> 00:07:20,945
ثم التوصل إلى اتفاق يقول أن هذا الوصول مقبول ويسمح.

89
00:07:20,945 --> 00:07:23,575
لذلك بمجرد التوصل إلى الاتفاق،

90
00:07:23,575 --> 00:07:29,182
يمكن السماح بهذا الطلب من قبل متصفحك.

91
00:07:29,182 --> 00:07:32,912
وبالتالي فإن المتصفح والخادم سوف تتفاعل مع بعضها البعض من أجل

92
00:07:32,912 --> 00:07:38,252
تحديد ما إذا كان هذا الوصول إلى هذا المورد هو موقف مقبول.

93
00:07:38,252 --> 00:07:43,672
لذلك هذا هو المكان الذي تم فيه

94
00:07:43,672 --> 00:07:49,010
إدخال مجموعة جديدة من رؤوس HTTP في رسائل رد HTTP القادمة من جانب الخادم.

95
00:07:49,010 --> 00:07:54,580
تسمح هذه الرؤوس للخوادم بوصف مجموعة الأصول

96
00:07:54,580 --> 00:08:01,690
المسموح بها من قبل الخادم للوصول إليها بواسطة المستعرض.

97
00:08:01,690 --> 00:08:06,760
وبدوره يدرك المتصفح أن وصول هذه الموارد

98
00:08:06,760 --> 00:08:11,405
مقبول، على الرغم من أنها تنتهك

99
00:08:11,405 --> 00:08:16,230
سياسة المصدر نفسه التي رأيناها سابقًا.

100
00:08:16,230 --> 00:08:19,876
لذلك في هذه الحالة، لدينا رؤوس مثل، على سبيل المثال،

101
00:08:19,876 --> 00:08:24,821
Access-Control-Allow-Origin،

102
00:08:24,821 --> 00:08:29,780
Access-Control-Allow-Headers، Access-Control-Allow-Methods،

103
00:08:29,780 --> 00:08:35,330
وعدد قليل من الآخرين التي يستخدمها الخادم لإبلاغ المتصفح، قائلا إن

104
00:08:35,330 --> 00:08:41,190
هذه طريقة مقبولة للوصول إلى المورد من جانب المتصفح.

105
00:08:41,190 --> 00:08:46,970
وعندما يرى المتصفح رسالة الرد الواردة هذه من جانب الخادم،

106
00:08:46,970 --> 00:08:52,510
يقبل المتصفح ويسمح بتنفيذ هذا الطلب عبر الأصل.

107
00:08:52,510 --> 00:08:56,500
الآن، هذا يعني أيضًا أنه يجب إعداد الخادم ليكون قادرًا على

108
00:08:56,500 --> 00:09:01,230
الاستجابة مع حقول الرأس هذه

109
00:09:01,230 --> 00:09:06,800
ومعلومات الرأس المضمنة في رسالة الرد القادمة من جانب الخادم.

110
00:09:06,800 --> 00:09:11,424
الآن، هذا هو المكان الذي نقسم فيه جميع الطلبات عبر الأصل إلى

111
00:09:11,424 --> 00:09:13,260
عدة فئات.

112
00:09:13,260 --> 00:09:18,495
لدينا أول واحد هو طلب بسيط عبر الموقع.

113
00:09:18,495 --> 00:09:22,780
في طلبات بسيطة عبر المواقع، قد تستخدم إما GET أو

114
00:09:22,780 --> 00:09:25,410
POST مع نص الطلب.

115
00:09:25,410 --> 00:09:30,180
ولكن عندما تستخدم POST، يجب أن يحتوي نص الطلب على

116
00:09:30,180 --> 00:09:34,688
تطبيق/X-WW-urlencoded،

117
00:09:34,688 --> 00:09:39,305
أو بيانات متعددة الأجزاء/النموذج، أو نص/عادي.

118
00:09:39,305 --> 00:09:44,805
ثم يتم التعامل معها كطلب بسيط عبر المواقع

119
00:09:44,805 --> 00:09:47,625
ولن يسمح بأي رؤوس مخصصة في هذه الحالة.

120
00:09:47,625 --> 00:09:52,955
لذلك في هذه الحالة، من المقبول أن يقوم الخادم بإبلاغ العميل،

121
00:09:52,955 --> 00:09:57,520
قائلا إن هذا مسموح به ويجب أن يسمح المتصفح بمثل هذه الطلبات.

122
00:09:57,520 --> 00:10:01,700
لذلك، على سبيل المثال، بالنسبة للموارد التي يمكن الوصول إليها على نطاق واسع، على سبيل المثال،

123
00:10:01,700 --> 00:10:05,830
إذا قمت بإجراء طلب GET إلى خادم من أجل جلب البيانات من أجل

124
00:10:05,830 --> 00:10:10,580
إنشاء واجهة المستخدم، فربما يكون طلب GET مقبولًا

125
00:10:10,580 --> 00:10:14,400
بغض النظر عن الأصل الذي ينشأ منه الطلب.

126
00:10:14,400 --> 00:10:17,350
لذا في هذه الحالة، سيرد الخادم الخاص بك على العميل،

127
00:10:17,350 --> 00:10:23,250
قائلا Access-Conrol-Allow-Origin، مع نجم أحرف البدل هذا هنا،

128
00:10:23,250 --> 00:10:27,830
مما يعني أن أي أصل ينشأ الطلب مقبول،

129
00:10:27,830 --> 00:10:33,540
ويجب أن يسمح المتصفح بتنفيذ الطلب إلى هذا الخادم.

130
00:10:33,540 --> 00:10:38,020
والآن، يمكنك أيضًا تقييد الوصول إلى الأصل.

131
00:10:38,020 --> 00:10:44,440
في هذه الحالة، يمكنك أن تقول على وجه التحديد أنه إذا كان الأصل هو

132
00:10:44,440 --> 00:10:50,090
موقع معين، فمن المقبول لخدمة هذا الطلب.

133
00:10:50,090 --> 00:10:55,940
لذلك يرى المتصفح أن إرسال الطلبات

134
00:10:55,940 --> 00:11:01,230
مع هذا الموقع الأصلي معين في الطلب مقبول

135
00:11:01,230 --> 00:11:03,830
وسنسمح بطلب عبر الأصل.

136
00:11:03,830 --> 00:11:08,790
حتى تتمكن من التحكم في الطريقة التي يتم بها

137
00:11:08,790 --> 00:11:12,870
تحديد الأصل في رسالة الطلب القادمة من جانب العميل.

138
00:11:12,870 --> 00:11:17,500
وبالتالي فإن الخادم قادر على قبول مثل هذه الطلبات. و

139
00:11:17,500 --> 00:11:23,094
ستدرج طلبات أخرى معينة في فئة الطلبات السابقة.

140
00:11:23,094 --> 00:11:27,750
في الطلب التجريبي، تتوقع أنه قبل أن

141
00:11:27,750 --> 00:11:32,380
يرسل العميل الطلب الفعلي، سيقوم العميل بإرسال طلب اختبار مبدئي،

142
00:11:32,380 --> 00:11:37,260
مما يعني أنه يتصل بالخادم للحصول على

143
00:11:37,260 --> 00:11:41,380
معلومات من الخادم قبل إصدار الطلب الفعلي.

144
00:11:41,380 --> 00:11:46,580
هذه هي الحالة التي تقوم فيها بإصدار طلبات PUT و DELETE

145
00:11:46,580 --> 00:11:52,160
لأن طلبات PUT و DELETE قد تتسبب في تغييرات على جانب الخادم.

146
00:11:52,160 --> 00:11:58,100
وبالتالي فإن أي طريقة تسبب آثارًا جانبية على بيانات الخادم، مثل PUT

147
00:11:58,100 --> 00:12:03,538
وطلب DELETE، يتم تكليفها خصيصًا باتباع نهج الاختبار المبدئي.

148
00:12:03,538 --> 00:12:08,276
في نهج الاختبار المبدئي، فإن الفكرة هي أن العميل سيقوم

149
00:12:08,276 --> 00:12:12,919
أولاً بإرسال طلب HTTP OPTIONS إلى جانب الخادم،

150
00:12:12,919 --> 00:12:19,174
وردًا على رسالة طلب OPTIONS من جانب العميل،

151
00:12:19,174 --> 00:12:24,864
سيستجيب الخادم مع Access-Control-Allow-Headers المقابلة،

152
00:12:24,864 --> 00:12:31,504
Access-Control-Allow-Origin،

153
00:12:31,504 --> 00:12:36,350
ومعلومات رأس Access-Control-Allow-Cedentis في الرد على رسالة OPTI

154
00:12:36,350 --> 00:12:42,359
بعد ذلك، سيقرر العميل ما إذا كان يمكنه إصدار طلب عبر الأصل أم

155
00:12:42,359 --> 00:12:48,870
لا بناءً على الاستجابة لطلب الاختبار المبدئي OPTIONS الذي أرسله العميل.

156
00:12:48,870 --> 00:12:53,410
لذلك هذا هو المكان الذي يجب أن تذهب من خلال خطوتين قبل

157
00:12:53,410 --> 00:12:57,205
أن يسمح طلبك وخدمته من جانب الخادم.

158
00:12:58,340 --> 00:13:03,230
الفئة الثالثة من طلبات CORS هي ما يسمى الطلبات المعتمدة،

159
00:13:03,230 --> 00:13:07,900
حيث تتوقع من العميل تضمين بيانات الاعتماد

160
00:13:07,900 --> 00:13:09,608
في رأس رسالة الطلب.

161
00:13:09,608 --> 00:13:13,518
لذا فإن الطلبات المصحوبة بملفات تعريف الارتباط، على سبيل المثال،

162
00:13:13,518 --> 00:13:19,040
للتعرف على الجلسة على جانب الخادم، أو نوع من

163
00:13:19,040 --> 00:13:24,440
معلومات مصادقة HTTP في رأس التفويض في رسالة الطلب.

164
00:13:24,440 --> 00:13:27,843
لذلك في هذه الحالة، يحتاج الخادم إلى الاستجابة باستخدام

165
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credences: true إلى جانب العميل.

166
00:13:32,460 --> 00:13:37,920
لذلك في هذه الحالة، سوف يستجيب الخادم مع هذا ومن

167
00:13:37,920 --> 00:13:41,070
ثم سيتم السماح للعميل بإرسال

168
00:13:41,070 --> 00:13:45,720
معلومات بيانات الاعتماد الخاصة بهم في الطلب الوارد من جانب العميل.

169
00:13:45,720 --> 00:13:50,430
الآن، في هذه الحالة، لا يُسمح لـ Access-Control-Allow-Origin

170
00:13:50,430 --> 00:13:56,550
بالحصول على البطاقة البرية، النجم، في رسالة الرد.

171
00:13:56,550 --> 00:14:00,770
ومن المتوقع أن يحدد بوضوح المصدر

172
00:14:00,770 --> 00:14:03,450
الذي يمكن البدء في الطلب من أجله.

173
00:14:04,500 --> 00:14:08,235
الآن، من الواضح، يمكننا تنفيذ الكثير من العمل،

174
00:14:08,235 --> 00:14:13,796
ما نحتاج إلى القيام به على جانب الخادم، من خلال تنفيذ البرامج الوسيطة الخاصة بنا إذا

175
00:14:13,796 --> 00:14:19,260
اخترنا ذلك للتعامل مع الردود المتعلقة بـ CORS من جانب الخادم.

176
00:14:19,260 --> 00:14:23,570
انها واضحة جدا، كما رأينا في التعليمات البرمجية التي قمنا بتنفيذها.

177
00:14:23,570 --> 00:14:29,140
بالطبع، هذه طريقة واحدة للتعامل مع الردود ذات الصلة بـ

178
00:14:29,140 --> 00:14:34,800
Cors من جانب الخادم، ولكن لحسن الحظ، لدينا NodeModule محددة

179
00:14:34,800 --> 00:14:40,470
تم تصميمها للتعامل مع هذا النوع من

180
00:14:40,470 --> 00:14:44,920
العمل الذي يحتاج الخادم إلى القيام به لتلبية متطلبات CORS.

181
00:14:44,920 --> 00:14:50,790
لذا فإن CORS NodeModule يسمح لنا بتكوين CORS على جانب الخادم،

182
00:14:50,790 --> 00:14:55,810
بما في ذلك تحديد معلومات الأصل حيث سيتم قبول بيانات الاعتماد

183
00:14:55,810 --> 00:15:01,010
والعديد من المعلومات الأخرى بحيث يمكنك تكوين الخادم

184
00:15:01,010 --> 00:15:05,630
لتكون قادرة على التعامل مع الردود ذات الصلة CORS التي يحتاج إلى إعطائها

185
00:15:05,630 --> 00:15:09,480
إلى المتصفح استجابة لرسالة الطلب.

186
00:15:09,480 --> 00:15:15,750
لتثبيت CORS NodeModule، من الواضح أنك ترى npm تثبيت cors،

187
00:15:15,750 --> 00:15:22,280
ثم قم بتكوين البرامج الوسيطة CORS داخل التطبيق السريع الخاص بك.

188
00:15:23,430 --> 00:15:28,940
توفر وحدة CORS نفسها طريقة بسيطة للغاية لتمكين CORS.

189
00:15:28,940 --> 00:15:35,970
يمكنك ببساطة تضمين استخدام التطبيق CORS مع أقواس فارغة، وهذا

190
00:15:35,970 --> 00:15:41,370
يعني بشكل أساسي أنك تفتح الخادم الخاص بك، وسترد باستخدام

191
00:15:41,370 --> 00:15:47,180
Access-Control-Allow-Origin مع نجمة البطاقة البرية لكل طلب وارد.

192
00:15:47,180 --> 00:15:51,940
ولكن عندما تقوم بتكوين الخادم الخاص بك، قد تحتاج إلى مزيد من التحكم في

193
00:15:51,940 --> 00:15:57,190
ذلك، بحيث يمكننا تحديد خيارات إضافية لـ CORS.

194
00:15:57,190 --> 00:16:02,790
وليس ذلك فقط، يمكنك فرض CORS التعامل

195
00:16:02,790 --> 00:16:06,810
بشكل مختلف للطرق المختلفة داخل جانب الخادم الخاص بك.

196
00:16:06,810 --> 00:16:12,320
لذلك كما سنرى في التمرين، سنفرض متطلبات CORS مختلفة على

197
00:16:12,320 --> 00:16:17,540
المسارات المختلفة على جانب الخادم الخاص بنا، ويتم تكوين كل هذا باستخدام

198
00:16:17,540 --> 00:16:22,690
خيارات التكوين المختلفة التي تدعمها CORS NodeModule بالنسبة لنا.

199
00:16:22,690 --> 00:16:34,020
لذلك، باستخدام CORS NodeModule، من السهل جدًا إعداد الخادم الخاص بك للتعامل

200
00:16:34,020 --> 00:16:39,730
مع أي طلبات عبر الأصل القادمة من جانب العميل ثم الاستجابة بمعلومات الرأس المناسبة إلى جانب العميل

201
00:16:39,730 --> 00:16:45,310
باستخدام رؤوس CORS المناسبة في رسالة الرد من جانب الخادم.

202
00:16:45,310 --> 00:16:48,450
مع هذا الفهم السريع لـ CORS،

203
00:16:48,450 --> 00:16:54,730
أنا متأكد من أن لديك أسئلة أكثر في هذه المرحلة من الإجابات من هذه المحاضرة.

204
00:16:54,730 --> 00:16:58,960
ولكن إذا كنت ترغب في قراءة المزيد من التفاصيل حول CORS،

205
00:16:58,960 --> 00:17:04,050
فقد قدمت لك موارد إضافية في نهاية هذا الدرس،

206
00:17:04,050 --> 00:17:06,804
والتي تمكنك من قراءة المزيد عن CORS نفسها.

207
00:17:06,804 --> 00:17:11,553
ولكن من منظور هذه الدورة، نود تكوين

208
00:17:11,553 --> 00:17:15,037
تطبيقنا الصريح الذي قمنا بتطويره حتى

209
00:17:15,037 --> 00:17:19,150
الآن للتعامل مع المسائل المتعلقة بـ CORS على جانب الخادم.

210
00:17:19,150 --> 00:17:24,941
لذا ننتقل إلى التمرين، سنقوم بتثبيت وحدة CORS npm

211
00:17:24,941 --> 00:17:30,236
ثم تكوينه على طرق مختلفة داخل خادمنا الإضافي.

212
00:17:30,236 --> 00:17:33,629
[ موسيقى]