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

2
00:00:04,470 --> 00:00:10,326
Máy chủ Express REST API mà chúng tôi thực hiện trong

3
00:00:10,326 --> 00:00:17,750
mô-đun trước đó cho phép bất kỳ người dùng thực hiện bất kỳ thao tác GET hoặc POST hoặc DELETE nào.

4
00:00:17,750 --> 00:00:21,360
Không có kiểm soát ai có thể thực hiện thao tác này.

5
00:00:21,360 --> 00:00:22,350
Vì vậy, có nghĩa là,

6
00:00:22,350 --> 00:00:27,180
nếu bạn chạy một máy chủ như thế, thì bất cứ ai cũng có thể vào máy chủ của bạn và

7
00:00:27,180 --> 00:00:33,420
bắt đầu thao tác các thông tin có trong cơ sở dữ liệu của bạn.

8
00:00:33,420 --> 00:00:36,578
Đây rõ ràng là một tình huống nguy hiểm.

9
00:00:36,578 --> 00:00:40,380
Cách mà máy chủ nên được thực hiện là,

10
00:00:40,380 --> 00:00:44,330
bạn cần phải có một số loại hạn chế về

11
00:00:44,330 --> 00:00:48,660
loại người dùng nào đó sẽ được phép thực hiện loại hoạt động nào.

12
00:00:48,660 --> 00:00:51,090
Vì vậy, có lẽ, bạn sẽ cho phép và

13
00:00:51,090 --> 00:00:54,650
một người dùng được ủy quyền chỉ để thực hiện các thao tác GET.

14
00:00:54,650 --> 00:01:00,040
Vì vậy, ví dụ, nếu bạn muốn một khách có thể xem thông tin

15
00:01:00,040 --> 00:01:04,860
về các món ăn trong nhà hàng của bạn hoặc thực đơn của nhà hàng của bạn và

16
00:01:04,860 --> 00:01:07,250
như vậy, điều đó là hoàn toàn chấp nhận được.

17
00:01:07,250 --> 00:01:11,699
Tuy nhiên, bạn chỉ có thể cho phép quản trị viên vào và

18
00:01:11,699 --> 00:01:17,780
sửa đổi thông tin về món ăn hoặc xóa một món ăn khỏi menu.

19
00:01:17,780 --> 00:01:23,448
Và cũng có thể cập nhật một món ăn hiện có trong menu, hoặc một chương trình khuyến mãi,

20
00:01:23,448 --> 00:01:29,062
hoặc thông tin về các nhà lãnh đạo ở phía máy chủ của bạn.

21
00:01:29,062 --> 00:01:34,810
Bây giờ, bạn cũng có thể có một nhóm người dùng khác sẽ được đăng ký

22
00:01:34,810 --> 00:01:39,980
người dùng, những người có thể được phép lưu một số món ăn của họ như là món ăn yêu thích của họ,

23
00:01:39,980 --> 00:01:44,290
và chỉ có họ mới có thể thao tác danh sách các món ăn yêu thích của họ.

24
00:01:44,290 --> 00:01:47,850
Vì vậy, đó là một mức độ ủy quyền hoặc

25
00:01:47,850 --> 00:01:49,940
xác thực khác mà bạn cần phải thực hiện.

26
00:01:49,940 --> 00:01:53,400
Vì vậy, bạn có các cấp độ khác nhau của người dùng, và

27
00:01:53,400 --> 00:01:57,820
cũng có thể, tùy thuộc vào loại hoạt động mà họ sẽ được phép thực hiện.

28
00:01:57,820 --> 00:02:01,880
Vì vậy, tất cả điều này có nghĩa là bạn cần một số loại bảo mật để được xây dựng

29
00:02:01,880 --> 00:02:03,840
vào phía máy chủ của bạn.

30
00:02:03,840 --> 00:02:07,970
Chúng tôi sẽ xem xét cách chúng tôi có thể xác thực người dùng, và

31
00:02:07,970 --> 00:02:13,110
sau đó quyết định loại người dùng này là gì.

32
00:02:13,110 --> 00:02:15,410
Và sau đó tùy thuộc vào loại người dùng,

33
00:02:15,410 --> 00:02:19,360
bạn có thể cho phép người dùng thực hiện một số loại hoạt động nhất định.

34
00:02:19,360 --> 00:02:24,630
Chúng tôi sẽ bắt đầu với sự hiểu biết cơ bản về điều này, những gì chúng tôi gọi

35
00:02:24,630 --> 00:02:30,860
là Xác thực cơ bản ở phía máy chủ cho

36
00:02:30,860 --> 00:02:36,940
một khách hàng, và sau đó, xây dựng dựa trên đó trong suốt phần còn lại của mô-đun này.

37
00:02:36,940 --> 00:02:42,030
Và sau đó vào cuối mô-đun này, chúng tôi sẽ kết thúc với một cơ chế,

38
00:02:42,030 --> 00:02:46,170
do đó, cho phép người dùng tự đăng ký.

39
00:02:46,170 --> 00:02:50,220
Và, người dùng đã đăng ký có thể thực hiện các thao tác nhất định

40
00:02:50,220 --> 00:02:53,930
mà người dùng chưa đăng ký không thể, v.v.

41
00:02:53,930 --> 00:02:57,320
Vì vậy, chúng tôi sẽ áp đặt các loại điều khiển truy cập

42
00:02:57,320 --> 00:03:01,990
khác nhau cho các hoạt động khác nhau trên phía máy chủ dựa trên loại người dùng.

43
00:03:01,990 --> 00:03:04,930
Vì vậy, điều đó đặt cho bạn quan điểm, hoặc

44
00:03:04,930 --> 00:03:09,830
đúng hơn là ý tưởng về những gì bạn sẽ gặp phải trong mô-đun này.

45
00:03:09,830 --> 00:03:12,450
Hãy bắt đầu với xác thực cơ bản,

46
00:03:12,450 --> 00:03:18,450
cơ chế rất cơ bản sẽ cho phép chúng tôi xác thực người dùng.

47
00:03:19,970 --> 00:03:25,173
Xác thực cơ bản trong HTTP là một cơ chế rất đơn giản

48
00:03:25,173 --> 00:03:28,782
, nó sẽ yêu cầu người dùng cho một tên người dùng và

49
00:03:28,782 --> 00:03:32,720
mật khẩu được gửi kèm theo một yêu cầu.

50
00:03:32,720 --> 00:03:35,180
Và có một cấu trúc cụ thể

51
00:03:35,180 --> 00:03:39,920
về cách thông tin này sẽ được gửi từ khách hàng đến phía máy chủ.

52
00:03:39,920 --> 00:03:45,060
Vì vậy, đây là một vấn đề, xác thực truy cập cơ bản, mà HTTP hỗ trợ,

53
00:03:45,060 --> 00:03:49,860
là một vấn đề mà sẽ cho phép một máy chủ để thách thức một khách hàng, và yêu cầu

54
00:03:49,860 --> 00:03:53,110
tên người dùng và mật khẩu được gửi bởi khách hàng.

55
00:03:53,110 --> 00:03:57,714
Vì vậy, máy chủ có thể thách thức khách hàng để xác thực chính nó bằng cách gõ vào

56
00:03:57,714 --> 00:03:59,140
thông tin này.

57
00:03:59,140 --> 00:04:01,880
Khách hàng cần gửi tên người dùng và

58
00:04:01,880 --> 00:04:05,440
mật khẩu để đáp ứng với thách thức từ phía máy chủ.

59
00:04:05,440 --> 00:04:09,870
Vì vậy, mỗi thông điệp yêu cầu có nguồn gốc từ một khách hàng

60
00:04:09,870 --> 00:04:13,870
nên bao gồm các hình thức mã hóa của tên người dùng và

61
00:04:13,870 --> 00:04:19,700
mật khẩu trong tiêu đề yêu cầu đi từ khách hàng đến phía máy chủ.

62
00:04:19,700 --> 00:04:22,229
Vì vậy, khi máy chủ nhận được yêu cầu,

63
00:04:22,229 --> 00:04:27,009
máy chủ sẽ trích xuất thông tin này từ tiêu đề yêu cầu của máy khách.

64
00:04:27,009 --> 00:04:31,831
Và sau đó, sử dụng nó để xác thực khách hàng trước khi

65
00:04:31,831 --> 00:04:37,390
cho phép truy cập vào các hoạt động khác nhau ở phía máy chủ.

66
00:04:37,390 --> 00:04:40,850
Vì vậy, làm thế nào để xác thực này hoạt động?

67
00:04:40,850 --> 00:04:44,450
Nếu một client gửi một yêu cầu tới server, và

68
00:04:44,450 --> 00:04:50,150
yêu cầu client này không bao gồm sự hình thành ủy quyền, thì server

69
00:04:50,150 --> 00:04:55,160
sẽ thách thức client, họ đang yêu cầu client gửi thông tin này.

70
00:04:55,160 --> 00:04:58,100
Máy chủ thách thức khách hàng bằng cách bao gồm

71
00:04:58,100 --> 00:05:01,900
một tiêu đề vào thư trả lời sắp tới.

72
00:05:01,900 --> 00:05:06,410
Các tiêu đề với các loại như WWW xác thực, và

73
00:05:06,410 --> 00:05:11,843
sau đó là phần thứ hai mà nó xác định các loại là nơi nó sẽ

74
00:05:11,843 --> 00:05:17,500
xác định loại xác thực khách hàng cần phải gửi.

75
00:05:17,500 --> 00:05:21,990
Và chúng tôi sẽ bắt đầu với sự hiểu biết về xác thực cơ bản ở đây.

76
00:05:21,990 --> 00:05:26,400
Và cũng nhận thấy rằng thông báo trả lời sẽ chứa một mã lỗi 401,

77
00:05:27,570 --> 00:05:31,270
đó là trái phép, mà là viết tắt của trái phép.

78
00:05:31,270 --> 00:05:35,470
Vì vậy, khi trả lời trở lại từ phía máy chủ, sau đó khách hàng,

79
00:05:35,470 --> 00:05:41,300
để đáp ứng với trả lời này đến, khách hàng sẽ phải gửi yêu cầu của họ,

80
00:05:41,300 --> 00:05:49,550
bao gồm một trường tiêu đề cụ thể trong thông điệp yêu cầu của ủy quyền loại.

81
00:05:49,550 --> 00:05:55,250
Và trường tiêu đề ủy quyền này sẽ chứa một số thông tin trong đó.

82
00:05:55,250 --> 00:06:00,440
Đối với một xác thực cơ bản, thông tin này sẽ ở dạng,

83
00:06:00,440 --> 00:06:03,900
như từ đầu tiên ở đây, sẽ là cơ bản.

84
00:06:03,900 --> 00:06:11,410
Và sau đó là một không gian ở đây, và tiếp theo là một chuỗi mã hóa Base64 ở đây.

85
00:06:11,410 --> 00:06:15,358
Chuỗi mã hóa Base64 này mã hóa tên người dùng và

86
00:06:15,358 --> 00:06:21,350
mật khẩu trong một định dạng cụ thể, và sau đó bao gồm trong tiêu đề.

87
00:06:21,350 --> 00:06:25,479
Bây giờ bạn đang nói, nếu bạn gửi một thông điệp yêu cầu như thế này,

88
00:06:25,479 --> 00:06:29,397
bao gồm cả điều này, trong tiêu đề, sau đó bất cứ ai ở giữa.

89
00:06:29,397 --> 00:06:33,538
Vì vậy, nếu bạn biết bất cứ điều gì về an ninh và

90
00:06:33,538 --> 00:06:39,927
làm thế nào người đàn ông ở giữa các cuộc tấn công có thể được đưa ra, thì rõ ràng,

91
00:06:39,927 --> 00:06:44,777
điều này có thể được lấy ra bởi một kẻ xâm nhập ở giữa,

92
00:06:44,777 --> 00:06:49,590
và sau đó có thể được sử dụng để giả mạo khách hàng thực sự.

93
00:06:49,590 --> 00:06:52,720
Một lần nữa, chúng ta không nhận được câu hỏi đó vào lúc này.

94
00:06:52,720 --> 00:06:57,470
Khi tôi nói về HTTPS trong mô-đun tiếp theo,

95
00:06:57,470 --> 00:07:00,880
tôi sẽ trở lại để giải quyết vấn đề đó một chút chi tiết hơn.

96
00:07:00,880 --> 00:07:06,060
Nhưng cho thời điểm này, thông tin trong tiêu đề sẽ được gửi qua

97
00:07:07,880 --> 00:07:11,930
mà không được mã hóa trong tiêu đề tại thời điểm này.

98
00:07:11,930 --> 00:07:15,460
Bây giờ, một lý do khác tại sao tôi đang làm điều này là, để chúng tôi thực sự có thể nhìn

99
00:07:15,460 --> 00:07:20,150
vào tiêu đề trực tiếp và sau đó xem thông tin này trong tiêu đề chính nó.

100
00:07:20,150 --> 00:07:25,401
Vì vậy, khi khách hàng gửi yêu cầu này, thì máy chủ sẽ trích xuất

101
00:07:25,401 --> 00:07:30,930
thông tin từ tiêu đề ủy quyền này trong tiêu đề request.

102
00:07:30,930 --> 00:07:35,078
Và sau đó sử dụng thông tin này để xác minh xem đây là

103
00:07:35,078 --> 00:07:37,670
yêu cầu khách hàng được ủy quyền hay không.

104
00:07:37,670 --> 00:07:40,412
Bây giờ tất nhiên câu hỏi tiếp theo của bạn sẽ là,

105
00:07:40,412 --> 00:07:44,490
tiêu đề ủy quyền này chứa chính xác những gì?

106
00:07:44,490 --> 00:07:48,350
Tiêu đề ủy quyền chính nó được xây dựng như sau.

107
00:07:48,350 --> 00:07:52,180
Nếu bạn có tên người dùng và mật khẩu, đây là hai

108
00:07:52,180 --> 00:07:55,730
phần thông tin mà bạn sẽ sử dụng để xác thực một khách hàng.

109
00:07:55,730 --> 00:08:01,330
Vì vậy, tên người dùng và mật khẩu sẽ được nối vào một chuỗi duy nhất

110
00:08:01,330 --> 00:08:06,910
bằng cách nói tên người dùng và dấu hai chấm, và chính mật khẩu.

111
00:08:06,910 --> 00:08:09,860
Vì vậy, chuỗi tên người dùng, dấu hai chấm và

112
00:08:09,860 --> 00:08:16,210
mật khẩu sẽ được nối lại với nhau thành một chuỗi toàn bộ ở đây.

113
00:08:16,210 --> 00:08:22,994
Chuỗi kết quả này mà chúng tôi nhận được ở đây là, mã hóa bằng cách sử dụng mã hóa Base64.

114
00:08:22,994 --> 00:08:27,344
Nếu bạn biết về cách mã hóa được thực hiện cơ bản để mã hóa,

115
00:08:27,344 --> 00:08:32,390
chuyển đổi nó thành một tiêu đề ASCII như thể hiện trong ví dụ này ở đây,

116
00:08:32,390 --> 00:08:36,195
vì vậy đây là không có gì ngoài một chuỗi các tiêu đề ASCII.

117
00:08:36,195 --> 00:08:39,545
Bây giờ nếu bạn không biết nhiều về mã hóa cứng cơ bản, đừng lo lắng về nó,

118
00:08:39,545 --> 00:08:44,325
nó không ảnh hưởng đến sự hiểu biết của bạn về những gì đang xảy ra ở đây anyway.

119
00:08:44,325 --> 00:08:47,090
Vì vậy, Basic64 mã hóa chuỗi, vì vậy

120
00:08:47,090 --> 00:08:51,950
thông tin đặc biệt này được mã hóa thành một chuỗi như thế này, và

121
00:08:51,950 --> 00:08:57,090
sau đó được bao bọc trong tiêu đề yêu cầu đi từ máy khách đến máy chủ.

122
00:08:57,090 --> 00:09:02,143
Tiêu đề yêu cầu chính nó là của ủy quyền loại,

123
00:09:02,143 --> 00:09:07,194
và sau đó theo sau là giá trị thực tế ở đây, mà nói,

124
00:09:07,194 --> 00:09:13,774
cơ bản, và một không gian ở đây, và Base64 mã hóa chuỗi ở đây.

125
00:09:13,774 --> 00:09:20,034
Vì vậy, khi điều này được nhận bởi sever của chúng tôi, máy chủ sẽ trích xuất thông tin này,

126
00:09:20,034 --> 00:09:25,059
và sau đó từ đây, nó sẽ trích xuất tên người dùng và mật khẩu, và

127
00:09:25,059 --> 00:09:31,620
sau đó xác minh xem đó có phù hợp với một người dùng được ủy quyền hay không ở phía máy chủ.

128
00:09:31,620 --> 00:09:36,917
Để giúp bạn hiểu rõ hơn về cách chúng tôi thực sự tổ chức ứng dụng thể hiện

129
00:09:36,917 --> 00:09:42,211
và cách thức xác thực chính nó được thực hiện, như chúng tôi đã học trước đó, các

130
00:09:42,211 --> 00:09:47,520
ứng dụng thể hiện bản thân được tổ chức trong một bộ phần mềm trung gian.

131
00:09:47,520 --> 00:09:51,690
Và cách ứng dụng express hoạt động là phần mềm trung gian

132
00:09:51,690 --> 00:09:55,630
được áp dụng cho yêu cầu và thông điệp phản hồi

133
00:09:55,630 --> 00:10:00,940
theo thứ tự mà nó được khai báo trong ứng dụng express của tôi.

134
00:10:00,940 --> 00:10:05,290
Vì vậy, nếu bạn có một express.use và

135
00:10:05,290 --> 00:10:09,740
sau đó bạn có một trong những đầu tiên nói một máy chủ tĩnh, sau đó,

136
00:10:09,740 --> 00:10:13,220
bạn có một middleware khác, sau đó sau đó, bạn có một middleware khác.

137
00:10:13,220 --> 00:10:18,560
Trình tự trong đó chúng được khai báo trong tệp app.js máy chủ nhanh,

138
00:10:18,560 --> 00:10:23,600
ví dụ, là trình tự chính xác trong đó phần mềm trung gian sẽ được áp dụng.

139
00:10:23,600 --> 00:10:29,124
Vì vậy, một yêu cầu đến từ phía máy chủ như bạn nhớ lại trong

140
00:10:29,124 --> 00:10:34,690
ứng dụng express của bạn, yêu cầu đến được coi là một đối tượng request.

141
00:10:34,690 --> 00:10:39,050
Đối tượng phản hồi là những gì máy chủ thể hiện xây dựng, và

142
00:10:39,050 --> 00:10:43,310
sau đó tiếp theo là cho phép bạn đi vào phần mềm trung gian tiếp theo

143
00:10:43,310 --> 00:10:45,910
mà bạn sẽ được áp dụng, và như vậy.

144
00:10:45,910 --> 00:10:52,400
Vì vậy, một yêu cầu đến như thế này, khi nó đi vào, phần mềm trung gian đầu tiên được áp dụng.

145
00:10:52,400 --> 00:10:56,164
Và sau đó một khi middleware đó đã chuyển đổi cả yêu cầu và

146
00:10:56,164 --> 00:11:00,680
phản hồi, nó chuyển sang phần mềm trung gian tiếp theo, sau đó được áp dụng cho nó.

147
00:11:00,680 --> 00:11:03,940
Ví dụ, chúng tôi thấy rằng chúng tôi áp dụng Morgan đầu tiên,

148
00:11:03,940 --> 00:11:06,930
sau đó chúng tôi áp dụng bộ phân tích cơ thể cho phần mềm trung gian.

149
00:11:06,930 --> 00:11:12,930
Vì vậy, họ phải đã biến đổi các yêu cầu và các đối tượng phản hồi.

150
00:11:12,930 --> 00:11:17,440
Và sau đó, chúng ta có thể bao gồm một middleware xác thực tại chỗ đó.

151
00:11:17,440 --> 00:11:22,260
Các middleware xác thực sẽ xác thực yêu cầu.

152
00:11:22,260 --> 00:11:26,950
Bây giờ, vì vậy nếu bạn đang sử dụng xác thực cơ bản, làm yêu cầu của bạn

153
00:11:26,950 --> 00:11:31,970
phải chứa trong tiêu đề tiêu đề ủy quyền tại chỗ ở đó.

154
00:11:31,970 --> 00:11:36,260
Vì vậy, tiêu đề ủy quyền sẽ được trích xuất bởi các middleware xác thực

155
00:11:36,260 --> 00:11:40,180
và sau đó kiểm tra xem người dùng có được ủy quyền hay không.

156
00:11:40,180 --> 00:11:46,099
Và nếu phần mềm trung gian xác thực phát hiện rằng bạn là người dùng được ủy quyền,

157
00:11:46,099 --> 00:11:50,515
thì bạn sẽ được phép tiến tới bộ phần

158
00:11:50,515 --> 00:11:54,427
mềm trung gian tiếp theo sau bước xác thực.

159
00:11:54,427 --> 00:11:58,510
Và hồ sơ của bạn sẽ được xử lý bởi phần mềm trung gian tiếp theo.

160
00:11:58,510 --> 00:11:59,519
Nhưng mặt khác,

161
00:11:59,519 --> 00:12:04,422
nếu middleware xác thực của bạn quyết định rằng bạn không phải là một người dùng được ủy quyền,

162
00:12:04,422 --> 00:12:09,197
sau đó các middleware xác thực sẽ đưa bạn dọc theo một con đường khác đi.

163
00:12:09,197 --> 00:12:13,975
Và sau đó tạo ra một lỗi, và sau đó gửi lại

164
00:12:13,975 --> 00:12:19,368
một câu trả lời lỗi thích hợp cho phía khách hàng đó và

165
00:12:19,368 --> 00:12:24,010
sẽ được chuyển hướng đến trình xử lý lỗi.

166
00:12:24,010 --> 00:12:28,450
Vì vậy, chuyển hướng này đến xử lý lỗi sẽ được thực hiện bằng cách gọi Next

167
00:12:28,450 --> 00:12:32,490
với lỗi là tham số để tiếp theo ở đây.

168
00:12:32,490 --> 00:12:38,240
Vì vậy, Tiếp theo là chính xác này Tiếp theo mà chúng ta thấy trong tài nguyên yêu cầu Tiếp theo ở đây.

169
00:12:38,240 --> 00:12:42,760
Và như vậy, điều đó sẽ đưa bạn xuống trình xử lý lỗi,

170
00:12:42,760 --> 00:12:48,170
điều này sẽ xử lý lỗi và sau đó gửi lại thông báo lỗi trở lại phía khách hàng,

171
00:12:48,170 --> 00:12:51,820
cho thấy sự thất bại của việc xác thực.

172
00:12:51,820 --> 00:12:56,720
Vì vậy, đây là cách ủy quyền cơ bản điển hình của bạn, hoặc

173
00:12:56,720 --> 00:13:03,435
xác thực cơ bản hoạt động trong ứng dụng phía máy chủ của bạn.

174
00:13:03,435 --> 00:13:08,305
Sau khi hiểu được điều này, chúng ta hãy chuyển sang bài tập nơi chúng tôi

175
00:13:08,305 --> 00:13:13,176
sẽ thực hiện xác thực cơ bản trong ứng dụng của chúng tôi và

176
00:13:13,176 --> 00:13:15,717
xem làm thế nào nó xác thực người dùng.

177
00:13:15,717 --> 00:13:17,952
[ NHẠC]