1
00:00:00,000 --> 00:00:04,614
[MUSIC]

2
00:00:04,614 --> 00:00:09,792
لقد قمنا بالفعل بتطوير خادم REST API كامل باستخدام Express و

3
00:00:09,792 --> 00:00:12,026
MongoDB كجزء من هذه الدورة.

4
00:00:12,026 --> 00:00:16,881
لكي يتمكن الخادم من التواصل بشكل مفيد مع عملائنا،

5
00:00:16,881 --> 00:00:21,892
سنقوم بإجراء بعض التعديلات الطفيفة عليه بحيث يعيد النوع الصحيح من البيانات.

6
00:00:21,892 --> 00:00:26,063
بحيث يمكن تنفيذ العميل لدينا العمل بشكل أكثر كفاءة

7
00:00:26,063 --> 00:00:29,370
مع البيانات التي يتم إرجاعها من جانب الخادم.

8
00:00:29,370 --> 00:00:30,427
لذلك للقيام بذلك،

9
00:00:30,427 --> 00:00:35,724
دعونا نعمل على بعض التعديلات على جانب الخادم لدينا في هذا التمرين.

10
00:00:37,478 --> 00:00:43,220
الذهاب إلى خادمنا في المحرر، قبل أن نبدأ العمل على الخادم،

11
00:00:43,220 --> 00:00:48,497
أود أن أقترح عليك تحميل جميع الصور التي قدمتها

12
00:00:48,497 --> 00:00:53,260
كملف مضغوط في موارد التمرين تسمى images.zip.

13
00:00:53,260 --> 00:00:56,530
قم بفك ضغط الملف ثم الحصول على كافة الصور من هناك،

14
00:00:56,530 --> 00:01:03,440
ثم قم بنسخ تلك الصور إلى مجلد الصور العامة في الخادم الخاص بنا.

15
00:01:03,440 --> 00:01:08,980
لذلك ترى أن هنا قمت بنسخ جميع الصور في

16
00:01:08,980 --> 00:01:10,580
مجلد الصور العامة هنا بالفعل.

17
00:01:10,580 --> 00:01:15,120
لأن الخادم الخاص بنا هو الخادم الذي سيخدم كل هذه الصور

18
00:01:15,120 --> 00:01:17,460
لتطبيق العميل لدينا.

19
00:01:17,460 --> 00:01:22,820
بعد ذلك، نذهب إلى الكورس وضبط تلك القائمة البيضاء، هنا.

20
00:01:22,820 --> 00:01:27,919
لذلك بالنسبة لتطبيق العميل الزاوي الخاص بنا، إذا بدأنا تشغيله

21
00:01:27,919 --> 00:01:33,571
باستخدام أمر خدمة ng، فإنه يعمل في localhost:4200.

22
00:01:33,571 --> 00:01:36,196
لذلك فإن أي طلبات قادمة من

23
00:01:36,196 --> 00:01:40,750
تطبيق Angular الخاص بنا إلى الخادم ستحمل ذلك كأصلها هناك.

24
00:01:40,750 --> 00:01:44,710
لهذا السبب سأقوم بإضافة ذلك إلى قائمتي البيضاء،

25
00:01:44,710 --> 00:01:50,310
بحيث يتم معالجة أي مشاكل في الكورس تلقائيًا.

26
00:01:50,310 --> 00:01:54,848
حتى الذهاب إلى هذا الملف cors.js،

27
00:01:54,848 --> 00:01:59,698
في قائمتي البيضاء، هنا، اسمحوا لي أن أضيف

28
00:01:59,698 --> 00:02:08,371
في http://localhost:، 4200.

29
00:02:08,371 --> 00:02:12,503
وهذا هو الأصل الذي

30
00:02:12,503 --> 00:02:16,690
سينشأ منه كل عميل Angular الخاص بي الطلب الذي يأتي إلى هذا الخادم.

31
00:02:16,690 --> 00:02:22,020
وبهذه الطريقة، لن يسبب بلدي كورس مشاكل لعميل قد الزاوي.

32
00:02:22,020 --> 00:02:27,760
بعد ذلك، نحتاج إلى تحديث عدد قليل من المسارات للتعامل مع

33
00:02:27,760 --> 00:02:32,760
معلمات الاستعلام، وكذلك بعض التعديلات الأخرى الطفيفة.

34
00:02:32,760 --> 00:02:35,905
اسمحوا لي أن أبدأ مع ملفات promoRouter.js.

35
00:02:35,905 --> 00:02:39,760
لذلك هذا أمر بسيط للحصول على تحديث.

36
00:02:39,760 --> 00:02:44,790
حتى الذهاب إلى ملف promoRouter.js، في ملف برومورووتر، للحصول

37
00:02:44,790 --> 00:02:47,960
على طلب الحصول التي نحصل عليها هنا،

38
00:02:47,960 --> 00:02:52,400
بدلا من القيام الترقيات. البحث مع جافا سكريبت فارغة،

39
00:02:52,400 --> 00:02:57,256
وهنا أود أن توريد req.query

40
00:02:57,256 --> 00:03:02,470
كمعلمة لتلك الترقيات.

41
00:03:02,470 --> 00:03:07,650
نفس الشيء مع LeaderRouter أيضا، لذلك اسمحوا لي أن أذهب إلى ملف leaderRouter.js.

42
00:03:07,650 --> 00:03:09,786
وفي LeaderRouter أيضا،

43
00:03:09,786 --> 00:03:14,642
هنا حيث تجد Leaders.Find مع كائن جافا سكريبت فارغ.

44
00:03:14,642 --> 00:03:18,423
بدلاً من ذلك، استبدل ذلك بـ req.query،

45
00:03:18,423 --> 00:03:21,852
بحيث يتم تمرير معلمات الاستعلام.

46
00:03:21,852 --> 00:03:26,430
لذلك هذا هو المكان الذي سنمر فيه في العمود المميز

47
00:03:26,430 --> 00:03:29,487
كمعلمة الاستعلام.

48
00:03:29,487 --> 00:03:34,678
الآن بعد تعديل هذين، دعونا نعمل الآن على مسار الطبق،

49
00:03:34,678 --> 00:03:41,090
لذلك الذهاب إلى ملف dishRouter.js، حتى في DishRouter، نفس التحديث هنا.

50
00:03:41,090 --> 00:03:48,920
حتى الذهاب إلى هذه الأطباق. البحث في طريقة الحصول هنا، تغيير ذلك إلى req.query.

51
00:03:48,920 --> 00:03:52,987
لذلك مع هذا، تم الانتهاء من تحديث ديشروتر الخاص بي.

52
00:03:52,987 --> 00:03:57,664
لذلك قمنا الآن بتحديث بروموراوتر، ريدررووتر، و

53
00:03:57,664 --> 00:04:02,784
ديشروتر، ثم سننتقل إلى تحديث أن فافوريتريوتر.

54
00:04:02,784 --> 00:04:07,519
الآن كنت قد نفذت جهاز التوجيه المفضل كجزء من

55
00:04:07,519 --> 00:04:09,500
المهمة الرابعة الخاصة بك.

56
00:04:09,500 --> 00:04:12,306
الآن في FavoriterOuterOter، سترى أنه بالنسبة لـ

57
00:04:12,306 --> 00:04:16,618
FavoriterOter لا أريك الجزء المتبقي لأنه

58
00:04:16,618 --> 00:04:19,437
يجب عليك القيام به كجزء من مهمتك.

59
00:04:19,437 --> 00:04:22,925
اسمحوا لي أولا أن ألفت انتباهكم إلى طريقة الحصول على

60
00:04:22,925 --> 00:04:26,422
Favoriterouter.Route («/: Dishid').

61
00:04:26,422 --> 00:04:31,161
الآن، أنا ذاهب إلى استخدام هذه الطريقة الحصول فقط

62
00:04:31,161 --> 00:04:35,653
للتحقق للتأكد من أن طبق

63
00:04:35,653 --> 00:04:40,292
معين مع ديشيد هو بالفعل المفضلة للمستخدم.

64
00:04:40,292 --> 00:04:44,413
لذلك بدلا من مجرد قول عملية GET غير معتمدة،

65
00:04:44,413 --> 00:04:48,879
أنا ذاهب فقط للاستفادة من وجود هذه العملية الحصول على.

66
00:04:48,879 --> 00:04:52,574
وبعد ذلك سوف نقول

67
00:04:52,574 --> 00:04:56,684
، المفضلة.

68
00:04:56,684 --> 00:04:59,843
وسوف أقول،

69
00:04:59,843 --> 00:05:04,952
المستخدم: req.user.id

70
00:05:04,952 --> 00:05:10,194
لذلك سوف نجد المفضلة لهذا المستخدم معين.

71
00:05:10,194 --> 00:05:20,166
وبعد ذلك سوف نقول، ثم، المفضلة.

72
00:05:26,483 --> 00:05:32,913
و، قبض ((يخطئ)،

73
00:05:35,757 --> 00:05:40,160
التالي (يخطئ)).

74
00:05:40,160 --> 00:05:45,638
ثم وبالمثل هنا، سوف نضيف في الخطأ هنا.

75
00:05:48,689 --> 00:05:50,239
التالي (err))، هنا.

76
00:05:50,239 --> 00:05:55,689
حتى داخل هذا. ثم, عندما نحصل على المفضلة,

77
00:05:55,689 --> 00:06:00,290
ثم نحن سوف تحقق, إذا (! المفضلة).

78
00:06:00,290 --> 00:06:04,500
لذلك، إذا لم تكن هناك المفضلة لهذا المستخدم،

79
00:06:04,500 --> 00:06:08,770
فمن الواضح أن الطبق الذي نقوم بالتحقق منه غير موجود.

80
00:06:08,770 --> 00:06:18,604
لذا سنعود يا (ريستاتوسكود) 200

81
00:06:22,232 --> 00:06:29,488
سيثيادر ('نوع المحتوى

82
00:06:29,488 --> 00:06:34,436
'' تطبيق/جسون ').

83
00:06:34,436 --> 00:06:36,237
ثم سنعود

84
00:06:42,997 --> 00:06:51,490
قائلا: «موجود»: كاذبة.

85
00:06:51,490 --> 00:06:56,891
لذلك ما نحدده هنا هو أنه إذا تم الحصول على

86
00:06:56,891 --> 00:07:02,771
نقطة النهاية هذه مع Dishid،

87
00:07:02,771 --> 00:07:07,826
سيتم تعيين هذا العلم الموجود هنا إلى true إذا كان هذا الطبق جزءًا من المفضلة.

88
00:07:07,826 --> 00:07:13,008
إذا لم يكن هذا الطبق جزءًا من المفضلة، فسوف أقوم بتعيين العلم الموجود إلى false.

89
00:07:13,008 --> 00:07:16,687
حتى هنا، ترى أنه منذ ليس لدي أي المفضلة، لذلك

90
00:07:16,687 --> 00:07:20,008
يجب أن يكون موجودا تلقائيا خطأ في هذه المرحلة.

91
00:07:20,008 --> 00:07:26,780
لذلك سنقول «موجود»: كاذبة، ومن ثم سنعود المفضلة، هنا.

92
00:07:28,950 --> 00:07:31,237
حسنا، من الواضح في هذه الحالة،

93
00:07:31,237 --> 00:07:35,225
فإن المفضلة تكون فارغة في هذه المرحلة، وإلا.

94
00:07:39,097 --> 00:07:42,779
لذلك مما يعني أن المفضلة ليست فارغة، لذلك سنقول إذا،

95
00:07:45,218 --> 00:07:52,688
(favorites.days.indexOf)،

96
00:07:52,688 --> 00:07:58,011
لذلك نحن ذاهبون للبحث عن req.params.

97
00:08:00,046 --> 00:08:02,620
DisHid، لذلك نحن ذاهبون للبحث في هذا.

98
00:08:02,620 --> 00:08:09,632
الأطباق. صفيف، لمعرفة ما إذا كان هناك طبق موجود في هناك.

99
00:08:09,632 --> 00:08:15,410
وإذا لم يكن موجودًا، فمن الواضح أن هذا سيعود إلى مؤشر سلبي هنا.

100
00:08:15,410 --> 00:08:20,200
لذلك في هذه الحالة أيضا، سأعود بالضبط نفس هنا.

101
00:08:20,200 --> 00:08:22,291
لذلك إذا قامت بإرجاع فهرس سلبي،

102
00:08:22,291 --> 00:08:26,990
فهذا يعني أنه على الرغم من أن هذا المستخدم معين لديه مركز مفضل.

103
00:08:26,990 --> 00:08:31,464
هذا الطبق المحدد غير موجود في القائمة

104
00:08:31,464 --> 00:08:36,987
المفضلة له أو لها، لذلك هذا هو السبب في أنه سوف يعود موجودة كاذبة هنا.

105
00:08:36,987 --> 00:08:45,119
الآن وإلا فإن هذا يعني أن الطبق موجود في قائمة المفضلة.

106
00:08:45,119 --> 00:08:51,352
لذلك في هذه الحالة، سأعود رمز الحالة 200 موجود صحيح.

107
00:08:51,352 --> 00:08:57,144
بهذه الطريقة عندما يقوم المستخدم بإجراء عملية الحصول على

108
00:08:57,144 --> 00:09:02,408
نقطة النهاية هذه مع/favorite/dished.

109
00:09:02,408 --> 00:09:07,265
حيث يتم توفير DisHid كمعلمة هنا.

110
00:09:07,265 --> 00:09:09,821
كمعلمة السجلات هنا،

111
00:09:09,821 --> 00:09:15,226
ثم سوف نتحقق لمعرفة ما إذا كان هذا الطبق موجود في المفضلة.

112
00:09:15,226 --> 00:09:19,983
إذا لم يكن أي من المفضلة موجودة لهذا المستخدم، فسنقوم بإرجاع وجود false.

113
00:09:19,983 --> 00:09:22,138
وبالمثل، إذا كانت المفضلة موجودة،

114
00:09:22,138 --> 00:09:27,000
ولكن هذا الطبق معين غير موجود في المفضلة ثم انها ستعود كاذبة.

115
00:09:27,000 --> 00:09:28,705
وإلا فإنه سيعود صحيح.

116
00:09:28,705 --> 00:09:33,890
لذلك يمكن استخدام هذا العلم الموجود من قبل موكلي للتحقق

117
00:09:33,890 --> 00:09:41,997
لمعرفة ما إذا كان هذا الطبق هو جزء من قائمة الأطباق المفضلة لهذا المستخدم أم لا.

118
00:09:41,997 --> 00:09:48,624
وأخيرا سنقوم بتحديث ملف users.js.

119
00:09:48,624 --> 00:09:53,284
الآن في ملف users.js، نحن بحاجة إلى إضافة في

120
00:09:53,284 --> 00:09:58,204
مجال router.options آخر هنا لأنه في

121
00:09:58,204 --> 00:10:03,769
بعض الأحيان طلب المشاركة كما رأيت مع تسجيل الدخول،

122
00:10:03,769 --> 00:10:10,760
سنرسل الخيارات أولا للتحقق، وخاصة مع السيارات،

123
00:10:10,760 --> 00:10:16,140
ما إذا كان سيتم السماح بطلب آخر.

124
00:10:16,140 --> 00:10:23,156
لهذا السبب سيتحققون من السيارات والسيارات مع الخيارات هنا وبعد ذلك.

125
00:10:26,156 --> 00:10:27,915
سنقوم ببساطة بإرجاع

126
00:10:34,203 --> 00:10:39,938
رسالة حالة من 200 ردا على ذلك.

127
00:10:39,938 --> 00:10:44,624
لذلك لأي نقطة نهاية تحت المستخدمين إذا تلقينا

128
00:10:44,624 --> 00:10:50,183
الخيارات ببساطة إرجاع حالة 200 هنا.

129
00:10:50,183 --> 00:10:57,417
الآن وظيفة تسجيل الدخول التي قمنا بتنفيذها في وقت سابق.

130
00:10:57,417 --> 00:11:02,782
لقد فعلنا ببساطة passport.authenticate ('المحلية') هنا

131
00:11:02,782 --> 00:11:06,600
ثم نتحقق من القيم المتبقية هنا.

132
00:11:06,600 --> 00:11:11,006
الآن هذا passport.authenticate ('المحلية')، إذا لم يتم

133
00:11:11,006 --> 00:11:15,221
مصادقة المستخدم، فإنه ببساطة إرجاع غير مصرح به في رسالة الرد.

134
00:11:15,221 --> 00:11:18,212
الآن قد لا يكون ذلك مفيدًا جدًا

135
00:11:18,212 --> 00:11:21,868
لجانب العميل لعرض هذه المعلومات.

136
00:11:21,868 --> 00:11:27,245
ولهذا السبب سنقوم بتعزيز طريقة تسجيل الدخول بعد جهاز التوجيه

137
00:11:27,245 --> 00:11:35,158
هذه بحيث تقوم المصادقة بإرجاع معلومات أكثر معنى في هذا الجزء.

138
00:11:35,158 --> 00:11:39,831
حتى نفعل ذلك، نحن لن نقوم

139
00:11:39,831 --> 00:11:43,120
بتوثيق جواز السفر في الداخل هنا.

140
00:11:43,120 --> 00:11:47,180
بدلا من ذلك، سوف نأخذ، لذلك اسمحوا لي إزالة ذلك من هناك،

141
00:11:47,180 --> 00:11:52,410
وبعد ذلك سترى كيف سوف تحديث وظيفة جهاز التوجيه هنا.

142
00:11:52,410 --> 00:11:56,520
لذا سنرى سيارات ويثوبوتيونس

143
00:11:56,520 --> 00:12:03,806
وبعد ذلك سنقوم بتضمين req، الدقة والقادمة هنا.

144
00:12:03,806 --> 00:12:08,216
وداخل req، الدقة،

145
00:12:08,216 --> 00:12:14,227
وبعد ذلك هنا، passport.authenticate،

146
00:12:17,271 --> 00:12:22,035
ونحن سوف ندعو هذا مع «المحلية».

147
00:12:22,035 --> 00:12:27,041
الآن عندما نسمي هذا مع المحلية، في حالة

148
00:12:27,041 --> 00:12:34,607
حدوث خطأ في المصادقة، يمكن إجراء passport.authenticate لإرجاع قيمة الخطأ،

149
00:12:34,607 --> 00:12:39,519
وكذلك سيعود المستخدم إذا لم يكن هناك خطأ.

150
00:12:39,519 --> 00:12:42,283
ويمكن أن المعلمة تسمى المعلومات،

151
00:12:42,283 --> 00:12:47,643
والتي سوف تحمل معلومات إضافية التي قد يتم تمريرها مرة أخرى إلى المستخدم.

152
00:12:47,643 --> 00:12:51,714
سيتم إرجاع هذا الخطأ عندما يكون هناك خطأ حقيقي يحدث

153
00:12:51,714 --> 00:12:53,590
في الممكن للمصادقة.

154
00:12:53,590 --> 00:12:58,995
ولكن إذا تم إرسال معلومات المستخدم إلى passport.authenticate ولكن

155
00:12:58,995 --> 00:13:03,945
المستخدم غير موجود، فلا يتم حساب ذلك كخطأ.

156
00:13:03,945 --> 00:13:07,828
بدلاً من ذلك، سيتم حسابها نظرًا لأن المستخدم غير موجود.

157
00:13:07,828 --> 00:13:12,825
ويتم تمرير هذه المعلومات مرة أخرى في كائن المعلومات التي تأتي في.

158
00:13:12,825 --> 00:13:16,793
لذلك سيتم إرجاع الخطأ عندما يكون هناك خطأ حقيقي يحدث أثناء

159
00:13:16,793 --> 00:13:18,405
عملية المصادقة.

160
00:13:18,405 --> 00:13:23,995
ولكن المعلومات، وأنها سوف تحتوي على معلومات إذا كان المستخدم غير موجود وبالتالي

161
00:13:23,995 --> 00:13:30,102
فإن passport.authenticate يمر مرة أخرى رسالة تقول أن المستخدم غير

162
00:13:30,102 --> 00:13:35,780
موجود أو إما اسم المستخدم غير صحيح أو كلمة المرور غير صحيحة.

163
00:13:35,780 --> 00:13:40,415
وهكذا، بحيث سيتم تمرير المعلومات في، في رسالة المعلومات.

164
00:13:40,415 --> 00:13:44,569
الآن، سنرى كيف يكون هذا مفيدًا لنا عندما ننظر إلى جانب العميل

165
00:13:44,569 --> 00:13:45,990
بعد ذلك بقليل.

166
00:13:45,990 --> 00:13:48,070
لذلك في هذه الحالة،

167
00:13:49,530 --> 00:13:55,110
سوف نتعامل مع هذا على النحو التالي.

168
00:13:55,110 --> 00:14:00,510
وليس ذلك فقط، عندما نسمي هذا جواز السفر مصادقة،

169
00:14:00,510 --> 00:14:04,976
ونحن بحاجة أيضا إلى تمرير في (req، res،

170
00:14:04,976 --> 00:14:08,550
التالي) كما أن شريط المعلمات الثلاثة.

171
00:14:08,550 --> 00:14:10,320
لذلك هذا هو الهيكل.

172
00:14:10,320 --> 00:14:13,558
عندما تحتاج إلى الاتصال بمصادقة جواز السفر،

173
00:14:13,558 --> 00:14:18,798
توقع أن تقوم بتمرير معلومات مثل هذه كطريقة معاودة الاتصال هنا.

174
00:14:18,798 --> 00:14:24,072
لذلك تحتاج أيضا إلى توفير هذا req، الدقة القادمة هناك أيضا.

175
00:14:24,072 --> 00:14:25,720
الآن، إذا حدث هذا

176
00:14:25,720 --> 00:14:30,206
لذلك سنقول إذا (خطأ).

177
00:14:30,206 --> 00:14:34,163
لذلك إذا كان هناك خطأ يحدث،

178
00:14:34,163 --> 00:14:39,781
فسنقول العودة التالية (err) ومن ثم السماح

179
00:14:39,781 --> 00:14:45,028
لمعالج الأخطاء من جهاز التوجيه السريع لدينا رعاية ذلك.

180
00:14:45,028 --> 00:14:48,365
الآن، سننظر في حالات أخرى

181
00:14:48,365 --> 00:14:53,484
إذا (! )، لذلك إذا وصلنا إلى هذه النقطة، فهذا يعني أنه

182
00:14:53,484 --> 00:14:59,232
لم يكن خطأ حدث ولكن بدلاً من ذلك ربما لا يمكن العثور على المستخدم.

183
00:14:59,232 --> 00:15:04,860
إذا لم يتم العثور على المستخدم ثم سيتم تعيين المستخدم هنا إلى فارغة في هذه الحالة.

184
00:15:04,860 --> 00:15:10,088
لذلك، في هذه الحالة إذا كان المستخدم غير موجود،

185
00:15:10,088 --> 00:15:17,068
ثم نحن بحاجة إلى أن تكون قادرة على تمرير المعلومات مرة أخرى إلى جانب الخادم.

186
00:15:17,068 --> 00:15:22,895
لذا ما سنفعله هو أننا سنمر في هذه المعلومات بهذا الشكل،

187
00:15:22,895 --> 00:15:26,576
لذا سأقوم بقطع هذا من هنا،

188
00:15:26,576 --> 00:15:30,491
ثم لصقه هنا وبعد ذلك سنقوم بتحريره.

189
00:15:30,491 --> 00:15:36,748
إذا كان المستخدم فارغًا، فسنقوم بإرسال StatusCode

190
00:15:36,748 --> 00:15:41,509
من 401 مما يعني غير مصرح به،

191
00:15:41,509 --> 00:15:47,640
ثم سنقوم بإرسال نجاح المعلومات، false.

192
00:15:47,640 --> 00:15:54,340
وبعد ذلك نحن لن نمر مرة أخرى الرمز، ونحن سوف نمر مرة أخرى رسالة الحالة.

193
00:15:54,340 --> 00:16:02,501
حتى هنا سوف نقول تسجيل الدخول، غير ناجحة.

194
00:16:02,501 --> 00:16:07,870
ثم المعلومات الثالثة سوف تمر هذه المعلومات،

195
00:16:07,870 --> 00:16:13,238
ذلك الكائن الذي تلقيناه هنا كالجزء الثالث في

196
00:16:13,238 --> 00:16:19,231
رسالة الرد التي نرسلها مرة أخرى من الخادم لدينا هنا.

197
00:16:19,231 --> 00:16:22,496
لذلك سيتم إعادة تعيين علامة النجاح إلى false.

198
00:16:22,496 --> 00:16:27,145
سيتم تعيين الحالة تسجيل الدخول غير ناجحة ومعلومات الخطأ،

199
00:16:27,145 --> 00:16:30,235
التي يتم تمريرها في المعلومات سيتم تمريرها مرة أخرى.

200
00:16:30,235 --> 00:16:34,788
لاحظ الآن أن هذا الموقف سيحدث إذا كان اسم المستخدم وكلمة

201
00:16:34,788 --> 00:16:36,789
المرور غير صحيحين.

202
00:16:36,789 --> 00:16:42,516
وبالتالي هذا ليس خطأ، بمعنى الخطأ، ولكن حقيقة أن المصادقة

203
00:16:42,516 --> 00:16:47,505
لا يمكن العثور على المستخدم أو كلمة المرور للمستخدم غير صحيحة.

204
00:16:47,505 --> 00:16:51,545
بحيث سيتم ترميز هذه المعلومات في التدفق الذي يأتي، وحتى

205
00:16:51,545 --> 00:16:58,227
أنني سوف تمر مرة أخرى كخطأ إلى جانب العميل الخاص بي.

206
00:16:58,227 --> 00:17:02,633
وإلا يتم

207
00:17:02,633 --> 00:17:08,810
التعامل مع جزء كما Req.Login.

208
00:17:08,810 --> 00:17:10,700
لذلك إذا كان هذا ناجحا،

209
00:17:10,700 --> 00:17:16,200
فإن passport.authenticate إضافة هذه الطريقة تسمى Req.login للمستخدم.

210
00:17:16,200 --> 00:17:21,400
لذلك في هذه المرحلة سوف نمر فقط في كائن المستخدم الذي حصلنا عليه.

211
00:17:21,400 --> 00:17:26,398
حتى هنا، إذا وصلنا إلى هذه النقطة،

212
00:17:26,398 --> 00:17:32,572
ثم وهذا يعني أن كائن المستخدم ليست فارغة

213
00:17:32,572 --> 00:17:37,717
وأيضا لم يحدث خطأ، وهذا يعني أن

214
00:17:37,717 --> 00:17:43,304
المستخدم يمكن تسجيل الدخول ولذا فإننا سوف نقول خطأ.

215
00:17:43,304 --> 00:17:44,995
لذلك سيحاول تسجيل الدخول إلى المستخدم.

216
00:17:44,995 --> 00:17:47,231
لذا سنقول إذا أخطأت

217
00:17:51,210 --> 00:17:58,260
وبعد ذلك سنرجع نفس النوع من معلومات الخطأ التي فعلناها هنا.

218
00:17:59,450 --> 00:18:02,317
حتى في هذه الحالة، إذا كان الخطأ.

219
00:18:06,077 --> 00:18:11,757
إذا كان الخطأ، ثم سنقوم بتمرير رمز الحالة 401

220
00:18:11,757 --> 00:18:18,970
وسنقول النجاح هو خطأ والحالة هو تسجيل الدخول غير ناجحة.

221
00:18:18,970 --> 00:18:24,359
ثم معلومات الخطأ

222
00:18:24,359 --> 00:18:29,539
سنقوم بتمرير هذا بدلا من

223
00:18:29,539 --> 00:18:36,810
المعلومات التي سنمررها لا يمكن تسجيل الدخول المستخدم.

224
00:18:36,810 --> 00:18:42,580
لذلك هذه هي الرسالة التي سوف تمر مرة أخرى هنا، إذا حدث الخطأ.

225
00:18:42,580 --> 00:18:46,195
وإلا، سنكون أسفل هنا.

226
00:18:46,195 --> 00:18:53,157
وهكذا في هذه المرحلة سنكون قادرين على توليد الرمز المميز.

227
00:18:53,157 --> 00:18:57,594
لذلك إذا وصلنا إلى هذه النقطة فهذا يعني أن المستخدم قد قام

228
00:18:57,594 --> 00:19:01,892
بتسجيل الدخول بنجاح وحتى نتمكن الآن من إنشاء الرمز المميز.

229
00:19:01,892 --> 00:19:07,009
لذلك سنقوم بإنشاء الرمز المميز استنادًا إلى معرف المستخدم ومن

230
00:19:07,009 --> 00:19:11,794
ثم سنقوم بتمرير هذا الرمز مرة أخرى إلى المستخدم.

231
00:19:11,794 --> 00:19:15,462
حتى هنا سوف نقول فار رمزية.

232
00:19:15,462 --> 00:19:22,789
ومن ثم يمكننا أن نقول Res.statusCode = 200، ثم res.json (النجاح) صحيح،

233
00:19:22,789 --> 00:19:26,999
مما يعني أن المستخدم قام بتسجيل الدخول بنجاح.

234
00:19:26,999 --> 00:19:31,842
وبالتالي فإن الحالة ستكون تسجيل الدخول بنجاح،

235
00:19:31,842 --> 00:19:39,900
ثم الجزء الثالث بدلا من الخطأ سوف تمرير الرمز المميز مرة أخرى إلى المستخدم.

236
00:19:39,900 --> 00:19:45,590
لذلك سنقول رمزية، رمزية،

237
00:19:45,590 --> 00:19:50,390
هذا الرمز المميز الذي حصلنا عليه للتو في وقت سابق، بحيث سيتم تمرير

238
00:19:50,390 --> 00:19:54,600
الرمز المميز كخاصية رمزية لرسالة ضوء مزق.

239
00:19:54,600 --> 00:19:57,910
لذلك هنا، لاحظ أن هذا المحور تم تعيينه إلى true.

240
00:19:57,910 --> 00:20:01,890
مما يعني أن المستخدم قام بتسجيل الدخول بنجاح.

241
00:20:01,890 --> 00:20:05,660
وبالتالي يمكن للمستخدم المضي قدما في هذه المرحلة.

242
00:20:05,660 --> 00:20:13,667
وهذا يجب أن يتم داخل Req.Login هنا.

243
00:20:13,667 --> 00:20:20,640
لذلك في هذه المرحلة سنقوم بإغلاق Req.Login.

244
00:20:20,640 --> 00:20:27,570
لذلك لاحظ أن هذا هو داخل هذا req.Login هنا.

245
00:20:27,570 --> 00:20:30,830
لذلك في هناك سوف نمر هؤلاء الثلاثة مرة أخرى.

246
00:20:30,830 --> 00:20:33,800
لذلك اسمحوا لي أن مجرد مسافة بادئة درسية ثلاثة أسطر في.

247
00:20:35,830 --> 00:20:42,490
وهكذا كيف سنتعامل مع تسجيل دخول المستخدمين.

248
00:20:42,490 --> 00:20:45,850
مرة أخرى، مراجعة هذا الرمز مرة أخرى.

249
00:20:45,850 --> 00:20:47,740
لذلك سنقوم بعمل آخر جهاز التوجيه، ولكن

250
00:20:47,740 --> 00:20:52,490
بدلاً من القيام بمصادقة جواز السفر هناك، سنقول req، الدقة،

251
00:20:52,490 --> 00:20:57,970
التالي ثم داخل هنا سنقوم بعمل passport.authenticate المحلية.

252
00:20:57,970 --> 00:21:02,930
وسوف تمر هذه المصادقة مرة أخرى، حتى نتمكن من توفير وظيفة رد الاتصال لذلك.

253
00:21:02,930 --> 00:21:06,810
وستعود وظيفة رد الاتصال هذه إما الخطأ أو المستخدم أو

254
00:21:06,810 --> 00:21:08,370
المعلومات هنا.

255
00:21:08,370 --> 00:21:13,220
وهكذا، إذا حدث خطأ، فسنسمح فقط لمعالج الخطأ السريع

256
00:21:13,220 --> 00:21:14,560
بالاهتمام بذلك.

257
00:21:14,560 --> 00:21:20,580
إذا كان المستخدم فارغًا، فهذا يعني أن تسجيل دخول المستخدم لم يكن ناجحًا،

258
00:21:20,580 --> 00:21:25,090
وسيكون السبب في ذلك في المعلومات بحيث يتم تمريره

259
00:21:25,090 --> 00:21:30,660
كخطأ في المعلومات في رسالة الخطة هنا.

260
00:21:30,660 --> 00:21:37,190
إذا وصلنا إلى هذه النقطة ثم يتم التحقق من المستخدم بنجاح.

261
00:21:37,190 --> 00:21:38,898
حتى ذلك الحين سوف نقوم بتسجيل الدخول للمستخدم.

262
00:21:38,898 --> 00:21:43,850
وبالتالي فإن passport.authenticate إضافة في هذه الطريقة تسمى تسجيل الدخول إلى

263
00:21:43,850 --> 00:21:51,090
رسالة الطلب، حتى نتمكن من استدعاء تسجيل الدخول مع المستخدم

264
00:21:51,090 --> 00:21:56,760
وإذا كان هذا إرجاع خطأ، ثم سنقوم بإرجاع الخطأ هنا بشكل مناسب.

265
00:21:56,760 --> 00:22:01,400
إذا لم يكن الأمر كذلك، سنكون قد وصلنا إلى النقطة التي

266
00:22:01,400 --> 00:22:06,560
تمت مصادقة المستخدم بنجاح حتى يتمكنوا من إنشاء رمز ويب JSON هنا وإرجاع

267
00:22:06,560 --> 00:22:12,020
رمز ويب JSON إلى المستخدم للتأكد من تسجيل المستخدم بنجاح.

268
00:22:12,020 --> 00:22:15,190
هذه هي مجموعة الخطوات التي سنستخدمها هنا.

269
00:22:15,190 --> 00:22:19,910
الآن السبب في أنني أفعل طريقة أكثر تفصيلا للتعامل معها هو أنني أريد

270
00:22:19,910 --> 00:22:24,760
التمييز بين الوضع حيث يحدث خطأ حقيقي أثناء

271
00:22:24,760 --> 00:22:30,700
عملية التطبيق، بدلا من الوضع حيث اسم المستخدم غير صالح،

272
00:22:30,700 --> 00:22:32,830
أو كلمة المرور غير صالحة.

273
00:22:32,830 --> 00:22:37,713
لذلك سيتم التعامل مع هاتين الحالتين من خلال هذا الوضع حيث المعلومات سوف

274
00:22:37,713 --> 00:22:40,129
تحمل المعلومات مرة أخرى لنا.

275
00:22:40,129 --> 00:22:44,551
لذلك هذا ليس خطأ بيرس ولكن هذا

276
00:22:44,551 --> 00:22:49,440
هو الوضع حيث المستخدم ليس مستخدما صالحا أو كلمة مرور المستخدم غير صالحة.

277
00:22:49,440 --> 00:22:54,880
لذلك هذه هي الطريقة التي سوف التعامل مع سجل المستخدم في العملية.

278
00:22:54,880 --> 00:22:59,666
بالإضافة إلى ذلك، سأضيف طريقة واحدة أخرى هنا تسمى،

279
00:23:05,730 --> 00:23:08,832
CheckJWToken.

280
00:23:08,832 --> 00:23:12,831
من الممكن جدا أنه في حين أن العميل قد قام بتسجيل الدخول

281
00:23:12,831 --> 00:23:18,229
والحصول على رمز ويب JSON، في وقت لاحق، قد تنتهي صلاحية رمز JSON Web Token.

282
00:23:18,229 --> 00:23:23,776
وهكذا إذا حاول المستخدم الوصول من جانب العميل مع رمز مميز منتهية الصلاحية

283
00:23:23,776 --> 00:23:29,159
إلى الخادم، فلن يتمكن الخادم من مصادقة المستخدم.

284
00:23:29,159 --> 00:23:34,024
لذلك على فترات دورية، قد نرغب في عبور التحقق للتأكد من أن

285
00:23:34,024 --> 00:23:35,733
رمز ويب JSON لا يزال صالحًا.

286
00:23:35,733 --> 00:23:41,180
لذلك هذا هو السبب في أنني بما في ذلك نقطة نهاية أخرى تسمى

287
00:23:41,180 --> 00:23:46,131
CheckJwtToken، لذلك إذا كنت تفعل الحصول على CheckJwtToken.

288
00:23:46,131 --> 00:23:50,927
من خلال تضمين الرمز المميز في رأس التخويل،

289
00:23:50,927 --> 00:23:55,926
ستعود هذه المكالمة إلى true أو false للإشارة إليك إلى

290
00:23:55,926 --> 00:24:00,125
ما إذا كان رمز ويب JSON لا يزال صالحًا أم لا.

291
00:24:00,125 --> 00:24:04,430
إذا لم يكن صالحًا، فيمكن لجانب العميل بدء تسجيل دخول آخر

292
00:24:04,430 --> 00:24:09,710
للمستخدم للحصول على رمز ويب JSON جديد، إذا لزم الأمر.

293
00:24:09,710 --> 00:24:15,470
لذلك للقيام بذلك، سنقول كورس، كورسويثوبوتيونس و،

294
00:24:19,500 --> 00:24:23,760
ريك، الدقة، هنا، كما هو متوقع.

295
00:24:25,510 --> 00:24:28,029
وهنا سوف نقول،

296
00:24:31,852 --> 00:24:40,983
passport.authenticate ('jwt'،

297
00:24:42,356 --> 00:24:49,886
و، {الجلسة: false}).

298
00:24:54,050 --> 00:24:59,322
وهذا من شأنه أن يعود خطأ، المستخدم، المعلومات.

299
00:25:03,010 --> 00:25:07,005
لذلك تذكر كيف استخدمنا مصدق جواز السفر في وقت سابق.

300
00:25:07,005 --> 00:25:11,050
لذلك تقع جلسة JWT هنا.

301
00:25:11,050 --> 00:25:14,759
حتى في وقت سابق هنا نقول، passport.authenticate المحلية.

302
00:25:14,759 --> 00:25:17,039
لذلك هذا هو للمصادقة المحلية.

303
00:25:17,039 --> 00:25:21,038
لذلك هذا هو لمصادقة رمز ويب JSON.

304
00:25:21,038 --> 00:25:26,303
لذلك عندما نسمي ذلك، لأن ذلك سيتحقق من رمز ويب JSON،

305
00:25:26,303 --> 00:25:33,820
لذلك سأقول، إذا (err)، عد التالي (err).

306
00:25:33,820 --> 00:25:38,540
ثم دع معالج الخطأ Express يعتني بهذا الوضع.

307
00:25:38,540 --> 00:25:42,895
وبعد ذلك سنقول، إذا (! المستخدم)،

308
00:25:47,340 --> 00:25:53,395
إذا كان المستخدم غير موجود، ثم وبالمثل، آخر.

309
00:25:53,395 --> 00:25:58,850
مما يعني أنه إذا تم العثور على كائن المستخدم من رمز ويب JSON

310
00:25:58,850 --> 00:26:04,764
ثم تم تحميله على req.user، فهذا يعني أن المستخدم مستخدم صالح.

311
00:26:04,764 --> 00:26:06,990
وهكذا يمكن السماح للمضي قدما.

312
00:26:06,990 --> 00:26:13,770
خلاف ذلك، سنقول أن المستخدم غير موجود.

313
00:26:13,770 --> 00:26:18,480
لذلك نحن بحاجة إلى استنتاج أن رمز ويب JSON قد انتهت صلاحيته.

314
00:26:18,480 --> 00:26:24,495
لذلك في هذه المرحلة، سنرسل دقة مع رمز الحالة

315
00:26:29,070 --> 00:26:31,580
401، لذلك غير مصرح به.

316
00:26:33,847 --> 00:26:40,570
سيثيادر (، «نوع المحتوى

317
00:26:42,865 --> 00:26:45,940
»، «تطبيق/جسون»).

318
00:26:45,940 --> 00:26:52,243
ثم سنعود الدقة،

319
00:26:54,894 --> 00:27:00,970
.json، سنقول، {الحالة:،

320
00:27:04,165 --> 00:27:07,131
«JWT غير صالح!».

321
00:27:07,131 --> 00:27:15,242
وبعد ذلك سنعود العلم يسمى النجاح: كاذبة.

322
00:27:15,242 --> 00:27:20,624
ثم, سنقوم بإرجاع المعلومات التي

323
00:27:20,624 --> 00:27:26,890
نحصل عليها إذا لم يتم مصادقة المستخدم كخطأ في هذه المرحلة.

324
00:27:30,450 --> 00:27:36,219
وإلا، فهذا يعني أننا نصل إلى هذه النقطة عندما يكون المستخدم مستخدمًا صالحًا.

325
00:27:36,219 --> 00:27:40,921
حتى في هذه الحالة، اسمحوا لي فقط نسخ هذا الرمز هنا،

326
00:27:40,921 --> 00:27:45,392
ونحن سوف ترسل رمز الحالة من 200،

327
00:27:45,392 --> 00:27:48,727
وبعد ذلك res.json إرسال جوت،

328
00:27:51,140 --> 00:27:55,050
صالح! ، والنجاح سيكون صحيحا.

329
00:27:56,550 --> 00:28:03,290
والجزء الثالث، سوف نرسل معلومات المستخدم.

330
00:28:03,290 --> 00:28:07,776
وبهذه الطريقة، عندما يتم استدعاء نقطة النهاية هذه

331
00:28:07,776 --> 00:28:12,710
باستخدام طريقة get، فسيتحقق هذا مما إذا كان الرمز المميز صالحًا أم لا.

332
00:28:12,710 --> 00:28:15,580
إذا كان الرمز المميز صالحًا، فستتلقى هذا الرد.

333
00:28:15,580 --> 00:28:17,311
ومن علامة النجاح في الرد،

334
00:28:17,311 --> 00:28:20,050
يمكنك التحقق لمعرفة ما إذا كان رمز ويب JSON صالحًا أم لا.

335
00:28:20,050 --> 00:28:24,010
وهذا مفيد على جانب العميل.

336
00:28:24,010 --> 00:28:30,012
الآن هذا جواز السفر هنا, passport.authenticate هنا,

337
00:28:30,012 --> 00:28:37,720
يجب أن يتم توفيره مع req و الدقة كما المعلمات اثنين هنا.

338
00:28:37,720 --> 00:28:41,320
لذا هكذا نسمي ذلك جواز السفر.

339
00:28:41,320 --> 00:28:45,060
لاحظ أنه عند استدعاء passport.authenticate

340
00:28:45,060 --> 00:28:49,917
وتتوقع وظيفة رد الاتصال هذه هنا، تحتاج إلى إلحاق هذه النقطة، req،

341
00:28:49,917 --> 00:28:53,973
.res، إلى ذلك passport.authenticate، ثم العودة إلى هنا.

342
00:28:53,973 --> 00:28:57,915
لذلك مع هذا، قمنا بتحديث كل شيء على جانب الخادم.

343
00:28:57,915 --> 00:29:01,900
لذلك دعونا حفظ جميع التغييرات على جانب الخادم.

344
00:29:01,900 --> 00:29:05,400
حتى الآن خادمنا جاهز

345
00:29:05,400 --> 00:29:10,680
للتعامل مع الطلبات الواردة من عميل Angular الخاص بنا.

346
00:29:10,680 --> 00:29:13,120
مع هذا، نكمل هذا التمرين.

347
00:29:13,120 --> 00:29:18,010
في هذا التمرين، قمنا الآن بإعداد خادم Express الخاص بنا

348
00:29:18,010 --> 00:29:22,930
للتعامل مع الطلبات الواردة من عميلنا Angular.

349
00:29:22,930 --> 00:29:26,890
في التمرين التالي، سنلقي نظرة على العميل Angular بمزيد من التفصيل

350
00:29:26,890 --> 00:29:32,350
لفهم كيفية التواصل مع هذا الخادم الإضافي.

351
00:29:32,350 --> 00:29:37,881
هذا هو الوقت المناسب بالنسبة لك للقيام جيت الالتزام مع الرسالة،

352
00:29:37,881 --> 00:29:40,932
ودمج العميل والخادم.

353
00:29:40,932 --> 00:29:44,825
[ موسيقى]