1
00:00:03,650 --> 00:00:06,795
الآن بعد أن أكملنا تنفيذ

2
00:00:06,795 --> 00:00:11,395
خادم REST API باستخدام Express و MongoDB في هذه الدورة،

3
00:00:11,395 --> 00:00:14,990
فإن التفكير الفوري التالي الذي قد يحدث في عقلك هو،

4
00:00:14,990 --> 00:00:20,490
نظرًا لأننا قمنا بالفعل بتطوير تطبيقات العميل في الدورات السابقة،

5
00:00:20,490 --> 00:00:24,930
كيف يمكننا دمج الاثنين معًا بحيث يكون قادر على

6
00:00:24,930 --> 00:00:30,880
التفاعل مع خادم REST API الكامل الذي قمنا بتطويره في هذه الدورة؟

7
00:00:30,880 --> 00:00:33,820
إذن، هذا ما سندرسه في

8
00:00:33,820 --> 00:00:39,820
هذه المحاضرة والممارسين اللذين يتابعان هذه المحاضرة.

9
00:00:39,820 --> 00:00:41,770
لذلك، في نهاية هذا الدرس،

10
00:00:41,770 --> 00:00:44,390
سيكون لديك React Client التي ستكون

11
00:00:44,390 --> 00:00:47,330
قادرة على التواصل مع الخادم الذي قمت بتطويره للتو في

12
00:00:47,330 --> 00:00:50,345
هذه الدورة وتكون قادرة

13
00:00:50,345 --> 00:00:56,510
على دعم عرض جانب العميل الكامل للتطبيق بأكمله.

14
00:00:56,510 --> 00:00:58,970
وبهذه الطريقة سوف نرى أننا قد وضعت

15
00:00:58,970 --> 00:01:02,565
نهاية كاملة إلى نهاية

16
00:01:02,565 --> 00:01:07,795
التطبيق من جانب العميل على طول الطريق إلى جانب الخادم في هذه الدورة.

17
00:01:07,795 --> 00:01:10,910
لدمج العميل والخادم،

18
00:01:10,910 --> 00:01:13,670
كما أدركنا أن خادمنا تم

19
00:01:13,670 --> 00:01:17,525
تنفيذه بالفعل لدعم واجهة برمجة تطبيقات REST كاملة.

20
00:01:17,525 --> 00:01:19,220
من جانب العميل،

21
00:01:19,220 --> 00:01:20,720
سواء كان العميل الزاوي أو العميل

22
00:01:20,720 --> 00:01:23,340
الأيوني أو عميل البرنامج النصي الأصلي،

23
00:01:23,340 --> 00:01:28,240
فإنها تتفاعل جميعها مع الخادم باستخدام نقاط النهاية REST API.

24
00:01:28,240 --> 00:01:33,630
لذلك، عندما يرسل العميل الطلب إلى الخادم عند نقطة نهاية REST API،

25
00:01:33,630 --> 00:01:38,190
سيستجيب الخادم مع بيانات JSON المقابلة مرة أخرى إلى العميل.

26
00:01:38,190 --> 00:01:44,225
يمكن للعميل بعد ذلك الاستفادة من بيانات JSON لعرض طرق العرض للمستخدم.

27
00:01:44,225 --> 00:01:50,450
لذلك، بالنظر إلى هذا الفهم للتواصل بين العميل والخادم،

28
00:01:50,450 --> 00:01:53,745
يجب أن يكون التكامل واضحًا إلى حد ما.

29
00:01:53,745 --> 00:01:58,475
الآن بعد أن حصلنا على مصادقة المستخدم المضمنة في جانب الخادم الخاص بنا،

30
00:01:58,475 --> 00:02:03,330
نحتاج إلى تحديث تطبيقات العميل الخاصة بنا

31
00:02:03,330 --> 00:02:08,400
لتمكينهم من إجراء مصادقة المستخدم على جانب الخادم

32
00:02:08,400 --> 00:02:12,200
عن طريق نشر معلومات تسجيل الدخول إلى الخادم ثم

33
00:02:12,200 --> 00:02:16,010
الحصول على رمز المصادقة من

34
00:02:16,010 --> 00:02:19,120
جانب الخادم وبعد ذلك التواصل مع الخادم

35
00:02:19,120 --> 00:02:23,700
بما في ذلك رمز المصادقة في رأس رسائل الطلب.

36
00:02:23,700 --> 00:02:27,050
لذلك، كل هذا يعني أننا بحاجة إلى إجراء تعديلات طفيفة

37
00:02:27,050 --> 00:02:31,345
على كل من العميل والخادم بحيث يمكن للاثنين التواصل مع بعضها البعض.

38
00:02:31,345 --> 00:02:36,530
أحد الجوانب التي لم أتعامل معها في التمرين سابقًا

39
00:02:36,530 --> 00:02:41,970
هو كيفية تعامل الخادم مع معلمات الاستعلام التي تأتي من جانب العميل.

40
00:02:41,970 --> 00:02:43,480
لذلك، كما أدركنا،

41
00:02:43,480 --> 00:02:47,450
عندما يرسل جانب العميل طلبًا للحصول

42
00:02:47,450 --> 00:02:53,035
على طبق مميز أو قائد مميز أو عرض ترويجي مميز،

43
00:02:53,035 --> 00:02:55,910
رأينا أن عنوان URL يتضمن،

44
00:02:55,910 --> 00:02:59,590
ميزة علامة استفهام الأطباق تساوي

45
00:02:59,590 --> 00:03:04,370
الصواب في عنوان URL للطلب الذي يأتي من جانب العميل.

46
00:03:04,370 --> 00:03:07,210
الآن، في البيانات على جانب الخادم،

47
00:03:07,210 --> 00:03:09,585
رأينا بالفعل أن الطبق

48
00:03:09,585 --> 00:03:15,370
أو الترويج أو القائد يتضمن العلم المميز بالفعل في بيانات JSON.

49
00:03:15,370 --> 00:03:18,649
لذلك، عندما يأتي هذا الطلب إلى جانب الخادم،

50
00:03:18,649 --> 00:03:21,394
فيجب أن يكون الخادم قادرًا على استخراج

51
00:03:21,394 --> 00:03:26,765
معلمة الاستعلام هذه من الطلب الوارد ثم

52
00:03:26,765 --> 00:03:32,390
القيام بشكل مناسب باستعلام

53
00:03:32,390 --> 00:03:39,950
MongoDB ثم الحصول على النتائج فقط حيث يتم تعيين هذه العلامة المميزة إلى true.

54
00:03:39,950 --> 00:03:41,740
لذلك، للقيام بذلك كما رأينا،

55
00:03:41,740 --> 00:03:47,075
عنوان URL الذي يتم استخدامه لإرسال الطلب إلى الخادم هو،

56
00:03:47,075 --> 00:03:52,030
علامة استفهام أطباق مائلة مميزة تساوي true.

57
00:03:52,030 --> 00:03:57,905
لذا، هذه هي الطريقة التي سنقوم بتزويد معلمات الاستعلام إلى جانب الخادم الخاص بنا.

58
00:03:57,905 --> 00:04:02,610
الآن بالإضافة إلى ذلك، عندما يتم تلقي هذه المعلومات على جانب الخادم،

59
00:04:02,610 --> 00:04:07,430
والآن رأينا أنه في وقت سابق عندما فعلنا طلب الحصول على جانب الخادم،

60
00:04:07,430 --> 00:04:10,190
قلنا ببساطة الأطباق تجد وبعد ذلك سوف نجد

61
00:04:10,190 --> 00:04:13,135
جميع الأطباق ومن ثم إعادتها عندما

62
00:04:13,135 --> 00:04:19,745
يتم إرسال طلب الحصول إلى طبق جهاز التوجيه الخط المائل .

63
00:04:19,745 --> 00:04:25,185
وينطبق نفس المنطق على كل من جهاز التوجيه الترويجي وكذلك على جهاز التوجيه الزعيم.

64
00:04:25,185 --> 00:04:30,339
الآن، عندما تقوم بتضمين معلمة استعلام مثل ذلك في عنوان URL،

65
00:04:30,339 --> 00:04:34,695
كيف سيتمكن جانب الخادم من استخراج معلمة الاستعلام هذه؟

66
00:04:34,695 --> 00:04:35,980
لذلك، هذا هو المكان،

67
00:04:35,980 --> 00:04:42,590
عندما يحتوي الطلب الوارد على معلمة الاستعلام هذه المرفقة بعنوان URL الوارد،

68
00:04:42,590 --> 00:04:47,375
سيقوم الخادم السريع بمعالجة ذلك تلقائيًا وتحويله إلى

69
00:04:47,375 --> 00:04:54,445
كائن JSON يتم تحميله على رسالة طلب قادمة على جانب الخادم.

70
00:04:54,445 --> 00:05:00,710
الآن، هذا متاح على جانب الخادم في شكل req.query.

71
00:05:00,710 --> 00:05:06,545
لذا، سيتم تحويل معلمات الاستعلام التي تضمينها في عنوان URL إلى

72
00:05:06,545 --> 00:05:11,480
كائنات JSON المقابلة مع مجموعة المعلومات كما

73
00:05:11,480 --> 00:05:16,880
هو موضح هنا ثم تحميلها على كائن الطلب على جانب الخادم.

74
00:05:16,880 --> 00:05:19,940
لذلك، باستخدام req.query على جانب الخادم،

75
00:05:19,940 --> 00:05:23,625
سنكون قادرين على الحصول على معلمات الاستعلام هذه.

76
00:05:23,625 --> 00:05:27,935
لذلك، عند إجراء طلب الحصول على جانب الخادم تقول

77
00:05:27,935 --> 00:05:34,115
dishes.find ثم تقوم بتضمين req.query في البحث هناك.

78
00:05:34,115 --> 00:05:38,960
وبالتالي، عندما يتم

79
00:05:38,960 --> 00:05:44,120
الاستعلام عن MongoDB ثم

80
00:05:44,120 --> 00:05:50,390
سيتم استخراج تلك السجلات فقط أو تلك الوثائق التي تم تعيين المميز لها إلى true من MongoDB وتوفيرها مرة أخرى

81
00:05:50,390 --> 00:05:57,020
لنا داخل هذه الطريقة الحصول هنا ومن ثم يمكن إرجاعها إلى جانب العميل.

82
00:05:57,020 --> 00:06:05,270
لذا، هذا بسيط مثل ذلك في التعامل مع معلمات الاستعلام على جانب الخادم الخاص بنا.

83
00:06:05,270 --> 00:06:10,645
لذلك، هذا التحديث سوف نفعل لكل من جهاز التوجيه طبق، جهاز

84
00:06:10,645 --> 00:06:16,880
التوجيه الترويجي، وجهاز التوجيه زعيم على جانب الخادم لدينا.

85
00:06:16,880 --> 00:06:18,430
الجزء التالي هو،

86
00:06:18,430 --> 00:06:20,545
بالطبع، مصادقة المستخدم.

87
00:06:20,545 --> 00:06:22,060
لذلك، كما أدركنا،

88
00:06:22,060 --> 00:06:24,150
على جانب الخادم لدينا بالفعل

89
00:06:24,150 --> 00:06:29,450
نقاط نهاية واجهة برمجة تطبيقات REST التي هي مفيدة لمصادقة المستخدم،

90
00:06:29,450 --> 00:06:33,260
ولا سيما عند إجراء مشاركة لشرطة

91
00:06:33,260 --> 00:06:37,100
مائلة للمستخدمين تسجيل الدخول باستخدام اسم المستخدم وكلمة المرور،

92
00:06:37,100 --> 00:06:41,675
ثم سوف تكون قادرة على مصادقة المستخدم على الخادم الجانب.

93
00:06:41,675 --> 00:06:46,080
الآن، عندما تتم مصادقة المستخدم على جانب الخادم بنجاح،

94
00:06:46,080 --> 00:06:50,584
فستتضمن رسالة الرد القادمة من جانب الخادم رمز

95
00:06:50,584 --> 00:06:58,880
JSON Web Token في نص الرد الخاص برسالة الرد الواردة من جانب الخادم.

96
00:06:58,880 --> 00:07:00,350
لذلك، على جانب العميل،

97
00:07:00,350 --> 00:07:04,700
يجب أن نكون قادرين على استخراج هذا الرمز المميز ثم استخدام هذا الرمز المميز في وقت لاحق.

98
00:07:04,700 --> 00:07:08,210
لذلك، عندما يتلقى العميل رسالة الرد من

99
00:07:08,210 --> 00:07:12,560
جانب الخادم ويتم مصادقة المستخدم بنجاح على جانب الخادم،

100
00:07:12,560 --> 00:07:15,220
ستحتوي رسالة الرد على رمز JSON Web Token،

101
00:07:15,220 --> 00:07:16,950
الذي يجب استخراجه،

102
00:07:16,950 --> 00:07:20,780
وبعد ذلك يجب على العميل تضمين JSON Web Token هذا

103
00:07:20,780 --> 00:07:26,200
في لكل طلب صادر من جانب العميل.

104
00:07:26,200 --> 00:07:31,205
يتم تحقيق ذلك عن طريق حفظ رمز JSON Web Token إلى التخزين المحلي.

105
00:07:31,205 --> 00:07:35,155
بعد ذلك، لكل طلبات جلب نصدرها،

106
00:07:35,155 --> 00:07:40,365
يمكننا إعداد رأس التفويض لاحتواء رمز JSON Web Token.

107
00:07:40,365 --> 00:07:43,815
الآن، عملية الخروج واضحة إلى حد ما،

108
00:07:43,815 --> 00:07:47,865
إذا قمنا بتدمير رمز JSON Web Token الذي لدينا على جانب

109
00:07:47,865 --> 00:07:51,210
العميل، فلن يتمكن العميل من الوصول إلى الخادم.

110
00:07:51,210 --> 00:07:53,930
لذا، فهي بسيطة مثل تدمير رمز

111
00:07:53,930 --> 00:07:58,180
JSON Web Token على جانب العميل لتسجيل الخروج من هذا العميل.

112
00:07:58,180 --> 00:08:00,530
لذلك، وبالنظر إلى هذا الفهم،

113
00:08:00,530 --> 00:08:04,175
دعونا نرى الخطوات التي تشارك في

114
00:08:04,175 --> 00:08:09,840
القيام مصادقة المستخدم على التعامل مع مصادقة المستخدم على جانب العميل.

115
00:08:09,840 --> 00:08:13,085
لذا، للتعامل مع مصادقة المستخدم على جانب العميل،

116
00:08:13,085 --> 00:08:19,000
سيقوم العميل بإرسال طلب نشر إلى نقطة نهاية تسجيل الدخول إلى شرطة مائلة للمستخدمين،

117
00:08:19,000 --> 00:08:24,190
وسيحتوي نص طلب المشاركة على اسم المستخدم وكلمة المرور.

118
00:08:24,190 --> 00:08:26,720
نحن نستخدم مصادقة تسجيل الدخول في هذه الحالة.

119
00:08:26,720 --> 00:08:28,695
الآن، لمصادقة Facebook، مرة أخرى

120
00:08:28,695 --> 00:08:32,425
، هذا إعداد مختلف لن أناقشه الآن.

121
00:08:32,425 --> 00:08:35,570
ولكن نص الطلب كما ترى

122
00:08:35,570 --> 00:08:38,780
للمصادقة المحلية سيحتوي على اسم المستخدم وكلمة المرور.

123
00:08:38,780 --> 00:08:43,220
لذلك، عندما تتم مصادقة المستخدم بنجاح على جانب الخادم،

124
00:08:43,220 --> 00:08:46,460
سيقوم الخادم بالرد مرة أخرى

125
00:08:46,460 --> 00:08:51,490
على العميل من خلال تضمين رمز ويب JSON في رسالة الرد.

126
00:08:51,490 --> 00:08:56,150
لذلك، عندما يتلقى العميل رسالة الرد من جانب الخادم،

127
00:08:56,150 --> 00:09:00,320
فسيتعين على العميل التقاط رمز ويب JSON هذا ثم

128
00:09:00,320 --> 00:09:05,080
حفظ JSON Web Token في التخزين المحلي على جانب العميل.

129
00:09:05,080 --> 00:09:11,300
بعد ذلك، يجب على العميل تضمين هذا الرمز المميز في كل طلب صادر.

130
00:09:11,300 --> 00:09:14,495
إذن، كيف يتم إنجاز ذلك على جانب العميل؟

131
00:09:14,495 --> 00:09:20,285
أولا وقبل كل شيء، نحن بحاجة إلى حفظ JSON Web Token في التخزين المحلي.

132
00:09:20,285 --> 00:09:25,670
الآن، يتم إنجاز ذلك داخل منشئ الإجراءات الذي يتعامل مع عملية تسجيل دخول المستخدم.

133
00:09:25,670 --> 00:09:32,685
لذلك، عندما يتم النشر إلى الخادم من منشئ الحث من جانب العميل،

134
00:09:32,685 --> 00:09:36,020
فإن رسالة الرد سوف تحتوي على الرمز المميز،

135
00:09:36,020 --> 00:09:41,540
ويتم حفظ هذا الرمز المميز في منشئ الإجراءات الذي يعالج عملية تسجيل دخول المستخدم.

136
00:09:41,540 --> 00:09:45,875
الآن بعد ذلك، عندما يتم أي طلب جلب،

137
00:09:45,875 --> 00:09:52,829
ثم يمكننا بسهولة تعيين رأس التفويض في طلب الجلب الصادر.

138
00:09:52,829 --> 00:09:56,005
الآن، بمجرد أن يقوم العميل بتسجيل الخروج،

139
00:09:56,005 --> 00:09:59,930
سيتم تدمير رمز JSON Web Token على جانب العميل.

140
00:09:59,930 --> 00:10:03,050
لذلك بعد ذلك، لن تحتوي الطلبات الصادرة على رمز

141
00:10:03,050 --> 00:10:07,490
JSON Web Token بعد الآن لأن JSON Web Token غير موجود على جانب العميل.

142
00:10:07,490 --> 00:10:10,790
وبالتالي، يفقد المستخدم المصادقة.

143
00:10:10,790 --> 00:10:17,455
لذا، هذه هي الطريقة التي سنتعامل بها مع تسجيل الدخول وعملية الخروج على جانب العميل.

144
00:10:17,455 --> 00:10:21,890
من خلال التواصل مع الخادم ثم الحصول على رمز ويب JSON

145
00:10:21,890 --> 00:10:26,185
ثم تضمين رمز ويب JSON في كل طلب صادر.

146
00:10:26,185 --> 00:10:31,570
الآن، مع هذا الفهم لكيفية تفاعل العميل والخادم،

147
00:10:31,570 --> 00:10:35,540
دعونا ننتقل الآن إلى التدريبين التاليين.

148
00:10:35,540 --> 00:10:40,410
أولا، سنقوم بتحديث جانب الخادم مع بعض الإضافات بحيث

149
00:10:40,410 --> 00:10:45,550
يمكن أن تتكامل بشكل جيد مع جانب العميل لدينا.

150
00:10:45,550 --> 00:10:50,075
بعد ذلك، سنقوم بتحديث جانب العميل أو بالأحرى سأعطيك

151
00:10:50,075 --> 00:10:54,200
تطبيق عميل كامل الذي أخذته

152
00:10:54,200 --> 00:10:58,875
من قوة رد الفعل السابقة وتكييفه، وتحديثه.

153
00:10:58,875 --> 00:11:03,080
لذلك، سوف نتعامل مع كل من هذه في التدريبين المقبلين،

154
00:11:03,080 --> 00:11:09,460
وفي نهاية ذلك سوف نفهم كيفية دمج العميل والخادم الخاص بك.