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

2
00:00:04,614 --> 00:00:09,792
Chúng tôi đã phát triển một máy chủ REST API đầy đủ sử dụng Express và

3
00:00:09,792 --> 00:00:12,026
MongoDB như một phần của khóa học này.

4
00:00:12,026 --> 00:00:16,881
Để máy chủ có thể giao tiếp một cách có ý nghĩa với khách hàng của chúng

5
00:00:16,881 --> 00:00:21,892
tôi, chúng tôi sẽ thực hiện một vài điều chỉnh nhỏ để nó trả về đúng loại dữ liệu.

6
00:00:21,892 --> 00:00:26,063
Để thực hiện khách hàng của chúng tôi có thể hoạt động hiệu quả hơn

7
00:00:26,063 --> 00:00:29,370
với dữ liệu được trả về từ phía máy chủ của chúng tôi.

8
00:00:29,370 --> 00:00:30,427
Vì vậy, để làm điều đó, chúng

9
00:00:30,427 --> 00:00:35,724
ta hãy làm việc trên một vài điều chỉnh phía máy chủ của chúng tôi trong bài tập này.

10
00:00:37,478 --> 00:00:43,220
Đi đến máy chủ của chúng tôi trong trình soạn thảo, trước khi chúng tôi bắt đầu làm việc trên máy chủ,

11
00:00:43,220 --> 00:00:48,497
tôi sẽ đề nghị bạn tải xuống tất cả các hình ảnh mà tôi đã cung cấp

12
00:00:48,497 --> 00:00:53,260
dưới dạng tệp zip trong tài nguyên tập thể dục được gọi là images.zip.

13
00:00:53,260 --> 00:00:56,530
Giải nén tập tin và sau đó có được tất cả các hình ảnh từ đó, và

14
00:00:56,530 --> 00:01:03,440
sau đó sao chép những hình ảnh đó vào thư mục hình ảnh công cộng trong máy chủ của chúng tôi.

15
00:01:03,440 --> 00:01:08,980
Vì vậy, bạn thấy rằng ở đây tôi đã sao chép tất cả các hình ảnh vào

16
00:01:08,980 --> 00:01:10,580
thư mục hình ảnh công cộng của tôi ở đây đã.

17
00:01:10,580 --> 00:01:15,120
Bởi vì máy chủ của chúng tôi là một trong đó sẽ phục vụ tất cả những hình ảnh cho

18
00:01:15,120 --> 00:01:17,460
ứng dụng khách hàng của chúng tôi.

19
00:01:17,460 --> 00:01:22,820
Tiếp theo, chúng tôi đi đến cors và điều chỉnh danh sách trắng đó, ở đây.

20
00:01:22,820 --> 00:01:27,919
Vì vậy, đối với ứng dụng khách Angular của chúng tôi, nếu chúng ta bắt đầu nó

21
00:01:27,919 --> 00:01:33,571
với lệnh ng serve, nó chạy tại localhost:4200.

22
00:01:33,571 --> 00:01:36,196
Vì vậy, bất kỳ yêu cầu đến từ

23
00:01:36,196 --> 00:01:40,750
ứng dụng Angular của chúng tôi đến máy chủ sẽ mang nó như là nguồn gốc của họ ở đó.

24
00:01:40,750 --> 00:01:44,710
Vì vậy, đó là lý do tại sao tôi sẽ thêm vào danh sách trắng của tôi, để

25
00:01:44,710 --> 00:01:50,310
bất kỳ vấn đề cors sẽ được giải quyết tự động.

26
00:01:50,310 --> 00:01:54,848
Vì vậy, đi vào tập tin cors.js đó,

27
00:01:54,848 --> 00:01:59,698
trong danh sách trắng của tôi, ở đây, hãy để tôi thêm

28
00:01:59,698 --> 00:02:08,371
vào http://localhost:, 4200.

29
00:02:08,371 --> 00:02:12,503
Và đây là nguồn gốc mà từ đó tất cả máy khách Angular của tôi sẽ được

30
00:02:12,503 --> 00:02:16,690
bắt nguồn yêu cầu đến máy chủ này.

31
00:02:16,690 --> 00:02:22,020
Vì vậy, theo cách đó, cors của tôi sẽ không gây ra vấn đề cho có thể Angular khách hàng.

32
00:02:22,020 --> 00:02:27,760
Tiếp theo, chúng ta cần cập nhật một vài tuyến đường để xử lý

33
00:02:27,760 --> 00:02:32,760
các tham số truy vấn, và cũng có một vài điều chỉnh nhỏ khác.

34
00:02:32,760 --> 00:02:35,905
Hãy để tôi bắt đầu với các tập tin promoRouter.js.

35
00:02:35,905 --> 00:02:39,760
Vì vậy, đó là đơn giản để có được cập nhật.

36
00:02:39,760 --> 00:02:44,790
Vì vậy, đi đến các tập tin promoRouter.js, trong các tập tin Promorouter, cho

37
00:02:44,790 --> 00:02:47,960
yêu cầu nhận được mà chúng tôi nhận được ở đây,

38
00:02:47,960 --> 00:02:52,400
thay vì làm promotions.Find với một JavaScript trống rỗng,

39
00:02:52,400 --> 00:02:57,256
ở đây tôi sẽ cung cấp req.query như là

40
00:02:57,256 --> 00:03:02,470
tham số để khuyến mãi đó.Find ở đây.

41
00:03:02,470 --> 00:03:07,650
Điều tương tự với LeaderRouter cũng, vì vậy hãy để tôi đi đến tập tin leaderRouter.js.

42
00:03:07,650 --> 00:03:09,786
Và trong LeaderRouter cũng,

43
00:03:09,786 --> 00:03:14,642
ở đây nơi bạn tìm thấy Leaders.Find với đối tượng JavaScript rỗng.

44
00:03:14,642 --> 00:03:18,423
Thay vào đó, thay thế bằng req.query

45
00:03:18,423 --> 00:03:21,852
đó, để các tham số truy vấn sẽ được thông qua.

46
00:03:21,852 --> 00:03:26,430
Vì vậy, đây là nơi chúng tôi sẽ vượt qua trong cột đặc trưng

47
00:03:26,430 --> 00:03:29,487
thông qua như tham số truy vấn.

48
00:03:29,487 --> 00:03:34,678
Bây giờ đã điều chỉnh hai, bây giờ chúng ta hãy làm việc trên tuyến đường món ăn,

49
00:03:34,678 --> 00:03:41,090
do đó, đi đến tập tin dishRouter.js, ngay cả trong DishRouter, cập nhật tương tự ở đây.

50
00:03:41,090 --> 00:03:48,920
Vì vậy, đi đến món ăn này.Find trong phương pháp get ở đây, thay đổi đó để req.query.

51
00:03:48,920 --> 00:03:52,987
Vì vậy, với điều này, bản cập nhật DishRouter của tôi đã được hoàn thành.

52
00:03:52,987 --> 00:03:57,664
Vì vậy, bây giờ chúng tôi đã cập nhật Promorouter, ReaderRouter, và D

53
00:03:57,664 --> 00:04:02,784
ishRouter, sau đó chúng tôi sẽ tiếp tục cập nhật rằng FavoriterOuter.

54
00:04:02,784 --> 00:04:07,519
Bây giờ bạn đã thực hiện bộ định tuyến yêu thích như là một phần của

55
00:04:07,519 --> 00:04:09,500
nhiệm vụ thứ tư của bạn.

56
00:04:09,500 --> 00:04:12,306
Bây giờ trong FavoriterOuter, bạn sẽ thấy rằng đối với

57
00:04:12,306 --> 00:04:16,618
FavoriterOuter tôi không cho bạn thấy phần còn lại bởi vì

58
00:04:16,618 --> 00:04:19,437
bạn nên đã thực hiện như một phần của nhiệm vụ của bạn.

59
00:04:19,437 --> 00:04:22,925
Trước tiên hãy để tôi thu hút sự chú ý của bạn đến phương pháp get cho

60
00:04:22,925 --> 00:04:26,422
FavoriterOuter.route (“/:Dishid').

61
00:04:26,422 --> 00:04:31,161
Bây giờ, tôi sẽ sử dụng phương pháp get này để chỉ

62
00:04:31,161 --> 00:04:35,653
kiểm tra để đảm bảo rằng các món ăn cụ thể với

63
00:04:35,653 --> 00:04:40,292
một DisHid đã là một yêu thích cho người sử dụng.

64
00:04:40,292 --> 00:04:44,413
Vì vậy, thay vì chỉ đơn giản là nói GET hoạt động không được hỗ trợ,

65
00:04:44,413 --> 00:04:48,879
tôi chỉ sẽ tận dụng sự hiện diện của hoạt động get này.

66
00:04:48,879 --> 00:04:52,574
Và sau đó chúng ta sẽ nói,

67
00:04:52,574 --> 00:04:56,684
yêu thích.Findone.

68
00:04:56,684 --> 00:04:59,843
Và tôi sẽ nói,

69
00:04:59,843 --> 00:05:04,952
người dùng: req.user.id

70
00:05:04,952 --> 00:05:10,194
Vì vậy, chúng tôi sẽ tìm thấy các mục yêu thích cho người dùng cụ thể đó.

71
00:05:10,194 --> 00:05:20,166
Và sau đó chúng ta sẽ nói, .sau đó, yêu thích.

72
00:05:26,483 --> 00:05:32,913
Và, bắt ((err),

73
00:05:35,757 --> 00:05:40,160
tiếp theo (err)).

74
00:05:40,160 --> 00:05:45,638
Và sau đó tương tự ở đây, chúng tôi sẽ thêm vào lỗi ở đây.

75
00:05:48,689 --> 00:05:50,239
Tiếp theo (err)), ở đây.

76
00:05:50,239 --> 00:05:55,689
Vì vậy, bên trong này.sau đó, khi chúng tôi nhận được yêu thích,

77
00:05:55,689 --> 00:06:00,290
sau đó chúng tôi sẽ kiểm tra, nếu (! mục yêu thích).

78
00:06:00,290 --> 00:06:04,500
Vì vậy, nếu không có mục yêu thích cho người dùng này,

79
00:06:04,500 --> 00:06:08,770
thì rõ ràng là món ăn mà chúng tôi đang kiểm tra không tồn tại.

80
00:06:08,770 --> 00:06:18,604
Vì vậy, chúng tôi sẽ trở lại, res.StatusCode, 200.

81
00:06:22,232 --> 00:06:29,488
SeTheader ('Content-Type

82
00:06:29,488 --> 00:06:34,436
'' ứng dụng/json ').

83
00:06:34,436 --> 00:06:36,237
Và sau đó chúng ta sẽ trở lại,

84
00:06:42,997 --> 00:06:51,490
Nói, “tồn tại”: sai.

85
00:06:51,490 --> 00:06:56,891
Vì vậy, những gì chúng tôi đang xác định ở đây là nếu get được thực hiện

86
00:06:56,891 --> 00:07:02,771
để điểm cuối này với một DisHid, điều này tồn tại cờ ở đây

87
00:07:02,771 --> 00:07:07,826
sẽ được thiết lập thành true nếu món ăn này là một phần của mục yêu thích của tôi.

88
00:07:07,826 --> 00:07:13,008
Nếu món ăn này không phải là một phần của mục yêu thích của tôi, tôi sẽ thiết lập cờ tồn tại để sai.

89
00:07:13,008 --> 00:07:16,687
Vì vậy, ở đây, bạn thấy rằng kể từ khi tôi không có bất kỳ mục yêu thích, vì vậy

90
00:07:16,687 --> 00:07:20,008
tồn tại nên được tự động sai tại thời điểm này.

91
00:07:20,008 --> 00:07:26,780
Vì vậy, chúng tôi sẽ nói “tồn tại”: sai, và sau đó chúng tôi sẽ trả lại các mục yêu thích, ở đây.

92
00:07:28,950 --> 00:07:31,237
Vâng, rõ ràng trong trường hợp này,

93
00:07:31,237 --> 00:07:35,225
các mục yêu thích sẽ là null tại thời điểm này, nếu không.

94
00:07:39,097 --> 00:07:42,779
Vì vậy, có nghĩa là yêu thích không phải là null, vì vậy chúng tôi sẽ nói nếu,

95
00:07:45,218 --> 00:07:52,688
(favorites.dishes .indexof),

96
00:07:52,688 --> 00:07:58,011
vì vậy chúng tôi sẽ tìm kiếm req.params.

97
00:08:00,046 --> 00:08:02,620
Dishid, nên chúng ta sẽ tìm kiếm cái này.

98
00:08:02,620 --> 00:08:09,632
Favorites.dishes.array, để xem nếu món ăn tồn tại trong đó.

99
00:08:09,632 --> 00:08:15,410
Và nếu nó không tồn tại, rõ ràng điều này sẽ trả lại một chỉ số tiêu cực ở đây.

100
00:08:15,410 --> 00:08:20,200
Vì vậy, trong trường hợp đó cũng, tôi sẽ trở lại chính xác giống như ở đây.

101
00:08:20,200 --> 00:08:22,291
Vì vậy, nếu nó trả về một chỉ số âm,

102
00:08:22,291 --> 00:08:26,990
thì điều đó có nghĩa là mặc dù người dùng cụ thể này có một trung tâm yêu thích.

103
00:08:26,990 --> 00:08:31,464
Món ăn đặc biệt này không tồn tại trong danh sách

104
00:08:31,464 --> 00:08:36,987
yêu thích của mình, vì vậy đó là lý do tại sao nó sẽ trở lại tồn tại sai ở đây.

105
00:08:36,987 --> 00:08:45,119
Bây giờ nếu không điều đó có nghĩa là món ăn tồn tại trong danh sách yêu thích.

106
00:08:45,119 --> 00:08:51,352
Vì vậy, trong trường hợp này, tôi sẽ trả lại mã trạng thái 200 tồn tại là đúng.

107
00:08:51,352 --> 00:08:57,144
Vì vậy, theo cách đó khi người dùng thực hiện một hoạt động get vào

108
00:08:57,144 --> 00:09:02,408
điểm kết thúc này với /Favorite/Dishid.

109
00:09:02,408 --> 00:09:07,265
Nơi DisHid được cung cấp như là tham số ở đây.

110
00:09:07,265 --> 00:09:09,821
Là tham số hồ sơ ở đây,

111
00:09:09,821 --> 00:09:15,226
sau đó chúng tôi sẽ kiểm tra xem liệu món ăn đó có tồn tại trong mục yêu thích hay không.

112
00:09:15,226 --> 00:09:19,983
Nếu không có mục yêu thích tồn tại cho người dùng này thì chúng tôi sẽ trả về một sai tồn tại.

113
00:09:19,983 --> 00:09:22,138
Tương tự, nếu các mục yêu thích tồn tại,

114
00:09:22,138 --> 00:09:27,000
nhưng món ăn đặc biệt đó không tồn tại trong mục yêu thích thì nó sẽ trả về một sai.

115
00:09:27,000 --> 00:09:28,705
Nếu không nó sẽ trả lại một sự thật.

116
00:09:28,705 --> 00:09:33,890
Vì vậy, lá cờ tồn tại này có thể được sử dụng bởi khách hàng của tôi

117
00:09:33,890 --> 00:09:41,997
để kiểm tra xem món ăn này là một phần của danh sách các món ăn yêu thích cho người dùng này hay không.

118
00:09:41,997 --> 00:09:48,624
Cuối cùng chúng tôi sẽ cập nhật tệp users.js.

119
00:09:48,624 --> 00:09:53,284
Bây giờ trong tập tin users.js, chúng ta cần phải thêm vào một

120
00:09:53,284 --> 00:09:58,204
lĩnh vực router.options khác ở đây bởi vì

121
00:09:58,204 --> 00:10:03,769
đôi khi một yêu cầu bài đăng như bạn đã thấy với đăng nhập,

122
00:10:03,769 --> 00:10:10,760
chúng tôi sẽ gửi các tùy chọn đầu tiên để kiểm tra, đặc biệt là với xe ô tô, cho

123
00:10:10,760 --> 00:10:16,140
dù yêu cầu bài đăng sẽ được cho phép.

124
00:10:16,140 --> 00:10:23,156
Vì vậy, đó là lý do tại sao họ sẽ kiểm tra xe hơi, xe hơi với các lựa chọn ở đây và sau đó.

125
00:10:26,156 --> 00:10:27,915
Chúng tôi chỉ đơn giản

126
00:10:34,203 --> 00:10:39,938
là trả về một thông điệp trạng thái 200 để đáp lại điều đó.

127
00:10:39,938 --> 00:10:44,624
Vì vậy, đối với bất kỳ điểm cuối dưới người dùng nếu chúng tôi nhận được

128
00:10:44,624 --> 00:10:50,183
các tùy chọn sẽ chỉ đơn giản trả về một trạng thái 200 ở đây.

129
00:10:50,183 --> 00:10:57,417
Bây giờ chức năng Đăng nhập mà chúng tôi đã thực hiện trước đó.

130
00:10:57,417 --> 00:11:02,782
Chúng tôi chỉ đơn giản là thực hiện passport.authenticate ('địa phương') ở đây và

131
00:11:02,782 --> 00:11:06,600
sau đó chúng tôi kiểm tra các giá trị còn lại ở đây.

132
00:11:06,600 --> 00:11:11,006
Bây giờ passport.authenticate này ('địa phương'), nếu người dùng không nhận được

133
00:11:11,006 --> 00:11:15,221
chứng thực, nó chỉ đơn giản là trả về một trái phép trong thư trả lời.

134
00:11:15,221 --> 00:11:18,212
Bây giờ điều đó có thể không phải là rất có ý nghĩa cho

135
00:11:18,212 --> 00:11:21,868
phía khách hàng để hiển thị thông tin này.

136
00:11:21,868 --> 00:11:27,245
Vì vậy, đó là lý do tại sao chúng tôi sẽ tăng cường phương thức đăng nhập bài router này

137
00:11:27,245 --> 00:11:35,158
để xác thực sẽ trả lại thông tin có ý nghĩa hơn ở phần này.

138
00:11:35,158 --> 00:11:39,831
Vì vậy, để làm điều đó, chúng ta sẽ không làm hộ

139
00:11:39,831 --> 00:11:43,120
chiếu chứng thực bên trong đây.

140
00:11:43,120 --> 00:11:47,180
Thay vào đó, chúng tôi sẽ mất, vì vậy hãy để tôi loại bỏ điều đó từ đó,

141
00:11:47,180 --> 00:11:52,410
và sau đó bạn sẽ thấy làm thế nào tôi sẽ cập nhật bài đăng bộ định tuyến ở đây.

142
00:11:52,410 --> 00:11:56,520
Vì vậy, chúng ta sẽ thấy CarsWithOptions.

143
00:11:56,520 --> 00:12:03,806
Và sau đó chúng tôi sẽ bao gồm req, res và tiếp theo ở đây.

144
00:12:03,806 --> 00:12:08,216
Và bên trong req, res, và

145
00:12:08,216 --> 00:12:14,227
tiếp theo ở đây, passport.authenticate,

146
00:12:17,271 --> 00:12:22,035
Chúng tôi sẽ gọi điều này với 'địa phương'.

147
00:12:22,035 --> 00:12:27,041
Bây giờ khi chúng ta gọi điều này với địa phương, nếu một

148
00:12:27,041 --> 00:12:34,607
lỗi xác thực xảy ra passport.authenticate có thể được thực hiện để trả về giá trị lỗi,

149
00:12:34,607 --> 00:12:39,519
và nó cũng sẽ trả lại người dùng nếu không có lỗi.

150
00:12:39,519 --> 00:12:42,283
Và nó có thể tham số được gọi là thông tin,

151
00:12:42,283 --> 00:12:47,643
mà sẽ mang thông tin bổ sung có thể được chuyển trở lại cho người dùng.

152
00:12:47,643 --> 00:12:51,714
Lỗi này sẽ được trả lại khi có lỗi chính hãng xảy ra

153
00:12:51,714 --> 00:12:53,590
trong khả năng xác thực.

154
00:12:53,590 --> 00:12:58,995
Nhưng nếu thông tin người dùng được gửi đến passport.authenticate nhưng

155
00:12:58,995 --> 00:13:03,945
người dùng không tồn tại, thì thông tin đó không được tính là lỗi.

156
00:13:03,945 --> 00:13:07,828
Thay vào đó, nó sẽ được tính là người dùng không tồn tại.

157
00:13:07,828 --> 00:13:12,825
Và thông tin đó được truyền lại trong đối tượng thông tin đi vào.

158
00:13:12,825 --> 00:13:16,793
Vì vậy, lỗi sẽ được trả lại khi có một lỗi chính hãng xảy ra trong quá

159
00:13:16,793 --> 00:13:18,405
trình xác thực.

160
00:13:18,405 --> 00:13:23,995
Nhưng thông tin, chúng sẽ chứa thông tin nếu người dùng không tồn tại và vì vậy

161
00:13:23,995 --> 00:13:30,102
passport.authenticate đang truyền lại một thông báo nói rằng người dùng không

162
00:13:30,102 --> 00:13:35,780
tồn tại hoặc tên người dùng không chính xác hoặc mật khẩu không chính xác.

163
00:13:35,780 --> 00:13:40,415
Và như vậy, để thông tin sẽ được thông qua, trong thông báo thông tin.

164
00:13:40,415 --> 00:13:44,569
Bây giờ, chúng ta sẽ thấy điều này hữu ích như thế nào khi chúng ta nhìn vào phía khách hàng một

165
00:13:44,569 --> 00:13:45,990
chút sau đó.

166
00:13:45,990 --> 00:13:48,070
Vì vậy, trong tình huống này,

167
00:13:49,530 --> 00:13:55,110
chúng tôi sẽ xử lý điều này như sau.

168
00:13:55,110 --> 00:14:00,510
Và không chỉ vậy, khi chúng ta gọi hộ chiếu này xác thực,

169
00:14:00,510 --> 00:14:04,976
chúng ta cũng cần phải vượt qua trong một (req, res,

170
00:14:04,976 --> 00:14:08,550
tiếp theo) như ba dải tham số đó.

171
00:14:08,550 --> 00:14:10,320
Vì vậy, đây là cấu trúc.

172
00:14:10,320 --> 00:14:13,558
Khi bạn cần phải gọi hộ chiếu xác thực,

173
00:14:13,558 --> 00:14:18,798
mong đợi nó để vượt qua bạn trở lại thông tin như thế này như một phương pháp gọi lại ở đây.

174
00:14:18,798 --> 00:14:24,072
Vì vậy, bạn cũng cần phải cung cấp req này, res tiếp theo ngay ở đó quá.

175
00:14:24,072 --> 00:14:25,720
Bây giờ, nếu điều này xảy ra.

176
00:14:25,720 --> 00:14:30,206
Vì vậy, chúng tôi sẽ nói nếu (err).

177
00:14:30,206 --> 00:14:34,163
Vì vậy, nếu có một lỗi xảy ra,

178
00:14:34,163 --> 00:14:39,781
chúng tôi sẽ nói trở lại tiếp theo (err) và sau đó để cho trình

179
00:14:39,781 --> 00:14:45,028
xử lý lỗi của bộ định tuyến nhanh của chúng tôi chăm sóc điều đó.

180
00:14:45,028 --> 00:14:48,365
Bây giờ, chúng ta sẽ xem xét các tình huống khác.

181
00:14:48,365 --> 00:14:53,484
Nếu (! người dùng), vì vậy nếu chúng ta đã đạt đến thời điểm này thì điều đó có nghĩa

182
00:14:53,484 --> 00:14:59,232
là nó không phải là một lỗi xảy ra nhưng thay vào đó có lẽ người dùng không thể được tìm thấy.

183
00:14:59,232 --> 00:15:04,860
Nếu người dùng không được tìm thấy thì người dùng ở đây sẽ được đặt thành null trong trường hợp này.

184
00:15:04,860 --> 00:15:10,088
Vì vậy, trong tình huống đó nếu người dùng không tồn tại,

185
00:15:10,088 --> 00:15:17,068
thì chúng ta cần có khả năng truyền thông tin về phía máy chủ.

186
00:15:17,068 --> 00:15:22,895
Vì vậy, những gì chúng tôi sẽ làm là chúng tôi sẽ vượt qua thông tin này trong định dạng này,

187
00:15:22,895 --> 00:15:26,576
vì vậy tôi sẽ cắt ra từ đây, và

188
00:15:26,576 --> 00:15:30,491
sau đó dán nó vào đây và sau đó chúng tôi sẽ chỉnh sửa như vậy.

189
00:15:30,491 --> 00:15:36,748
Nếu người dùng là null, sau đó chúng tôi sẽ gửi lại một StatusCode

190
00:15:36,748 --> 00:15:41,509
của 401 có nghĩa là trái phép, và

191
00:15:41,509 --> 00:15:47,640
sau đó chúng tôi sẽ gửi lại thông tin thành công, sai.

192
00:15:47,640 --> 00:15:54,340
Và sau đó chúng tôi sẽ không đi lại mã thông báo, chúng tôi sẽ chuyển lại thông báo trạng thái.

193
00:15:54,340 --> 00:16:02,501
Vì vậy, ở đây chúng ta sẽ nói đăng nhập, Không thành công.

194
00:16:02,501 --> 00:16:07,870
Và sau đó thông tin thứ ba sẽ vượt qua thông tin này,

195
00:16:07,870 --> 00:16:13,238
đối tượng mà chúng tôi nhận được ở đây như là phần thứ ba trong

196
00:16:13,238 --> 00:16:19,231
thông điệp trả lời mà chúng tôi gửi lại từ máy chủ của chúng tôi ở đây.

197
00:16:19,231 --> 00:16:22,496
Vì vậy cờ thành công sẽ đặt lại thành false.

198
00:16:22,496 --> 00:16:27,145
Trạng thái sẽ được đặt Đăng nhập không thành công và thông tin lỗi,

199
00:16:27,145 --> 00:16:30,235
được thông qua trong thông tin sẽ được thông qua trở lại.

200
00:16:30,235 --> 00:16:34,788
Bây giờ lưu ý rằng tình huống này sẽ xảy ra nếu tên người dùng và

201
00:16:34,788 --> 00:16:36,789
mật khẩu là không chính xác.

202
00:16:36,789 --> 00:16:42,516
Và vì vậy đây không phải là một lỗi, theo nghĩa lỗi, nhưng thực tế là xác thực

203
00:16:42,516 --> 00:16:47,505
không thể tìm thấy người dùng hoặc mật khẩu của người dùng là không chính xác.

204
00:16:47,505 --> 00:16:51,545
Vì vậy, thông tin đó sẽ được mã hóa vào dòng chảy mà đi vào, và để

205
00:16:51,545 --> 00:16:58,227
tôi sẽ vượt qua trở lại như là một lỗi cho phía khách hàng của tôi.

206
00:16:58,227 --> 00:17:02,633
Nếu không một phần được

207
00:17:02,633 --> 00:17:08,810
xử lý như Req.login.

208
00:17:08,810 --> 00:17:10,700
Vì vậy, nếu điều này là thành

209
00:17:10,700 --> 00:17:16,200
công, passport.authenticate sẽ thêm phương pháp này gọi là req.login cho người dùng.

210
00:17:16,200 --> 00:17:21,400
Vì vậy, tại thời điểm này chúng tôi sẽ chỉ vượt qua trong đối tượng người dùng mà chúng tôi đã thu được.

211
00:17:21,400 --> 00:17:26,398
Vì vậy, ở đây, nếu chúng ta đã đạt đến thời điểm này,

212
00:17:26,398 --> 00:17:32,572
sau đó điều đó có nghĩa là đối tượng người dùng không phải là null và

213
00:17:32,572 --> 00:17:37,717
cũng không có lỗi xảy ra, vì vậy điều đó có nghĩa là

214
00:17:37,717 --> 00:17:43,304
người dùng có thể được đăng nhập và vì vậy chúng tôi sẽ nói err.

215
00:17:43,304 --> 00:17:44,995
Vì vậy, nó sẽ cố gắng đăng nhập vào người dùng.

216
00:17:44,995 --> 00:17:47,231
Vì vậy, chúng tôi sẽ nói nếu sai lầm.

217
00:17:51,210 --> 00:17:58,260
Và sau đó chúng tôi sẽ truyền lại cùng một loại thông tin lỗi mà chúng tôi đã làm ở đây.

218
00:17:59,450 --> 00:18:02,317
Vì vậy, trong trường hợp này, nếu lỗi.

219
00:18:06,077 --> 00:18:11,757
Nếu lỗi, sau đó chúng tôi sẽ chuyển lại mã trạng thái 401 và

220
00:18:11,757 --> 00:18:18,970
chúng tôi sẽ nói thành công là sai và trạng thái là Đăng nhập không thành công.

221
00:18:18,970 --> 00:18:24,359
Và sau đó thông tin lỗi

222
00:18:24,359 --> 00:18:29,539
chúng tôi sẽ vượt qua điều này như thay vì

223
00:18:29,539 --> 00:18:36,810
thông tin chúng tôi sẽ vượt qua trong không thể đăng nhập vào người dùng.

224
00:18:36,810 --> 00:18:42,580
Vì vậy, đó là thông báo sẽ vượt qua ở đây, nếu lỗi xảy ra.

225
00:18:42,580 --> 00:18:46,195
Nếu không, chúng ta sẽ xuống dưới đây.

226
00:18:46,195 --> 00:18:53,157
Và vì vậy tại thời điểm này chúng tôi sẽ có thể tạo ra mã thông báo.

227
00:18:53,157 --> 00:18:57,594
Vì vậy, nếu chúng ta đã đạt đến thời điểm này có nghĩa là người dùng đã

228
00:18:57,594 --> 00:19:01,892
đăng nhập thành công và vì vậy bây giờ chúng ta có thể tạo ra mã thông báo.

229
00:19:01,892 --> 00:19:07,009
Vì vậy, chúng tôi sẽ tạo ra các mã thông báo dựa trên ID người dùng và

230
00:19:07,009 --> 00:19:11,794
sau đó chúng tôi sẽ vượt qua lại mã thông báo đó trở lại cho người dùng.

231
00:19:11,794 --> 00:19:15,462
Vì vậy, ở đây chúng ta sẽ nói var token.

232
00:19:15,462 --> 00:19:22,789
Và sau đó chúng ta có thể nói res.StatusCode = 200, và sau đó res.json (thành công) là đúng,

233
00:19:22,789 --> 00:19:26,999
có nghĩa là người dùng đã đăng nhập thành công.

234
00:19:26,999 --> 00:19:31,842
Và vì vậy trạng thái sẽ là Đăng nhập thành công, và

235
00:19:31,842 --> 00:19:39,900
sau đó là phần thứ ba thay vì lỗi tôi sẽ vượt qua mã thông báo trở lại cho người dùng.

236
00:19:39,900 --> 00:19:45,590
Vì vậy, chúng tôi sẽ nói token, token,

237
00:19:45,590 --> 00:19:50,390
token này mà chúng tôi vừa thu được trước đó, để token sẽ được thông qua

238
00:19:50,390 --> 00:19:54,600
như là tài sản token của thông điệp rip light.

239
00:19:54,600 --> 00:19:57,910
Vì vậy, ở đây, chú ý rằng trục này được đặt thành true.

240
00:19:57,910 --> 00:20:01,890
Vì vậy, có nghĩa là người dùng đã đăng nhập thành công.

241
00:20:01,890 --> 00:20:05,660
Và do đó người dùng có thể tiến hành về phía trước tại thời điểm này.

242
00:20:05,660 --> 00:20:13,667
Và điều này phải được thực hiện bên trong Req.login ở đây.

243
00:20:13,667 --> 00:20:20,640
Vì vậy, tại thời điểm này chúng tôi sẽ đóng Req.login.

244
00:20:20,640 --> 00:20:27,570
Vì vậy, nhận thấy rằng đây là bên trong Req.login này ở đây.

245
00:20:27,570 --> 00:20:30,830
Vì vậy, trong đó chúng ta sẽ vượt qua ba trở lại.

246
00:20:30,830 --> 00:20:33,800
Vì vậy, hãy để tôi chỉ thụt lề ngưỡng ba dòng trong.

247
00:20:35,830 --> 00:20:42,490
Và đó là cách chúng tôi sẽ xử lý người dùng đăng nhập.

248
00:20:42,490 --> 00:20:45,850
Vì vậy, một lần nữa, xem xét lại mã này một lần nữa.

249
00:20:45,850 --> 00:20:47,740
Vì vậy, chúng tôi sẽ làm bài router, nhưng

250
00:20:47,740 --> 00:20:52,490
thay vì làm hộ chiếu xác thực ngay tại đó, chúng tôi sẽ nói req, res,

251
00:20:52,490 --> 00:20:57,970
tiếp theo và sau đó bên trong đây chúng tôi sẽ làm một passport.authenticate cho địa phương.

252
00:20:57,970 --> 00:21:02,930
Và xác thực này sẽ vượt qua trở lại, vì vậy chúng tôi có thể cung cấp một hàm gọi lại cho điều đó.

253
00:21:02,930 --> 00:21:06,810
Và chức năng gọi lại này sẽ trả về lỗi, người dùng hoặc

254
00:21:06,810 --> 00:21:08,370
thông tin ở đây.

255
00:21:08,370 --> 00:21:13,220
Và như vậy, nếu nó làm một lỗi, chúng tôi sẽ chỉ cho phép trình xử lý lỗi thể hiện để

256
00:21:13,220 --> 00:21:14,560
chăm sóc điều đó.

257
00:21:14,560 --> 00:21:20,580
Nếu người dùng là null thì điều đó có nghĩa là người dùng đăng nhập đã không thành công,

258
00:21:20,580 --> 00:21:25,090
và lý do cho điều đó sẽ là trong thông tin để sẽ vượt qua trở lại như là

259
00:21:25,090 --> 00:21:30,660
lỗi thông tin trong thư thoại kế hoạch ở đây.

260
00:21:30,660 --> 00:21:37,190
Nếu chúng ta đi đến thời điểm này thì người dùng được xác minh thành công.

261
00:21:37,190 --> 00:21:38,898
Vì vậy, sau đó chúng tôi sẽ đăng nhập vào người dùng.

262
00:21:38,898 --> 00:21:43,850
Vì vậy, passport.authenticate sẽ thêm vào phương pháp này được gọi là Login vào

263
00:21:43,850 --> 00:21:51,090
thông điệp yêu cầu, vì vậy chúng tôi có thể gọi tên đăng nhập với người dùng và

264
00:21:51,090 --> 00:21:56,760
nếu điều này trả về một lỗi, sau đó chúng tôi sẽ trả lại lỗi ở đây một cách thích hợp.

265
00:21:56,760 --> 00:22:01,400
Nếu không thì chúng tôi đã đạt đến điểm mà người dùng được

266
00:22:01,400 --> 00:22:06,560
xác thực thành công để họ có thể tạo ra mã thông báo web JSON ở đây và trả lại mã

267
00:22:06,560 --> 00:22:12,020
thông báo web JSON cho người dùng để xác nhận rằng người dùng đã đăng nhập thành công.

268
00:22:12,020 --> 00:22:15,190
Vì vậy, đó là tập hợp các bước mà chúng tôi sẽ sử dụng ở đây.

269
00:22:15,190 --> 00:22:19,910
Bây giờ lý do tại sao tôi làm một cách phức tạp hơn để xử lý nó là tôi muốn

270
00:22:19,910 --> 00:22:24,760
phân biệt giữa tình huống mà một lỗi chính hãng xảy ra trong quá

271
00:22:24,760 --> 00:22:30,700
trình ứng dụng, như trái ngược với tình huống mà tên người dùng không hợp lệ,

272
00:22:30,700 --> 00:22:32,830
hoặc mật khẩu không hợp lệ.

273
00:22:32,830 --> 00:22:37,713
Vì vậy, hai trường hợp đó sẽ được xử lý bởi tình huống này mà thông tin sẽ

274
00:22:37,713 --> 00:22:40,129
mang thông tin về cho chúng tôi.

275
00:22:40,129 --> 00:22:44,551
Vì vậy, đó không phải là một lỗi perse nhưng đó là một tình huống mà

276
00:22:44,551 --> 00:22:49,440
người dùng không phải là một người dùng hợp lệ hoặc mật khẩu của người dùng không hợp lệ.

277
00:22:49,440 --> 00:22:54,880
Vì vậy, đó là cách họ sẽ xử lý quá trình đăng nhập của người dùng.

278
00:22:54,880 --> 00:22:59,666
Ngoài ra, tôi sẽ thêm vào một phương pháp nữa ở đây được gọi là,

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

280
00:23:08,832 --> 00:23:12,831
Có thể là trong khi khách hàng đã đăng nhập và

281
00:23:12,831 --> 00:23:18,229
thu được mã thông báo web JSON, đôi khi sau đó, JSON Web Token có thể hết hạn.

282
00:23:18,229 --> 00:23:23,776
Và vì vậy nếu người dùng cố gắng truy cập từ phía khách hàng với một mã thông báo hết hạn

283
00:23:23,776 --> 00:23:29,159
đến máy chủ thì máy chủ sẽ không thể xác thực người dùng.

284
00:23:29,159 --> 00:23:34,024
Vì vậy, trong khoảng thời gian định kỳ, chúng tôi có thể muốn vượt qua kiểm tra để đảm bảo rằng

285
00:23:34,024 --> 00:23:35,733
mã thông báo web JSON vẫn còn hợp lệ.

286
00:23:35,733 --> 00:23:41,180
Vì vậy, đó là lý do tại sao tôi bao gồm một điểm cuối gọi là

287
00:23:41,180 --> 00:23:46,131
CheckJWTToken, vì vậy nếu bạn làm một get để CheckJWTToken.

288
00:23:46,131 --> 00:23:50,927
Bằng cách bao gồm mã thông báo vào tiêu đề ủy quyền,

289
00:23:50,927 --> 00:23:55,926
sau đó cuộc gọi này sẽ trả về một true hoặc false để cho bạn biết

290
00:23:55,926 --> 00:24:00,125
liệu mã thông báo web JSON vẫn còn hợp lệ hay không.

291
00:24:00,125 --> 00:24:04,430
Nếu nó không hợp lệ thì phía khách hàng có thể bắt đầu đăng nhập khác cho

292
00:24:04,430 --> 00:24:09,710
người dùng để có được một mã thông báo web JSON mới, nếu cần.

293
00:24:09,710 --> 00:24:15,470
Vì vậy, để làm điều này, chúng ta sẽ nói cors, CorsWithOptions và,

294
00:24:19,500 --> 00:24:23,760
req, res, ở đây, như mong đợi.

295
00:24:25,510 --> 00:24:28,029
Và ở đây chúng ta sẽ nói,

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

297
00:24:42,356 --> 00:24:49,886
và, {session: false}).

298
00:24:54,050 --> 00:24:59,322
Và điều này sẽ trả lại lỗi, người dùng, thông tin.

299
00:25:03,010 --> 00:25:07,005
Vì vậy, nhớ lại cách chúng tôi sử dụng trình xác thực hộ chiếu trước đó.

300
00:25:07,005 --> 00:25:11,050
Vì vậy, phiên JWT rơi ở đây.

301
00:25:11,050 --> 00:25:14,759
Vì vậy, trước đó ở đây chúng ta nói, passport.authenticate địa phương.

302
00:25:14,759 --> 00:25:17,039
Vì vậy, đây là để xác thực địa phương.

303
00:25:17,039 --> 00:25:21,038
Vì vậy, điều này là để xác thực mã thông báo web JSON.

304
00:25:21,038 --> 00:25:26,303
Vì vậy, khi chúng ta gọi đó, sau đó, kể từ đó sẽ xác minh mã thông báo web JSON,

305
00:25:26,303 --> 00:25:33,820
vì vậy tôi sẽ nói, nếu (err), trở lại tiếp theo (err).

306
00:25:33,820 --> 00:25:38,540
Và sau đó để cho trình xử lý lỗi Express chăm sóc tình huống đó.

307
00:25:38,540 --> 00:25:42,895
Và sau đó chúng ta sẽ nói, nếu (! người dùng),

308
00:25:47,340 --> 00:25:53,395
Nếu người dùng không tồn tại, thì tương tự, khác.

309
00:25:53,395 --> 00:25:58,850
Vì vậy, có nghĩa là nếu đối tượng người dùng được tìm thấy từ mã thông báo web JSON và

310
00:25:58,850 --> 00:26:04,764
sau đó nạp vào req.user, thì điều đó có nghĩa là người dùng là người dùng hợp lệ.

311
00:26:04,764 --> 00:26:06,990
Và như vậy có thể được phép tiến hành về phía trước.

312
00:26:06,990 --> 00:26:13,770
Nếu không, chúng ta sẽ nói rằng người dùng không tồn tại.

313
00:26:13,770 --> 00:26:18,480
Vì vậy, chúng ta cần suy ra rằng mã thông báo web JSON đã hết hạn.

314
00:26:18,480 --> 00:26:24,495
Vì vậy, tại thời điểm này, chúng tôi sẽ gửi một res với mã trạng thái của,

315
00:26:29,070 --> 00:26:31,580
401, do đó trái phép.

316
00:26:33,847 --> 00:26:40,570
SeTheader (, 'Content-Type',

317
00:26:42,865 --> 00:26:45,940
'ứng dụng/json').

318
00:26:45,940 --> 00:26:52,243
Và sau đó chúng tôi sẽ trả lại res,

319
00:26:54,894 --> 00:27:00,970
.json, chúng tôi sẽ nói, {status:,

320
00:27:04,165 --> 00:27:07,131
'JWT không hợp lệ! '.

321
00:27:07,131 --> 00:27:15,242
Và sau đó chúng tôi sẽ trả lại một lá cờ gọi là thành công: sai.

322
00:27:15,242 --> 00:27:20,624
Và sau đó, Chúng tôi sẽ trả lại thông tin mà chúng tôi

323
00:27:20,624 --> 00:27:26,890
có được nếu người dùng không được xác thực là lỗi tại thời điểm này.

324
00:27:30,450 --> 00:27:36,219
Nếu không, điều đó có nghĩa là chúng tôi đạt được điểm này khi người dùng là người dùng hợp lệ.

325
00:27:36,219 --> 00:27:40,921
Vì vậy, trong trường hợp này, hãy để tôi chỉ cần sao chép mã đó ở đây,

326
00:27:40,921 --> 00:27:45,392
chúng tôi sẽ gửi một mã trạng thái của 200, và

327
00:27:45,392 --> 00:27:48,727
sau đó res.json sẽ gửi JWT,

328
00:27:51,140 --> 00:27:55,050
hợp lệ! , và thành công sẽ đúng.

329
00:27:56,550 --> 00:28:03,290
Và phần thứ ba, chúng tôi sẽ gửi thông tin của người dùng.

330
00:28:03,290 --> 00:28:07,776
Vì vậy, theo cách đó, khi điểm cuối này được gọi

331
00:28:07,776 --> 00:28:12,710
với phương thức get, sau đó điều này sẽ xác minh cho dù mã thông báo là hợp lệ hay không.

332
00:28:12,710 --> 00:28:15,580
Nếu mã thông báo là hợp lệ, sau đó bạn sẽ nhận được trả lời này.

333
00:28:15,580 --> 00:28:17,311
Và từ cờ thành công trong bài trả lời,

334
00:28:17,311 --> 00:28:20,050
bạn có thể kiểm tra xem token web JSON có hợp lệ hay không.

335
00:28:20,050 --> 00:28:24,010
Và điều này rất hữu ích ở phía khách hàng.

336
00:28:24,010 --> 00:28:30,012
Bây giờ hộ chiếu này ở đây, passport.authenticate ở đây,

337
00:28:30,012 --> 00:28:37,720
sẽ phải được cung cấp với req và res như hai tham số ở đây.

338
00:28:37,720 --> 00:28:41,320
Đó là cách chúng tôi gọi đó là passport.authenticate.

339
00:28:41,320 --> 00:28:45,060
Chú ý rằng bất cứ khi nào bạn gọi passport.authenticate và

340
00:28:45,060 --> 00:28:49,917
mong đợi chức năng gọi lại này ở đây, bạn cần phải nối thêm điểm này, req,

341
00:28:49,917 --> 00:28:53,973
.res, đó passport.authenticate, và sau đó trở lại đây.

342
00:28:53,973 --> 00:28:57,915
Vì vậy, với điều này, chúng tôi đã cập nhật mọi thứ ở phía máy chủ.

343
00:28:57,915 --> 00:29:01,900
Vì vậy, hãy lưu tất cả các thay đổi ở phía máy chủ.

344
00:29:01,900 --> 00:29:05,400
Vì vậy, bây giờ máy chủ của chúng tôi đã sẵn sàng để

345
00:29:05,400 --> 00:29:10,680
xử lý các yêu cầu đến từ máy khách Angular của chúng tôi.

346
00:29:10,680 --> 00:29:13,120
Với điều này, chúng tôi hoàn thành bài tập này.

347
00:29:13,120 --> 00:29:18,010
Trong bài tập này, chúng tôi đã chuẩn bị máy chủ Express của chúng tôi để

348
00:29:18,010 --> 00:29:22,930
xử lý các yêu cầu đến từ máy khách Angular của chúng tôi.

349
00:29:22,930 --> 00:29:26,890
Trong bài tập tiếp theo, chúng ta sẽ xem xét máy khách Angular chi tiết hơn để

350
00:29:26,890 --> 00:29:32,350
hiểu làm thế nào nó được giao tiếp với máy chủ bổ sung này.

351
00:29:32,350 --> 00:29:37,881
Đây là thời điểm tốt để bạn thực hiện một Git cam kết với thông điệp,

352
00:29:37,881 --> 00:29:40,932
tích hợp client và server.

353
00:29:40,932 --> 00:29:44,825
[ NHẠC]