1
00:00:00,000 --> 00:00:10,326
[MUSIC]

2
00:00:10,326 --> 00:00:17,750
يسمح خادم Express REST API الذي قمنا بتنفيذه في الوحدة السابقة لأي مستخدم بإجراء أي من عمليات GET أو POST أو DELETE.

3
00:00:17,750 --> 00:00:21,360
لا توجد سيطرة على من يمكنه تنفيذ هذه العملية.

4
00:00:21,360 --> 00:00:22,350
مما يعني أنه

5
00:00:22,350 --> 00:00:27,180
إذا قمت بتشغيل خادم كهذا، فيمكن لأي شخص الدخول إلى خادمك

6
00:00:27,180 --> 00:00:33,420
والبدء في معالجة المعلومات الموجودة داخل قاعدة البيانات الخاصة بك.

7
00:00:33,420 --> 00:00:36,578
ومن الواضح أن هذا وضع خطير.

8
00:00:36,578 --> 00:00:40,380
الطريقة التي يجب أن يتم بها تنفيذ هذا الخادم هي أنه

9
00:00:40,380 --> 00:00:44,330
يجب أن يكون لديك نوع من القيود على

10
00:00:44,330 --> 00:00:48,660
أنواع المستخدمين التي سيتم السماح لها بتنفيذ أي أنواع من العمليات.

11
00:00:48,660 --> 00:00:51,090
لذلك ربما، سوف تسمح

12
00:00:51,090 --> 00:00:54,650
للمستخدم المصرح به فقط لتنفيذ عمليات GET.

13
00:00:54,650 --> 00:01:00,040
على سبيل المثال، إذا كنت تريد أن يكون الضيف قادرا على رؤية معلومات

14
00:01:00,040 --> 00:01:04,860
حول الأطباق في مطعمك أو قائمة مطعمك

15
00:01:04,860 --> 00:01:07,250
وهلم جرا، وهذا أمر مقبول تماما.

16
00:01:07,250 --> 00:01:11,699
ولكن، قد تسمح لمسؤول فقط للذهاب في

17
00:01:11,699 --> 00:01:17,780
وتعديل المعلومات حول الطبق أو لحذف طبق من القائمة.

18
00:01:17,780 --> 00:01:23,448
وقم أيضًا بتحديث طبق موجود في القائمة، أو عرض ترويجي،

19
00:01:23,448 --> 00:01:29,062
أو معلومات حول القادة في جانب الخادم.

20
00:01:29,062 --> 00:01:34,810
الآن، هل يمكن أيضا أن يكون مجموعة أخرى من المستخدمين الذين سيتم تسجيلهم المستخدمين

21
00:01:34,810 --> 00:01:39,980
الذين قد يسمح لهم لحفظ بعض من الأطباق الخاصة بهم كما الأطباق المفضلة لديهم،

22
00:01:39,980 --> 00:01:44,290
وفقط أنها سوف تكون قادرة على التعامل مع قائمة من الأطباق المفضلة لديهم.

23
00:01:44,290 --> 00:01:47,850
لذلك هذا هو مستوى آخر من التفويض أو

24
00:01:47,850 --> 00:01:49,940
المصادقة التي تحتاج إلى تنفيذها.

25
00:01:49,940 --> 00:01:53,400
لذلك، لديك درجات مختلفة من المستخدمين،

26
00:01:53,400 --> 00:01:57,820
وأيضا، اعتمادا على أي نوع من العمليات سوف يسمح لهم لأداء.

27
00:01:57,820 --> 00:02:01,880
لذلك كل هذا يعني أنك تحتاج إلى نوع من الأمان ليتم تضمينه

28
00:02:01,880 --> 00:02:03,840
في جانب الخادم الخاص بك.

29
00:02:03,840 --> 00:02:07,970
سننظر في كيفية مصادقة المستخدمين،

30
00:02:07,970 --> 00:02:13,110
ثم نقرر نوع المستخدم هذا العميل.

31
00:02:13,110 --> 00:02:15,410
ثم اعتمادا على نوع المستخدم،

32
00:02:15,410 --> 00:02:19,360
يمكنك السماح للمستخدم لتنفيذ أنواع معينة من العمليات.

33
00:02:19,360 --> 00:02:24,630
سنبدأ بالفهم الأساسي لهذا، ما نسميه

34
00:02:24,630 --> 00:02:30,860
المصادقة الأساسية في جانب الخادم

35
00:02:30,860 --> 00:02:36,940
للعميل، ثم نبني على ذلك طوال بقية هذه الوحدة.

36
00:02:36,940 --> 00:02:42,030
ثم في نهاية هذه الوحدة، سوف ينتهي بنا الأمر بآلية

37
00:02:42,030 --> 00:02:46,170
، مما يسمح للمستخدمين بتسجيل أنفسهم.

38
00:02:46,170 --> 00:02:50,220
ويمكن للمستخدمين المسجلين تنفيذ عمليات معينة

39
00:02:50,220 --> 00:02:53,930
لا يمكن للمستخدم غير المسجل، وهلم جرا.

40
00:02:53,930 --> 00:02:57,320
لذلك سنقوم بفرض أنواع مختلفة من ضوابط الوصول

41
00:02:57,320 --> 00:03:01,990
لمختلف العمليات على جانب الخادم استنادًا إلى نوع المستخدم.

42
00:03:01,990 --> 00:03:04,930
بحيث يحدد لك المنظور، أو

43
00:03:04,930 --> 00:03:09,830
بالأحرى فكرة ما سوف تواجهها في هذه الوحدة.

44
00:03:09,830 --> 00:03:12,450
دعونا نبدأ بالمصادقة الأساسية،

45
00:03:12,450 --> 00:03:18,450
الآلية الأساسية للغاية التي ستمكننا من مصادقة المستخدمين.

46
00:03:19,970 --> 00:03:25,173
المصادقة الأساسية في HTTP هي آلية بسيطة للغاية،

47
00:03:25,173 --> 00:03:28,782
والتي ستطلب من المستخدم

48
00:03:28,782 --> 00:03:32,720
تقديم اسم مستخدم وكلمة مرور مع طلب.

49
00:03:32,720 --> 00:03:35,180
وهناك بنية محددة

50
00:03:35,180 --> 00:03:39,920
حول كيفية إرسال هذه المعلومات من العميل إلى جانب الخادم.

51
00:03:39,920 --> 00:03:45,060
لذلك، هذه مسألة، مصادقة الوصول الأساسية، التي يدعمها HTTP،

52
00:03:45,060 --> 00:03:49,860
هي مسألة من شأنها تمكين الخادم من تحدي العميل، وطلب

53
00:03:49,860 --> 00:03:53,110
اسم المستخدم وكلمة المرور ليتم تقديمها من قبل العميل.

54
00:03:53,110 --> 00:03:57,714
لذلك يمكن للخادم تحدي العميل لمصادقة نفسه عن طريق كتابة هذه

55
00:03:57,714 --> 00:03:59,140
المعلومات.

56
00:03:59,140 --> 00:04:01,880
يحتاج العميل إلى إرسال اسم المستخدم

57
00:04:01,880 --> 00:04:05,440
وكلمة المرور استجابة للتحدي من جانب الخادم.

58
00:04:05,440 --> 00:04:09,870
لذلك،

59
00:04:09,870 --> 00:04:13,870
يجب أن تتضمن كل رسالة طلب تنشأ من عميل النموذج المشفر لاسم المستخدم وكلمة

60
00:04:13,870 --> 00:04:19,700
المرور في رأس الطلب الذي ينتقل من العميل إلى جانب الخادم.

61
00:04:19,700 --> 00:04:22,229
لذلك عندما يتلقى الخادم الطلب،

62
00:04:22,229 --> 00:04:27,009
سيقوم الخادم باستخراج هذه المعلومات من رأس طلب العميل.

63
00:04:27,009 --> 00:04:31,831
ثم استخدم ذلك لمصادقة العميل قبل

64
00:04:31,831 --> 00:04:37,390
السماح بالوصول إلى العمليات المختلفة على جانب الخادم.

65
00:04:37,390 --> 00:04:40,850
إذن، كيف تعمل هذه المصادقة؟

66
00:04:40,850 --> 00:04:44,450
إذا أرسل العميل طلبًا إلى الخادم،

67
00:04:44,450 --> 00:04:50,150
ولم يتضمن طلب العميل هذا تكوين التفويض،

68
00:04:50,150 --> 00:04:55,160
فسيقوم الخادم بتحدي العميل، ويطلب من العميل إرسال هذه المعلومات.

69
00:04:55,160 --> 00:04:58,100
يتحدى الخادم العميل من خلال

70
00:04:58,100 --> 00:05:01,900
تضمين رأس في رسالة الرد القادمة.

71
00:05:01,900 --> 00:05:06,410
الرأس مع النوع كما وو-المصادقة،

72
00:05:06,410 --> 00:05:11,843
ثم الجزء الثاني حيث يحدد النوع هو المكان الذي

73
00:05:11,843 --> 00:05:17,500
سيحدد فيه نوع المصادقة التي يحتاج العميل إلى إرسالها.

74
00:05:17,500 --> 00:05:21,990
وسنبدأ بفهم المصادقة الأساسية هنا.

75
00:05:21,990 --> 00:05:26,400
ولاحظ أيضًا أن رسالة الرد ستحتوي على رمز خطأ 401،

76
00:05:27,570 --> 00:05:31,270
وهو غير مصرح به، والذي يمثل غير مصرح به.

77
00:05:31,270 --> 00:05:35,470
لذلك عندما يعود الرد من جانب الخادم، فإن العميل،

78
00:05:35,470 --> 00:05:41,300
ردًا على هذا الرد، سيتعين على العميل إرسال طلبه،

79
00:05:41,300 --> 00:05:49,550
بما في ذلك حقل رأس محدد في رسالة الطلب الخاصة بتفويض النوع.

80
00:05:49,550 --> 00:05:55,250
وسيحتوي حقل رأس التفويض هذا على بعض المعلومات هناك.

81
00:05:55,250 --> 00:06:00,440
للحصول على مصادقة أساسية, هذه المعلومات ستكون في شكل,

82
00:06:00,440 --> 00:06:03,900
كالكلمة الأولى هنا, ستكون الأساسية.

83
00:06:03,900 --> 00:06:11,410
ثم تليها مساحة هنا، تليها سلسلة مشفرة Base64 هنا. تقوم

84
00:06:11,410 --> 00:06:15,358
هذه السلسلة المشفرة Base64 بترميز اسم المستخدم

85
00:06:15,358 --> 00:06:21,350
وكلمة المرور بتنسيق معين، ثم تتضمن ذلك في الرأس.

86
00:06:21,350 --> 00:06:25,479
الآن أنت تقول، إذا أرسلت رسالة طلب مثل هذه،

87
00:06:25,479 --> 00:06:29,397
بما في ذلك هذا، في الرأس، ثم أي شخص في المنتصف.

88
00:06:29,397 --> 00:06:33,538
لذا إذا كنت تعرف أي شيء عن الأمن

89
00:06:33,538 --> 00:06:39,927
وكيف يمكن إطلاق الرجل في الهجمات الوسطى، فمن الواضح

90
00:06:39,927 --> 00:06:44,777
أن هذا يمكن استرجاعه من قبل متسلل بين،

91
00:06:44,777 --> 00:06:49,590
ومن ثم يمكن استخدامه لتزييف العميل الحقيقي.

92
00:06:49,590 --> 00:06:52,720
و مرة أخرى, لن ندخل في هذا السؤال في الوقت الراهن.

93
00:06:52,720 --> 00:06:57,470
عندما أتحدث عن HTTPS في الوحدة التالية،

94
00:06:57,470 --> 00:07:00,880
سأعود لمعالجة هذه المشكلة بمزيد من التفصيل.

95
00:07:00,880 --> 00:07:06,060
ولكن في الوقت الحالي، سيتم إرسال المعلومات الموجودة في الرأس

96
00:07:07,880 --> 00:07:11,930
دون أن يتم تشفيرها في الرأس في هذه اللحظة.

97
00:07:11,930 --> 00:07:15,460
الآن، أحد الأسباب الأخرى التي تجعلني أفعل ذلك هو أنه، حتى نتمكن من النظر

98
00:07:15,460 --> 00:07:20,150
في العنوان مباشرة ثم نرى هذه المعلومات في الرأس نفسه.

99
00:07:20,150 --> 00:07:25,401
لذلك، عندما يرسل العميل هذا الطلب، سيقوم الخادم باستخراج

100
00:07:25,401 --> 00:07:30,930
المعلومات من رأس التفويض هذا في رأس الطلب.

101
00:07:30,930 --> 00:07:35,078
ثم استخدم هذه المعلومات للتحقق مما إذا كان هذا

102
00:07:35,078 --> 00:07:37,670
طلب عميل مصرح به أم لا.

103
00:07:37,670 --> 00:07:40,412
الآن بالطبع سيكون سؤالك التالي،

104
00:07:40,412 --> 00:07:44,490
ما الذي يحتوي عليه رأس التفويض هذا بالضبط؟

105
00:07:44,490 --> 00:07:48,350
يتم إنشاء رأس التخويل نفسه كما يلي.

106
00:07:48,350 --> 00:07:52,180
إذا كان لديك اسم مستخدم وكلمة مرور، فهذه هي

107
00:07:52,180 --> 00:07:55,730
قطعتي المعلومات التي ستستخدمهما لمصادقة عميل.

108
00:07:55,730 --> 00:08:01,330
لذلك سيتم تسلسل اسم المستخدم وكلمة المرور في سلسلة واحدة

109
00:08:01,330 --> 00:08:06,910
عن طريق قول اسم المستخدم ونقطتين، وكلمة المرور نفسها.

110
00:08:06,910 --> 00:08:09,860
لذلك

111
00:08:09,860 --> 00:08:16,210
سيتم تجميع سلسلة اسم المستخدم والنقطتين وكلمة المرور معًا في سلسلة كاملة هنا.

112
00:08:16,210 --> 00:08:22,994
هذه السلسلة الناتجة التي نحصل عليها هنا هي، المشفرة باستخدام ترميز Base64.

113
00:08:22,994 --> 00:08:27,344
إذا كنت تعرف كيف يتم الترميز أساسيات الترميز،

114
00:08:27,344 --> 00:08:32,390
قم بتحويل ذلك إلى رأس ASCII كما هو موضح في هذا المثال هنا،

115
00:08:32,390 --> 00:08:36,195
لذلك هذا ليس سوى سلسلة من رؤوس ASCII.

116
00:08:36,195 --> 00:08:39,545
الآن إذا كنت لا تعرف الكثير عن الترميز الأساسي القاسي، فلا تقلق بشأن ذلك،

117
00:08:39,545 --> 00:08:44,325
فإنه لا يؤثر على فهمك لما يحدث هنا على أي حال.

118
00:08:44,325 --> 00:08:47,090
لذلك هذه السلاسل المشفرة Basic64، لذلك

119
00:08:47,090 --> 00:08:51,950
يتم ترميز هذه المعلومات الخاصة في سلسلة مثل هذه،

120
00:08:51,950 --> 00:08:57,090
ثم يتم تضمينها في رأس الطلب الانتقال من العميل إلى الخادم.

121
00:08:57,090 --> 00:09:02,143
رأس الطلب نفسه هو من تفويض النوع،

122
00:09:02,143 --> 00:09:07,194
ثم يتبعه القيمة الفعلية هنا، والتي تقول،

123
00:09:07,194 --> 00:09:13,774
Basic، ومساحة هنا، وسلسلة Base64 المشفرة هنا.

124
00:09:13,774 --> 00:09:20,034
لذلك، عندما يتم استلام هذا من قبل قطع لدينا، سيقوم الخادم باستخراج هذه المعلومات،

125
00:09:20,034 --> 00:09:25,059
ومن ثم من هنا، فإنه سيتم استخراج اسم المستخدم وكلمة المرور،

126
00:09:25,059 --> 00:09:31,620
ومن ثم التحقق مما إذا كان ذلك يطابق مستخدم معتمد أم لا على جانب الخادم.

127
00:09:31,620 --> 00:09:36,917
لمساعدتك على فهم أفضل لكيفية تنظيم التطبيق السريع بالفعل

128
00:09:36,917 --> 00:09:42,211
وكيفية تنفيذ المصادقة نفسها، كما تعلمنا في وقت سابق،

129
00:09:42,211 --> 00:09:47,520
يتم تنظيم التطبيقات السريعة نفسها في مجموعة من البرامج الوسيطة.

130
00:09:47,520 --> 00:09:51,690
والطريقة التي يعمل بها التطبيق السريع هي أن

131
00:09:51,690 --> 00:09:55,630
يتم تطبيق الوسيطة على الطلب ورسالة الاستجابة

132
00:09:55,630 --> 00:10:00,940
بالترتيب الذي تم الإعلان عنه في طلبي السريع.

133
00:10:00,940 --> 00:10:05,290
حتى إذا كان لديك express.use

134
00:10:05,290 --> 00:10:09,740
ثم لديك أول واحد يقول خادم ثابت، ثم بعد ذلك،

135
00:10:09,740 --> 00:10:13,220
لديك وسيط آخر، ثم بعد ذلك، لديك وسيط آخر.

136
00:10:13,220 --> 00:10:18,560
التسلسل الذي يتم الإعلان عنه في ملف app.js الخوادم السريعة

137
00:10:18,560 --> 00:10:23,600
، على سبيل المثال، هو التسلسل الدقيق الذي سيتم تطبيق الوسيطة.

138
00:10:23,600 --> 00:10:29,124
لذلك طلب وارد من جانب الخادم كما تتذكر في

139
00:10:29,124 --> 00:10:34,690
التطبيق السريع الخاص بك، يتم التعامل مع الطلب الوارد ككائن طلب.

140
00:10:34,690 --> 00:10:39,050
كائن الاستجابة هو ما يبني الخادم السريع، ومن

141
00:10:39,050 --> 00:10:43,310
ثم يسمح لك التالي بالانتقال إلى الوسيطة التالية

142
00:10:43,310 --> 00:10:45,910
التي ستقوم بتطبيقها، وهكذا.

143
00:10:45,910 --> 00:10:52,400
لذلك، طلب وارد مثل هذا، عندما يتعلق الأمر، يتم تطبيق الوسيطة الأولى.

144
00:10:52,400 --> 00:10:56,164
وبعد ذلك بمجرد أن تقوم هذه البرامج الوسيطة بتحويل كل

145
00:10:56,164 --> 00:11:00,680
من الطلب والاستجابة، فإنها تنتقل إلى الوسيطة التالية، والتي يتم تطبيقها عليها بعد ذلك.

146
00:11:00,680 --> 00:11:03,940
على سبيل المثال، رأينا أننا طبقنا مورغان أولا،

147
00:11:03,940 --> 00:11:06,930
ثم طبقنا محلل الجسم على الوسيطة.

148
00:11:06,930 --> 00:11:12,930
لذلك يجب أن تكون قد حولت بالفعل الطلب وكائنات الاستجابة.

149
00:11:12,930 --> 00:11:17,440
ثم بعد ذلك، يمكننا تضمين الوسيطة المصادقة في مكان هناك.

150
00:11:17,440 --> 00:11:22,260
ستقوم الوسيطة المصادقة بمصادقة الطلب.

151
00:11:22,260 --> 00:11:26,950
الآن، لذلك إذا كنت تستخدم المصادقة الأساسية، هل

152
00:11:26,950 --> 00:11:31,970
يجب أن يحتوي طلبك في رأس رأس التفويض الموجود هناك.

153
00:11:31,970 --> 00:11:36,260
لذلك سيتم استخراج رأس التفويض بواسطة الوسيطة المصادقة

154
00:11:36,260 --> 00:11:40,180
ثم التحقق لمعرفة ما إذا كان المستخدم مأذونا به.

155
00:11:40,180 --> 00:11:46,099
وإذا اكتشفت برامج المصادقة الوسيطة أنك مستخدم معتمد،

156
00:11:46,099 --> 00:11:50,515
فسيسمح لك بالمضي قدمًا إلى المجموعة التالية من البرامج

157
00:11:50,515 --> 00:11:54,427
الوسيطة التي تتبع خطوة المصادقة.

158
00:11:54,427 --> 00:11:58,510
وسيتم معالجة السجلات الخاصة بك من قبل الوسيطة اللاحقة.

159
00:11:58,510 --> 00:11:59,519
ولكن من ناحية أخرى،

160
00:11:59,519 --> 00:12:04,422
إذا قررت البرامج الوسيطة للمصادقة أنك لست مستخدمًا

161
00:12:04,422 --> 00:12:09,197
مرخصًا، فستأخذك برامج المصادقة الوسيطة على طول مسار مختلف.

162
00:12:09,197 --> 00:12:13,975
ثم قم بإنشاء خطأ، ثم قم بإرسال

163
00:12:13,975 --> 00:12:19,368
رد خطأ مناسب إلى جانب العميل هذا

164
00:12:19,368 --> 00:12:24,010
وسيتم إعادة توجيهه إلى معالج الأخطاء.

165
00:12:24,010 --> 00:12:28,450
لذلك سيتم إجراء إعادة التوجيه هذه إلى معالج الأخطاء عن طريق استدعاء Next

166
00:12:28,450 --> 00:12:32,490
مع الخطأ كمعلمة لذلك التالي هنا.

167
00:12:32,490 --> 00:12:38,240
لذا فإن التالي هو بالضبط هذا التالي الذي نراه في مورد الطلب التالي هنا.

168
00:12:38,240 --> 00:12:42,760
وهكذا، وهذا سوف يأخذك على طول الطريق وصولا إلى معالج الخطأ،

169
00:12:42,760 --> 00:12:48,170
والتي سوف تتعامل مع الخطأ ومن ثم إرسال رسالة الخطأ مرة أخرى إلى جانب العميل،

170
00:12:48,170 --> 00:12:51,820
مشيرا إلى فشل المصادقة.

171
00:12:51,820 --> 00:12:56,720
إذن هذه هي الطريقة التي

172
00:12:56,720 --> 00:13:03,435
يعمل بها التفويض الأساسي النموذجي، أو المصادقة الأساسية في التطبيق من جانب الخادم.

173
00:13:03,435 --> 00:13:08,305
بعد فهم هذا، دعونا ننتقل إلى التمرين حيث

174
00:13:08,305 --> 00:13:13,176
سنقوم بتنفيذ المصادقة الأساسية في تطبيقنا

175
00:13:13,176 --> 00:13:15,717
ونرى كيف يصادق المستخدمين.

176
00:13:15,717 --> 00:13:17,952
[ موسيقى]