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

2
00:00:04,869 --> 00:00:06,266
في الدروس السابقة،

3
00:00:06,266 --> 00:00:10,110
رأينا عدة أنواع مختلفة من مخططات التوثيق.

4
00:00:10,110 --> 00:00:14,910
بدأنا بالمصادقة الأساسية، ثم نظرنا في كيفية استخدام ملفات تعريف الارتباط

5
00:00:14,910 --> 00:00:18,290
للقيام بالمصادقة، وحتى ملفات تعريف الارتباط الموقعة،

6
00:00:18,290 --> 00:00:22,090
وبعد ذلك، نظرنا في المصادقة المستندة إلى الجلسة.

7
00:00:22,090 --> 00:00:27,070
حيث يتتبع الخادم معلومات حول كل عميل،

8
00:00:27,070 --> 00:00:30,680
ثم سيتم استخدام ملف تعريف الارتباط كطريقة للفهرسة في

9
00:00:30,680 --> 00:00:35,720
قاعدة البيانات من جانب الخادم لاستخراج معلومات إضافية، للتحقق من صحة المستخدم.

10
00:00:35,720 --> 00:00:41,160
الآن، ملفات تعريف الارتباط والمصادقة المستندة إلى جلسة العمل غير قابلة للتطوير،

11
00:00:41,160 --> 00:00:47,300
لأن هناك خادم يحتاج إلى تتبع جميع المستخدمين المختلفين.

12
00:00:48,820 --> 00:00:53,120
على الرغم من ذلك، يتم ذلك خارج بروتوكول HTTP نفسه، ولكن

13
00:00:53,120 --> 00:00:56,160
لا يزال حقيقة أنك تحتاج إلى تتبع

14
00:00:56,160 --> 00:01:00,660
جميع معلومات القسم من موقع الخادم، يجعلها غير قابلة للتطوير للغاية.

15
00:01:00,660 --> 00:01:04,510
لذلك هذا هو المكان الذي

16
00:01:04,510 --> 00:01:06,570
أثبتت المصادقة المستندة إلى الرمز المميز أنها مفيدة للغاية.

17
00:01:06,570 --> 00:01:11,260
سنلقي نظرة على مصادقة قاعدة الرمز المميز أكثر تفصيلاً في هذه المحاضرة

18
00:01:11,260 --> 00:01:12,830
وممارسة ما يلي.

19
00:01:14,680 --> 00:01:18,880
مرة أخرى، مراجعة ملفات تعريف الارتباط والمصادقة القائمة على جلسة العمل بسرعة.

20
00:01:18,880 --> 00:01:20,580
مع المصادقة المستندة إلى ملف

21
00:01:20,580 --> 00:01:25,240
تعريف الارتباط، نلاحظ أن ملفات تعريف الارتباط يتم تخزينها على جانب العميل، ويتم تضمين ملفات تعريف الارتباط

22
00:01:25,240 --> 00:01:29,510
في كل رسالة طلب صادرة حيث يتم تذكير الخادم

23
00:01:29,510 --> 00:01:35,050
بذلك العميل المحدد، عن طريق استخراج المعلومات من ملف تعريف الارتباط.

24
00:01:35,050 --> 00:01:40,550
يمكن استخدام ملف تعريف الارتباط مع جلسات العمل، حيث تقوم ملفات تعريف الارتباط بتخزين معرف الجلسة،

25
00:01:40,550 --> 00:01:44,650
ثم عندما يتلقى الخادم الطلب الوارد من ملف تعريف الارتباط،

26
00:01:44,650 --> 00:01:49,770
فإنه يستخرج معرف الجلسة ويستخدم ذلك كفهرس في

27
00:01:49,770 --> 00:01:55,210
مخزن جلسة العمل من جانب الخادم لاسترداد معلومات جلسة العمل عميل معين.

28
00:01:55,210 --> 00:01:56,840
الآن، هذا النهج كما قلت،

29
00:01:56,840 --> 00:02:01,234
ليس قابلاً للتطوير لأنه إذا كان لديك آلاف الجلسات، يحتاج الخادم إلى

30
00:02:01,234 --> 00:02:04,980
تتبع كل هذه الآلاف من الجلسات على جانب الخادم.

31
00:02:04,980 --> 00:02:10,820
على الرغم من أنه يتم بشكل مستقل عن HTTP في متجر،

32
00:02:10,820 --> 00:02:13,770
إما مخزن ملفات أو قاعدة بيانات.

33
00:02:13,770 --> 00:02:14,610
ولكن

34
00:02:14,610 --> 00:02:19,520
مع ذلك، حقيقة أنك تحتاج إلى تتبع كل هذه المعلومات يجعلها غير قابلة للتطوير.

35
00:02:19,520 --> 00:02:23,960
لذا، مرة أخرى، لتذكيرك مرة أخرى،

36
00:02:23,960 --> 00:02:27,201
لماذا نتحدث عن المصادقة المستندة إلى الرمز المميز؟

37
00:02:27,201 --> 00:02:32,260
المصادقة المستندة إلى الجلسة، كما رأينا سابقًا، تعمل بشكل جيد تمامًا

38
00:02:32,260 --> 00:02:39,910
لتطبيقات الويب ويمكن بسهولة العناية بمصادقة المستخدم.

39
00:02:39,910 --> 00:02:43,660
ولكن بعد ذلك، المصادقة المستندة إلى جلسة العمل، في حين أنه مبدأ

40
00:02:43,660 --> 00:02:48,280
الخوادم عديمة الجنسية ويؤدي أيضًا إلى مشاكل قابلية التوسع.

41
00:02:48,280 --> 00:02:52,727
المسألة الثانية هي، تطبيقات الهاتف المحمول لا

42
00:02:52,727 --> 00:02:58,090
تتعامل مع المصادقة المستندة إلى جلسة العمل بشكل جيد للغاية.

43
00:02:58,090 --> 00:03:01,742
وبالمثل، تواجه تطبيقات الهاتف المحمول صعوبة في التعامل مع ملفات تعريف الارتباط.

44
00:03:01,742 --> 00:03:08,048
لذلك، في مثل هذه الظروف حيث الخادم الخاص بك هو تقديم البيانات

45
00:03:08,048 --> 00:03:13,610
لكل من تطبيق ويب، فضلا عن التطبيق المحمول.

46
00:03:13,610 --> 00:03:19,275
بعد ذلك، لن تكون المصادقة المستندة إلى الجلسة مفيدة جدًا،

47
00:03:19,275 --> 00:03:25,139
وهذا هو المكان الذي تصبح فيه المصادقة المستندة إلى الرمز المميز أكثر سهولة في الاستخدام.

48
00:03:25,139 --> 00:03:29,369
في المصادقة المستندة إلى

49
00:03:29,369 --> 00:03:34,589
الرمز المميز كاسم في المكان، سيصدر الخادم رمزًا مميزًا لمستخدم تم التحقق من صحته

50
00:03:34,589 --> 00:03:40,803
، وستتحمل جميع الطلبات اللاحقة القادمة من جانب العميل الرمز المميز في الطلب نفسه.

51
00:03:40,803 --> 00:03:48,992
إما في شكل رأس طلب أو في نص رسالة الطلب.

52
00:03:48,992 --> 00:03:53,410
علاوة على ذلك، تساعدنا المصادقة المستندة إلى الرمز المميز أيضًا على

53
00:03:53,410 --> 00:03:57,965
التعامل مع ما يسمى مشكلات CORS أو CSRF.

54
00:03:57,965 --> 00:04:00,480
مشاكل مشاركة الموارد عبر الأصل وهلم

55
00:04:00,480 --> 00:04:04,360
جرا، سأتحدث بإيجاز عن التكلفة في الوحدة التالية.

56
00:04:04,360 --> 00:04:07,540
ولكن في الوقت الحالي، تعالج المصادقة المستندة إلى الرمز المميز بعض

57
00:04:07,540 --> 00:04:13,430
المشكلات التي تكمن في السيارات والقضايا المتعلقة بالتزوير عبر الموقع.

58
00:04:13,430 --> 00:04:17,680
ليس ذلك فقط، المصادقة المستندة إلى الرمز المميز هي أكثر سهولة

59
00:04:17,680 --> 00:04:21,700
لتطبيق واحد لمشاركة المصادقة الخاصة به مع تطبيق آخر.

60
00:04:21,700 --> 00:04:24,610
وبطبيعة الحال، يتم كل هذا بطريقة آمنة.

61
00:04:24,610 --> 00:04:28,867
ولكن، مع المصادقة القائمة على جلسة العمل، وهذا ليس مباشرة إلى الأمام.

62
00:04:28,867 --> 00:04:32,272
كيف تعمل المصادقة المستندة إلى الرمز المميز؟

63
00:04:32,272 --> 00:04:34,260
في المصادقة المستندة إلى الرمز المميز،

64
00:04:34,260 --> 00:04:40,020
يحتاج المستخدم أولاً إلى التحقق من صحة نفسه على جانب الخادم.

65
00:04:40,020 --> 00:04:44,040
الآن، يمكن لهذا التحقق أن يأخذ النماذج التي رأيناها في وقت سابق.

66
00:04:44,040 --> 00:04:48,519
حتى نتمكن من استخدام التحقق المحلي باستخدام اسم المستخدم وكلمة المرور.

67
00:04:48,519 --> 00:04:53,111
أو، يمكننا حتى استخدام التحقق من صحة طرف ثالث باستخدام

68
00:04:53,111 --> 00:04:58,267
تقنيات مثل، oauth أو oauth 2.0 أو معرف مفتوح.

69
00:04:58,267 --> 00:05:03,700
سنتحدث بإيجاز عن oauth و oauth 2.0 في الوحدة التالية.

70
00:05:03,700 --> 00:05:08,790
ولكن، بغض النظر عن الطريقة التي يصادق بها المستخدم، بمجرد

71
00:05:08,790 --> 00:05:14,370
مصادقة المستخدم، مباشرة بعد ذلك، يمكن للخادم الخاص بك ببساطة إصدار رمز مميز للمستخدم.

72
00:05:14,370 --> 00:05:18,790
وجميع الاتصالات اللاحقة بين المستخدم

73
00:05:18,790 --> 00:05:23,658
والخادم، ويمكن القيام به ببساطة باستخدام هذا الرمز المميز.

74
00:05:23,658 --> 00:05:29,240
JSON Web Token الذي سنتحدث عنه، هو أحد

75
00:05:29,240 --> 00:05:35,465
مخططات المصادقة المستندة إلى الرمز المميز، وهناك خادم عندما يقوم بإنشاء هذا الرمز المميز، فإنه سيتم إنشاء رمز مميز موقعة.

76
00:05:35,465 --> 00:05:40,315
استخدام سر على موقع الخادم الذي يعرفه الخادم فقط.

77
00:05:40,315 --> 00:05:43,965
وبالتالي، حتى إذا كان طرف ثالث في اتجاه وبين

78
00:05:43,965 --> 00:05:49,185
ويحاول التعامل مع الرمز المميز، حتى لو كان يلتقط الرمز المميز

79
00:05:49,185 --> 00:05:53,045
ويحاول التعامل مع الرمز المميز، سيصبح الرمز غير صالح.

80
00:05:53,045 --> 00:05:57,201
وهكذا، فإن هذه الطريقة لحماية المستخدم

81
00:05:57,201 --> 00:06:02,250
ممكنة بسهولة،

82
00:06:02,250 --> 00:06:07,430
يجب أن تحمل جميع الطلبات اللاحقة من جانب العميل الرمز المميز في الطلب

83
00:06:07,430 --> 00:06:11,870
، إما، كما قلت، في الرأس أو في نص رسالة الطلب.

84
00:06:11,870 --> 00:06:16,120
لذلك عندما يتلقى الخادم هذا الرمز المميز، سيقوم الخادم بالتحقق من الرمز المميز،

85
00:06:16,120 --> 00:06:20,810
للتأكد من أن هذا رمز مميز صالح، ثم إذا كان رمزًا صالحًا،

86
00:06:20,810 --> 00:06:25,430
فسيرد الخادم على الطلب الوارد.

87
00:06:25,430 --> 00:06:31,210
كما ذكرت، فإن رموز JSON Web Tokens هي أحد مخططات المصادقة المستندة إلى الرمز المميز.

88
00:06:31,210 --> 00:06:35,838
JSON Web Token، هي طريقة بسيطة جدًا لترميز

89
00:06:35,838 --> 00:06:41,174
المعلومات في رمز مميز ثم تمريرها إلى موقع العميل.

90
00:06:41,174 --> 00:06:45,702
ويستند جسون ويب رمز نفسه على المعايير،

91
00:06:45,702 --> 00:06:49,670
وهذا يعتمد على إيتف رفك 7519.

92
00:06:49,670 --> 00:06:53,499
IETF هنا، لتقف على فرقة عمل هندسة الإنترنت.

93
00:06:53,499 --> 00:07:00,011
المنظمة التي تكلف كل شيء عن كيفية عمل الإنترنت،

94
00:07:00,011 --> 00:07:06,427
وتتعامل مع البروتوكولات والسياسات، المتعلقة بالإنترنت.

95
00:07:06,427 --> 00:07:10,391
RFC، لتقف على وثيقة المعايير،

96
00:07:10,391 --> 00:07:15,270
في شروط IETF، RFC لتقف على طلب التعليقات.

97
00:07:15,270 --> 00:07:18,650
وكل وثيقة معايير من هذا القبيل تحمل عددا.

98
00:07:18,650 --> 00:07:23,560
7519 في هذه الحالة يشير إلى المستند،

99
00:07:23,560 --> 00:07:27,250
المستند القياسي المتعلق بـ JSON Web Token. رمز

100
00:07:27,250 --> 00:07:31,420
JSON Web Token نفسه هو رمز

101
00:07:31,420 --> 00:07:37,250
مضمن ذاتيا، ويحمل جميع المعلومات في حد ذاته، وهذا ضروري لتحديد المستخدم.

102
00:07:37,250 --> 00:07:43,080
ليس ذلك فقط، يمكن مشاركة JSON Web Token بين تطبيقين.

103
00:07:43,080 --> 00:07:46,930
على سبيل المثال،

104
00:07:46,930 --> 00:07:51,760
يمكن لتطبيق واحد عندما يصادق ثم يحصل على عقد من JSON Web Token، تمرير هذا JSON Web Token إلى وفي

105
00:07:51,760 --> 00:07:56,950
هذا التطبيق، أنه على استعداد للتصريح بالوصول إلى الخادم نيابة عنه.

106
00:07:56,950 --> 00:08:00,200
تتم مشاركة الرمز المميز هذه بطريقة آمنة للغاية،

107
00:08:00,200 --> 00:08:03,460
لذلك لا تقلق كثيرًا بشأن الأمان هناك.

108
00:08:03,460 --> 00:08:04,990
هذا ليس بطريقة آمنة،

109
00:08:04,990 --> 00:08:09,090
حيث من خلال مشاركة الرمز المميز بين تطبيق إلى آخر.

110
00:08:09,090 --> 00:08:13,250
وبالتالي، يتم نقل التفويض إلى تطبيق ثان،

111
00:08:13,250 --> 00:08:17,740
ويمكن للتطبيق الثاني أن يأذن نيابة عن التطبيق الأول،

112
00:08:17,740 --> 00:08:18,990
للتواصل مع الخادم.

113
00:08:20,200 --> 00:08:24,200
هذا ممكن مع الرموز.

114
00:08:24,200 --> 00:08:28,710
الآن بالطبع، من الواضح أن المهندس في داخلك يتساءل ما هو بالضبط

115
00:08:28,710 --> 00:08:32,690
داخل رمز ويب JSON، وكيف يكون مفيدًا؟

116
00:08:32,690 --> 00:08:39,120
يتم ترميز رمز JSON Web Token، كما قلت، في سلسلة طويلة

117
00:08:39,120 --> 00:08:43,530
ويمكن تفسير هذه السلسلة نفسها على أنها تتكون من ثلاثة أجزاء.

118
00:08:43,530 --> 00:08:49,470
السلسلة نفسها يمكن، أو السلسلة المشفرة نفسها تحتوي على ثلاثة أجزاء،

119
00:08:49,470 --> 00:08:52,896
الرأس، الحمولة، والتوقيع.

120
00:08:52,896 --> 00:08:59,070
هذا يحمل معلومات كافية حول كيفية ترميز هذا الرمز المميز.

121
00:08:59,070 --> 00:09:03,780
يحتوي الرأس نفسه على الخوارزمية المحددة التي يتم استخدامها

122
00:09:03,780 --> 00:09:08,460
لترميز رمز ويب JSON هذا، ونوع الرمز المميز نفسه.

123
00:09:08,460 --> 00:09:16,280
الخوارزمية في هذه الحالة، ستكون HS256 وهو مخطط ترميز 256 بت، والذي

124
00:09:16,280 --> 00:09:21,140
يستخدم لتجزئة المعلومات داخل الرمز المميز.

125
00:09:21,140 --> 00:09:24,350
وفي هذه الحالة، يحدث أن يكون هذا هو JSON Web Token، وبالتالي

126
00:09:24,350 --> 00:09:27,870
سيتم تعيين حقل النوع إلى JWT.

127
00:09:27,870 --> 00:09:33,210
وهكذا هذه هي المعلومات التي يتم تخزينها في رأس JSON Web Token.

128
00:09:33,210 --> 00:09:38,800
الحمولة نفسها، يحمل المعلومات التي تساعدك على التعرف على المستخدم.

129
00:09:38,800 --> 00:09:41,440
في التمرين الذي سنقوم به، لا

130
00:09:41,440 --> 00:09:46,730
تحمل حمولة الساعة إلا هوية المستخدم داخل الحمولة.

131
00:09:46,730 --> 00:09:48,720
لا توجد معلومات أخرى ضرورية.

132
00:09:48,720 --> 00:09:51,690
يمكن استخدام هذا المعرف على جانب الخادم،

133
00:09:51,690 --> 00:09:58,350
لفهرسة في DB Mongo لاسترداد معلومات المستخدم الكاملة إذا لزم الأمر.

134
00:09:58,350 --> 00:10:02,050
لذا، سترى أننا سنقوم بترميز المعرف

135
00:10:02,050 --> 00:10:05,020
ثم تخزينه في حمولة تلك الرسالة.

136
00:10:05,020 --> 00:10:09,470
يمكنك تخزين معلومات إضافية في حمولة الرسالة إذا كنت بحاجة إليها.

137
00:10:09,470 --> 00:10:11,410
ولكن كلما زادت المعلومات التي قمت بتخزينها هناك،

138
00:10:11,410 --> 00:10:15,720
كلما كان رمز JSON Web Token مناسبًا لي.

139
00:10:15,720 --> 00:10:20,010
لذا، حاول تحديد مقدار المعلومات التي قمت بتخزينها في حمولة

140
00:10:20,010 --> 00:10:22,155
JSON Web Token.

141
00:10:22,155 --> 00:10:27,545
كما سنرى في التمرين، لدينا وحدة عقدة

142
00:10:27,545 --> 00:10:30,875
تمكننا من ترميز وإنشاء رمز ويب JSON،

143
00:10:30,875 --> 00:10:34,395
استنادًا إلى المعلومات التي نريد وضعها في الحمولة.

144
00:10:34,395 --> 00:10:38,735
الآن، عند إنشاء JSON Web Token، يمكنك أيضًا توفير توقيع.

145
00:10:38,735 --> 00:10:44,929
مفتاح سري على جانب الخادم يستخدم لترميز رمز JSON Web Token هذا،

146
00:10:44,929 --> 00:10:51,044
ويتم تضمين هذا السر أيضًا في جزء التوقيع من JSON Web Token.

147
00:10:51,044 --> 00:10:55,232
يتم تضمين التوقيع نفسه في مثل هذه الطريقة أن

148
00:10:55,232 --> 00:10:58,797
هناك أساسيات قبل رأس المشفرة والحمولة،

149
00:10:58,797 --> 00:11:04,750
والتي يتم بعد ذلك ترميز باستخدام سر معين الذي يستخدمه الخادم.

150
00:11:04,750 --> 00:11:08,644
وهذا مشفر في، كما قلت HMAC،

151
00:11:08,644 --> 00:11:14,144
التي أشرنا إليها في أحد الدروس السابقة

152
00:11:14,144 --> 00:11:20,922
واستخدام تجزئة 256 بت، والتي يتم تضمينها في التوقيع.

153
00:11:20,922 --> 00:11:25,118
لذلك، عندما يتم استلام رمز JSON Web Token هذا على جانب

154
00:11:25,118 --> 00:11:30,094
الخادم، وعندما يقوم الخادم بفك تشفير هذا الرمز المميز، فإن الخادم قادر على عبور التحقق

155
00:11:30,094 --> 00:11:34,525
للتأكد من أن JSON Web Token لم يتم العبث به من قبل أي شخص،

156
00:11:34,525 --> 00:11:39,460
بينما يتم تمرير الرمز المميز بين العميل وموقع الخادم.

157
00:11:39,460 --> 00:11:43,020
حتى إذا كنت تعرف أي شيء عن الأمن،

158
00:11:43,020 --> 00:11:47,670
والمتسللين، وهلم جرا، فإنك تفهم لماذا من المهم ترميز الرمز المميز،

159
00:11:47,670 --> 00:11:53,250
والتحقق من صحة الرمز المميز على موقع الخادم.

160
00:11:53,250 --> 00:11:58,640
كما ذكرت، إذا كنت بحاجة إلى التعامل مع رموز JSON Web Tokens في تطبيق العقدة الخاص بك.

161
00:11:58,640 --> 00:12:02,810
هناك وحدة عقدة محددة تسمى وحدة عقدة jsonwebtoken.

162
00:12:02,810 --> 00:12:07,830
تنفذ وحدة العقدة هذه المعايير ذات الصلة JSON Web Token،

163
00:12:07,830 --> 00:12:10,640
ويمكن تضمينها في تطبيق العقدة الخاص بك.

164
00:12:10,640 --> 00:12:15,190
توفر هذه الوحدة نفسها طريقة تسمى علامة والتي تسمح لك بالتوقيع

165
00:12:15,190 --> 00:12:18,910
وإصدار الرمز المميز للعميل من جانب الخادم.

166
00:12:18,910 --> 00:12:21,820
كما أنه يحتوي على طريقة التحقق.

167
00:12:21,820 --> 00:12:27,040
والتي يمكن استخدامها للتحقق من الأصالة أو

168
00:12:27,040 --> 00:12:33,380
لضمان صحة رمز JSON ويب الوارد،

169
00:12:33,380 --> 00:12:38,620
لذلك سنستخدم وحدة JSON Web المميزة، في ممارستنا.

170
00:12:38,620 --> 00:12:42,010
جنبا إلى جنب مع وحدة JSON Web Token،

171
00:12:42,010 --> 00:12:47,450
استخدمنا أيضا وحدة Passport-JWT، وحدة العقدة.

172
00:12:47,450 --> 00:12:54,547
الذي يوفر الاستراتيجيات المستندة إلى jwt لوحدة مصادقة جواز السفر لدينا.

173
00:12:54,547 --> 00:12:59,441
لذلك يوفر هذا استراتيجية جواز سفر للمصادقة باستخدام JSON Web Token.

174
00:12:59,441 --> 00:13:06,153
لذلك يسمح لك هذا بمصادقة نقطة النهاية RESTful باستخدام JWT كطريقة

175
00:13:06,153 --> 00:13:12,240
للتحقق من الصحة، دون الحاجة إلى الخادم لاستخدام الجلسات.

176
00:13:12,240 --> 00:13:17,300
الآن، وحدة جواز السفر JWT،

177
00:13:17,300 --> 00:13:21,710
تدعم طريقة حتى استخراج رمز JWT من

178
00:13:21,710 --> 00:13:26,970
رسالة الطلب الواردة، ومن ثم التحقق من الرمز المميز نيابة عنك.

179
00:13:26,970 --> 00:13:31,470
يستخدم متدرب الوحدة النمطية Passport-JWT، وحدة JSON Web Token

180
00:13:31,470 --> 00:13:34,550
للقيام بالتحقق من هذا JSON Web Token.

181
00:13:34,550 --> 00:13:40,300
يمكن حمل الرمز المميز نفسه في رأس الطلب الوارد،

182
00:13:40,300 --> 00:13:44,350
في الرأس، حتى في رأس المصادقة للطلب الوارد،

183
00:13:44,350 --> 00:13:46,940
وهو ما سنقوم به في التمرين.

184
00:13:46,940 --> 00:13:51,420
يمكن أيضًا حمل الرمز المميز في نص الطلب الوارد، وفي هذه الحالة،

185
00:13:51,420 --> 00:13:54,610
يجب علينا استخراج الرمز المميز من نص الطلب الوارد

186
00:13:54,610 --> 00:13:56,352
ثم الاستفادة منه.

187
00:13:56,352 --> 00:14:01,170
وحدة Passport-JWT، تدعم ذلك أيضًا إذا اخترت

188
00:14:01,170 --> 00:14:06,580
استخدام ذلك كطريقة لتمرير الرمز المميز مرة أخرى من العميل إلى موقع الخادم.

189
00:14:06,580 --> 00:14:11,600
يمكن تضمين JSON Web Token أيضًا في معلمات استعلام URL إذا

190
00:14:11,600 --> 00:14:16,440
اخترت ذلك، ويمكن استخراجها من هناك b Passport-JWT

191
00:14:16,440 --> 00:14:18,370
واستخدامها للمصادقة.

192
00:14:18,370 --> 00:14:22,783
الآن، مع هذا الفهم السريع لـ JSON Web Tokens

193
00:14:22,783 --> 00:14:27,915
وكيف تكون مفيدة، سننتقل إلى التمرين حيث سنستخدم وحدة

194
00:14:27,915 --> 00:14:33,230
Passport-JWT، جنبًا إلى جنب مع وحدة JSON Web Token،

195
00:14:33,230 --> 00:14:38,211
ونقوم بتكوين خادم Express Rest API لاستخدام JSON Web Tokens.

196
00:14:38,211 --> 00:14:41,589
[ موسيقى]