1
00:00:04,746 --> 00:00:08,050
Bây giờ chúng ta hãy nói chuyện bằng một số ngôn ngữ CORS.

2
00:00:08,050 --> 00:00:11,500
Bây giờ chính xác là gì chia sẻ kết quả chéo nguồn gốc, và tại

3
00:00:11,500 --> 00:00:15,325
sao nó lại có liên quan khi chúng ta nhìn vào các ứng dụng web và các

4
00:00:15,325 --> 00:00:21,010
ứng dụng siêu di động như chúng ta đã làm trong chuyên môn hóa này?

5
00:00:21,010 --> 00:00:25,260
Như bạn đã hiểu, hầu hết các trang web bây giờ kéo dữ liệu từ

6
00:00:25,260 --> 00:00:29,790
nhiều trang web khác nhau để xây dựng một trang web.

7
00:00:29,790 --> 00:00:38,470
Bây giờ, để áp đặt một chính sách nghiêm ngặt về quyền truy cập vào tài nguyên từ các trang web khác nhau,

8
00:00:38,470 --> 00:00:44,220
chính sách nguồn gốc tương tự đã được áp đặt bởi nhiều trình duyệt.

9
00:00:44,220 --> 00:00:49,410
Chúng ta sẽ nói một chút về điều đó một cách chi tiết hơn trong vài slide tiếp theo, nhưng

10
00:00:49,410 --> 00:00:55,950
trong bối cảnh của các framework mà chúng tôi đã thảo luận trong

11
00:00:55,950 --> 00:01:00,640
chuyên môn đặc biệt này, như Angular, Ionic, và NativeScript,

12
00:01:00,640 --> 00:01:05,650
nhiều trong số này sẽ liên quan đến kịch bản, mã JavaScript,

13
00:01:05,650 --> 00:01:11,220
mà có thể phải truy cập tài nguyên từ các trang web khác nhau.

14
00:01:11,220 --> 00:01:16,790
Và đây là nơi vấn đề CORS phát triển rất dễ dàng.

15
00:01:16,790 --> 00:01:22,290
Hãy xem làm thế nào chúng ta sẽ giải quyết vấn đề này chi tiết hơn trong bài giảng này và

16
00:01:22,290 --> 00:01:24,050
bài tập sau.

17
00:01:25,940 --> 00:01:31,446
Tôi đã ám chỉ ngắn gọn về chính sách cùng nguồn mà tôi đã bắt đầu bài giảng này.

18
00:01:31,446 --> 00:01:36,510
Bây giờ, chính sách cùng nguồn là một mô hình bảo mật ứng dụng web

19
00:01:36,510 --> 00:01:40,170
hạn chế làm thế nào một tài liệu hoặc một kịch bản được

20
00:01:40,170 --> 00:01:45,380
nạp từ một nguồn sẽ tương tác với các tài nguyên từ một nguồn khác.

21
00:01:45,380 --> 00:01:50,270
Mục đích của việc này là để cô lập các tài liệu có khả năng độc hại.

22
00:01:50,270 --> 00:01:54,940
Bây giờ rõ ràng, khi bạn có một trang web có liên quan đến kịch bản,

23
00:01:54,940 --> 00:02:00,900
mã JavaScript, có thể truy cập tài nguyên từ một vị trí khác,

24
00:02:00,900 --> 00:02:05,185
mã độc có thể được tiêm vào trang web của bạn và

25
00:02:05,185 --> 00:02:12,800
theo đó truy cập một nguồn gốc khác so với từ nơi trang web của bạn được thu được.

26
00:02:12,800 --> 00:02:17,220
Bây giờ, đó là lý do nhiều trình duyệt áp đặt chính sách cùng nguồn này.

27
00:02:17,220 --> 00:02:22,230
Bây giờ, khi chúng ta nói về cùng nguồn gốc, làm thế nào để chúng ta xác định một nguồn gốc?

28
00:02:22,230 --> 00:02:28,540
Bây giờ trong bối cảnh này, một nguồn gốc cho bất kỳ tài nguyên nào được định nghĩa bởi ba tuples.

29
00:02:28,540 --> 00:02:32,980
Đầu tiên, giao thức được sử dụng để truy cập tài nguyên.

30
00:02:32,980 --> 00:02:39,410
Thứ hai, tên máy chủ lưu trữ của tài nguyên, hoặc tên miền của tài nguyên đó.

31
00:02:39,410 --> 00:02:43,480
Và thứ ba, số cổng mà tại đó tài nguyên đang được truy cập.

32
00:02:43,480 --> 00:02:48,700
Vì vậy, đây là cách chúng tôi xác định nguồn gốc của bất kỳ tài nguyên nào.

33
00:02:48,700 --> 00:02:53,626
Tài nguyên trong trường hợp này có thể là một trang html, một hình ảnh,

34
00:02:53,626 --> 00:03:00,720
dữ liệu JSON được lấy từ một điểm cuối REST API, và nhiều hơn nữa.

35
00:03:00,720 --> 00:03:05,410
Để xây dựng thêm về chính sách cùng nguồn, chúng ta hãy xem một ví dụ.

36
00:03:05,410 --> 00:03:12,315
Giả sử chúng tôi có một trang web được tải vào từ trang web này được liệt kê ở đây,

37
00:03:12,315 --> 00:03:17,330
www.abc.com, và trong một thư mục xyz, và

38
00:03:17,330 --> 00:03:21,210
page.html đang được tải ở đây.

39
00:03:21,210 --> 00:03:26,890
Trang này có thể liên quan đến các liên kết hoặc thậm chí mã JavaScript có thể

40
00:03:26,890 --> 00:03:33,200
phát hành XMLHttpRequest cho các tài nguyên khác trên trang web.

41
00:03:33,200 --> 00:03:38,310
Bây giờ, trong trường hợp này, nếu chúng ta cố gắng truy cập

42
00:03:38,310 --> 00:03:42,690
một URL khác, ví dụ, URL đầu tiên được liệt kê ở đây, mà rõ ràng bạn thấy là

43
00:03:42,690 --> 00:03:47,860
từ cùng một trang web nhưng từ một thư mục khác.

44
00:03:47,860 --> 00:03:51,820
Điều này là chấp nhận được, bởi vì nguồn gốc, trong trường hợp này,

45
00:03:51,820 --> 00:03:55,420
giao thức đang được sử dụng và số cổng, vẫn giữ nguyên.

46
00:03:55,420 --> 00:04:00,660
Vì vậy, điều này là chấp nhận được để truy cập tài nguyên này.

47
00:04:00,660 --> 00:04:05,470
Tương tự như vậy trong trường hợp thứ hai, chúng tôi có thể có dưới

48
00:04:07,040 --> 00:04:10,570
nhiều cấp của thư mục con một tài nguyên đang được truy cập.

49
00:04:10,570 --> 00:04:15,850
Nhưng một lần nữa, vì nguồn gốc của chúng vẫn giữ nguyên, điều này là chấp nhận được.

50
00:04:15,850 --> 00:04:18,260
Nhưng chúng ta hãy nhìn vào ví dụ thứ ba ở đây.

51
00:04:18,260 --> 00:04:23,930
Trong ví dụ này, chúng ta thấy rằng chúng ta đang cố gắng truy cập vào một tài nguyên ở đây với

52
00:04:23,930 --> 00:04:31,230
giao thức https, mà rõ ràng vi phạm hiệu trưởng cùng nguồn

53
00:04:31,230 --> 00:04:35,580
vì chúng ta đang sử dụng một giao thức khác nhau để truy cập vào tài nguyên đó tại thời điểm này.

54
00:04:35,580 --> 00:04:39,030
Vì vậy, điều đó sẽ được coi là một thất bại trong trường hợp này.

55
00:04:39,030 --> 00:04:44,840
Trường hợp thứ tư là nơi chúng tôi đang truy cập một tài nguyên với một số cổng khác nhau.

56
00:04:44,840 --> 00:04:50,300
Và trường hợp thứ năm là nơi chúng tôi đang truy cập vào một tài nguyên tại một máy chủ khác.

57
00:04:50,300 --> 00:04:54,830
Bây giờ, tất cả ba cái này sẽ được đánh dấu là không hợp lệ hoặc

58
00:04:54,830 --> 00:04:58,110
không thể truy cập theo chính sách cùng nguồn đó.

59
00:04:58,110 --> 00:05:02,710
Vì vậy, nếu bạn áp đặt chính sách cùng nguồn để truy cập từ, ví dụ,

60
00:05:02,710 --> 00:05:10,970
XMLHttpRequest của bạn, sau đó ba cuối cùng sẽ không được phép trong trường hợp này.

61
00:05:10,970 --> 00:05:16,270
Nhưng tất nhiên, có rất nhiều tình huống mà nhà thiết kế trang web đó

62
00:05:16,270 --> 00:05:22,510
thực sự có thể lưu trữ tài nguyên trên các trang web khác nhau,

63
00:05:22,510 --> 00:05:27,128
có thể trên các tên miền khác nhau, và vẫn có thể kéo dữ liệu để xây dựng trang web hoặc

64
00:05:27,128 --> 00:05:32,120
để làm cho ứng dụng web chạy hoặc để làm cho các ứng dụng di động kết hợp chạy .

65
00:05:32,120 --> 00:05:38,914
Vì vậy, để thích ứng với những tình huống này, việc

66
00:05:38,914 --> 00:05:44,798
xử lý yêu cầu chéo nguồn gốc là một phương pháp cho phép chúng ta truy cập các tài nguyên này.

67
00:05:44,798 --> 00:05:50,410
Vì vậy, chúng tôi xem xét một yêu cầu là một

68
00:05:50,410 --> 00:05:56,290
yêu cầu chéo nguồn nếu bạn đang cố gắng truy cập một tài nguyên từ một tên miền khác,

69
00:05:56,290 --> 00:06:01,240
hoặc tại một số cổng khác, hoặc với một giao thức khác.

70
00:06:01,240 --> 00:06:06,920
Vì vậy, làm thế nào để chúng ta thích ứng với các tình huống mà đây là một quyền truy cập hợp pháp vào một tài nguyên,

71
00:06:06,920 --> 00:06:08,800
nhưng vì chính sách cùng nguồn,

72
00:06:08,800 --> 00:06:12,930
trình duyệt của bạn sẽ từ chối tải tài nguyên này?

73
00:06:12,930 --> 00:06:15,790
Bây giờ đây là nơi, như tôi đã đề cập,

74
00:06:15,790 --> 00:06:20,220
nhiều trình duyệt sẽ hạn chế các yêu cầu http chéo nguồn gốc,

75
00:06:20,220 --> 00:06:26,420
đặc biệt là những người được khởi xướng bởi XMLHttpRequest hoặc

76
00:06:26,420 --> 00:06:30,570
giao thức Fetch để lấy dữ liệu.

77
00:06:30,570 --> 00:06:36,980
Những điều này có liên quan khi chúng tôi truy cập vào chúng từ bên trong mã JavaScript của chúng tôi.

78
00:06:36,980 --> 00:06:41,950
Vì vậy, trong những trường hợp đó, nó có ý nghĩa để áp đặt chính sách cùng nguồn,

79
00:06:41,950 --> 00:06:46,490
nhưng sau đó chúng ta nên có một cách để làm việc xung quanh tình huống mà

80
00:06:46,490 --> 00:06:49,980
một yêu cầu hợp pháp có thể được ban hành.

81
00:06:49,980 --> 00:06:52,184
Đây là nơi mà phương pháp tiếp cận CORS, phương pháp

82
00:06:52,184 --> 00:06:56,960
chia sẻ tài nguyên chéo, đến với sự trợ giúp của chúng tôi.

83
00:06:56,960 --> 00:07:02,021
Vì vậy, CORS này là một cơ chế cho phép các máy chủ web thực hiện các

84
00:07:02,021 --> 00:07:06,741
yêu cầu cross-domain, hoặc các yêu cầu cross-origin.

85
00:07:06,741 --> 00:07:10,400
Vì vậy, ở đây trình duyệt và máy chủ

86
00:07:10,400 --> 00:07:14,375
từ nơi bạn đang cố gắng để sửa chữa các tài nguyên sẽ tương tác với nhau và

87
00:07:14,375 --> 00:07:20,945
sau đó đi đến một thỏa thuận nói rằng truy cập này là chấp nhận được và cho phép.

88
00:07:20,945 --> 00:07:23,575
Vì vậy, khi đạt được thỏa thuận,

89
00:07:23,575 --> 00:07:29,182
thì yêu cầu này có thể được trình duyệt của bạn cho phép.

90
00:07:29,182 --> 00:07:32,912
Vì vậy, trình duyệt và máy chủ sẽ tương tác với nhau để

91
00:07:32,912 --> 00:07:38,252
xác định xem quyền truy cập này vào tài nguyên này có phải là một tình huống chấp nhận được hay không.

92
00:07:38,252 --> 00:07:43,672
Vì vậy, đây là nơi một tập hợp các tiêu đề HTTP mới được giới thiệu

93
00:07:43,672 --> 00:07:49,010
vào các thông điệp trả lời HTTP đến từ phía máy chủ.

94
00:07:49,010 --> 00:07:54,580
Các tiêu đề này cho phép các máy chủ để mô tả tập hợp

95
00:07:54,580 --> 00:08:01,690
các nguồn gốc được cho phép bởi các máy chủ để được truy cập bởi trình duyệt.

96
00:08:01,690 --> 00:08:06,760
Và lần lượt trình duyệt nhận ra rằng các truy cập tài nguyên này

97
00:08:06,760 --> 00:08:11,405
được chấp nhận để được cho phép, mặc dù họ đang vi phạm

98
00:08:11,405 --> 00:08:16,230
chính sách cùng nguồn mà chúng ta đã thấy trước đó.

99
00:08:16,230 --> 00:08:19,876
Vì vậy, trong trường hợp này, chúng tôi có tiêu đề như, ví dụ,

100
00:08:19,876 --> 00:08:24,821
Access-Control-Allow-Origin, Access-Control-Allow-Credentials,

101
00:08:24,821 --> 00:08:29,780
Access-Control-Allow-Headers, Access-Control-Allow-Methods, và

102
00:08:29,780 --> 00:08:35,330
một vài người khác mà máy chủ sử dụng để thông báo cho trình duyệt, nói rằng

103
00:08:35,330 --> 00:08:41,190
đây là một cách chấp nhận được truy cập tài nguyên từ phía trình duyệt.

104
00:08:41,190 --> 00:08:46,970
Và khi trình duyệt nhìn thấy các thông điệp trả lời đến từ phía máy chủ,

105
00:08:46,970 --> 00:08:52,510
trình duyệt chấp nhận và cho phép yêu cầu chéo nguồn này được thực hiện.

106
00:08:52,510 --> 00:08:56,500
Bây giờ, điều này cũng có nghĩa là máy chủ nên được thiết lập để có thể

107
00:08:56,500 --> 00:09:01,230
đáp ứng với các trường tiêu đề và

108
00:09:01,230 --> 00:09:06,800
thông tin tiêu đề bao gồm trong thư trả lời đến từ phía máy chủ.

109
00:09:06,800 --> 00:09:11,424
Bây giờ, đây là nơi chúng tôi chia tất cả các yêu cầu nguồn gốc chéo thành

110
00:09:11,424 --> 00:09:13,260
nhiều loại.

111
00:09:13,260 --> 00:09:18,495
Chúng tôi có một trong những đầu tiên là yêu cầu cross-site đơn giản.

112
00:09:18,495 --> 00:09:22,780
Trong yêu cầu cross-site đơn giản, bạn có thể đang sử dụng GET hoặc

113
00:09:22,780 --> 00:09:25,410
POST với nội dung yêu cầu.

114
00:09:25,410 --> 00:09:30,180
Nhưng khi bạn đang sử dụng POST, cơ thể yêu cầu của bạn nên chứa một trong

115
00:09:30,180 --> 00:09:34,688
hai ứng dụng/X-WWW-urlencoded,

116
00:09:34,688 --> 00:09:39,305
hoặc multipart/form-data, hoặc văn bản/plain.

117
00:09:39,305 --> 00:09:44,805
Sau đó, nó được coi là một yêu cầu cross-site đơn giản và

118
00:09:44,805 --> 00:09:47,625
không có tiêu đề tùy chỉnh sẽ được cho phép trong trường hợp này.

119
00:09:47,625 --> 00:09:52,955
Vì vậy, trong trường hợp này, nó là chấp nhận cho máy chủ để thông báo cho khách hàng,

120
00:09:52,955 --> 00:09:57,520
nói rằng điều này được cho phép và trình duyệt nên cho phép các yêu cầu như vậy.

121
00:09:57,520 --> 00:10:01,700
Vì vậy, ví dụ, đối với các tài nguyên được truy cập rộng rãi, ví dụ,

122
00:10:01,700 --> 00:10:05,830
nếu bạn thực hiện một yêu cầu GET đến một máy chủ để lấy dữ liệu để

123
00:10:05,830 --> 00:10:10,580
xây dựng giao diện người dùng, thì có thể yêu cầu GET là chấp nhận được

124
00:10:10,580 --> 00:10:14,400
bất kể nguồn gốc yêu cầu đó có nguồn gốc từ nào.

125
00:10:14,400 --> 00:10:17,350
Vì vậy, trong trường hợp đó, máy chủ của bạn sẽ trả lời cho máy khách,

126
00:10:17,350 --> 00:10:23,250
nói rằng Access-Conrol-Allow-Origin, với ngôi sao ký tự đại diện

127
00:10:23,250 --> 00:10:27,830
đó ở đây, nghĩa là bất kỳ nguồn gốc nào bắt nguồn yêu cầu đều được chấp nhận, và

128
00:10:27,830 --> 00:10:33,540
trình duyệt nên cho phép yêu cầu được thực hiện đến máy chủ đó.

129
00:10:33,540 --> 00:10:38,020
Và bây giờ, bạn cũng có thể hạn chế quyền truy cập vào nguồn gốc.

130
00:10:38,020 --> 00:10:44,440
Trong trường hợp này, bạn có thể nói cụ thể rằng nếu nguồn gốc là

131
00:10:44,440 --> 00:10:50,090
một trang web cụ thể, thì có thể chấp nhận được để phục vụ yêu cầu này.

132
00:10:50,090 --> 00:10:55,940
Vì vậy, trình duyệt thấy rằng việc gửi yêu cầu

133
00:10:55,940 --> 00:11:01,230
với trang gốc cụ thể này trong yêu cầu là chấp nhận được và

134
00:11:01,230 --> 00:11:03,830
chúng tôi sẽ cho phép yêu cầu chéo nguồn.

135
00:11:03,830 --> 00:11:08,790
Vì vậy, bạn có thể kiểm soát cách thức nguồn gốc được

136
00:11:08,790 --> 00:11:12,870
chỉ định trong thông điệp yêu cầu đến từ phía khách hàng.

137
00:11:12,870 --> 00:11:17,500
Vì vậy, máy chủ có thể chấp nhận các yêu cầu như vậy.

138
00:11:17,500 --> 00:11:23,094
Một số yêu cầu khác sẽ thuộc thể loại yêu cầu trước.

139
00:11:23,094 --> 00:11:27,750
Trong yêu cầu preflighted, bạn mong đợi rằng trước khi khách hàng

140
00:11:27,750 --> 00:11:32,380
gửi yêu cầu thực tế, khách hàng sẽ gửi một yêu cầu preflight, có

141
00:11:32,380 --> 00:11:37,260
nghĩa là nó liên hệ với máy chủ để lấy

142
00:11:37,260 --> 00:11:41,380
thông tin từ máy chủ trước khi yêu cầu thực tế được ban hành.

143
00:11:41,380 --> 00:11:46,580
Điều này đặc biệt là trường hợp mà bạn vấn đề PUT và DELETE yêu cầu

144
00:11:46,580 --> 00:11:52,160
bởi vì PUT và DELETE yêu cầu có thể gây ra thay đổi ở phía máy chủ.

145
00:11:52,160 --> 00:11:58,100
Và vì vậy bất kỳ phương pháp nào gây ra tác dụng phụ trên dữ liệu của máy chủ, như PUT và

146
00:11:58,100 --> 00:12:03,538
yêu cầu DELETE, được đặc biệt yêu cầu phải làm theo cách tiếp cận preflight.

147
00:12:03,538 --> 00:12:08,276
Trong cách tiếp cận preflight, ý tưởng là máy khách

148
00:12:08,276 --> 00:12:12,919
đầu tiên sẽ gửi một yêu cầu HTTP OPTIONS đến phía máy chủ, và

149
00:12:12,919 --> 00:12:19,174
trả lời thông điệp yêu cầu OPTIONS từ phía máy khách, máy chủ sẽ

150
00:12:19,174 --> 00:12:24,864
đáp ứng với Access-Control-Allow-Headers tương ứng,

151
00:12:24,864 --> 00:12:31,504
Access-Control-Allow-Origin, và

152
00:12:31,504 --> 00:12:36,350
thông tin tiêu đề Access-Control-Allow-Credentials trong câu trả lời cho một thông báo OPTIONS.

153
00:12:36,350 --> 00:12:42,359
Sau đó, khách hàng sẽ quyết định xem nó có thể phát hành yêu cầu chéo nguồn hay

154
00:12:42,359 --> 00:12:48,870
không dựa trên phản hồi đến yêu cầu trước OPTIONS mà khách hàng đã gửi.

155
00:12:48,870 --> 00:12:53,410
Vì vậy, đây là nơi bạn phải trải qua hai bước trước khi yêu cầu của bạn

156
00:12:53,410 --> 00:12:57,205
có thể được cho phép và phục vụ bởi phía máy chủ.

157
00:12:58,340 --> 00:13:03,230
Một loại thứ ba của CORS yêu cầu sẽ là những gì được gọi là ủy nhiệm yêu cầu,

158
00:13:03,230 --> 00:13:07,900
nơi bạn mong đợi các khách hàng để bao gồm thông tin đăng nhập trong tiêu đề

159
00:13:07,900 --> 00:13:09,608
của thư yêu cầu.

160
00:13:09,608 --> 00:13:13,518
Vì vậy, các yêu cầu được đi kèm với cookie, ví dụ, để

161
00:13:13,518 --> 00:13:19,040
nhận dạng phiên ở phía máy chủ, hoặc một số loại

162
00:13:19,040 --> 00:13:24,440
thông tin xác thực HTTP trong tiêu đề ủy quyền trong thông báo yêu cầu.

163
00:13:24,440 --> 00:13:27,843
Vì vậy, trong trường hợp này, máy chủ cần phải đáp ứng với

164
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credentials: đúng với phía khách hàng.

165
00:13:32,460 --> 00:13:37,920
Vì vậy, trong trường hợp này, máy chủ sẽ đáp ứng với điều này và

166
00:13:37,920 --> 00:13:41,070
sau đó máy khách sẽ được phép gửi

167
00:13:41,070 --> 00:13:45,720
thông tin ủy nhiệm của họ trong yêu cầu đến từ phía máy khách.

168
00:13:45,720 --> 00:13:50,430
Bây giờ, trong trường hợp này, Access-Control-Allow-Origin không được

169
00:13:50,430 --> 00:13:56,550
phép có thẻ hoang dã, ngôi sao, trong tin nhắn trả lời.

170
00:13:56,550 --> 00:14:00,770
Nó dự kiến sẽ xác định rõ ràng nguồn gốc

171
00:14:00,770 --> 00:14:03,450
mà yêu cầu có thể được khởi xướng.

172
00:14:04,500 --> 00:14:08,235
Bây giờ, rõ ràng, chúng ta có thể thực hiện nhiều công việc,

173
00:14:08,235 --> 00:14:13,796
những gì chúng ta cần làm ở phía máy chủ, bằng cách thực hiện phần mềm trung gian của riêng chúng ta nếu chúng ta

174
00:14:13,796 --> 00:14:19,260
chọn để xử lý các câu trả lời liên quan đến CORS từ phía máy chủ.

175
00:14:19,260 --> 00:14:23,570
Nó rất đơn giản, như chúng ta đã thấy trong mã mà chúng tôi đã thực hiện.

176
00:14:23,570 --> 00:14:29,140
Tất nhiên, đó là một cách để xử lý các câu trả lời liên quan đến CORS từ phía máy chủ,

177
00:14:29,140 --> 00:14:34,800
nhưng may mắn thay, chúng tôi có một CORS NoDemodule cụ thể

178
00:14:34,800 --> 00:14:40,470
được thiết kế để xử lý loại

179
00:14:40,470 --> 00:14:44,920
công việc này mà máy chủ cần làm để đáp ứng các yêu cầu của CORS.

180
00:14:44,920 --> 00:14:50,790
Vì vậy, CORS NoDemodule cho phép chúng tôi cấu hình CORS ở phía máy chủ,

181
00:14:50,790 --> 00:14:55,810
bao gồm xác định thông tin gốc nơi thông tin đăng nhập sẽ được chấp nhận

182
00:14:55,810 --> 00:15:01,010
và nhiều mảnh khác của thông tin như vậy mà bạn có thể cấu hình máy chủ

183
00:15:01,010 --> 00:15:05,630
để có thể xử lý các câu trả lời liên quan đến CORS mà nó cần phải cung cấp cho vào

184
00:15:05,630 --> 00:15:09,480
trình duyệt để đáp ứng thông báo yêu cầu.

185
00:15:09,480 --> 00:15:15,750
Để cài đặt CORS NoDemodule, rõ ràng bạn thấy npm cài đặt cors,

186
00:15:15,750 --> 00:15:22,280
và sau đó cấu hình phần mềm trung gian CORS trong ứng dụng express của bạn.

187
00:15:23,430 --> 00:15:28,940
Bản thân mô-đun CORS cung cấp một cách rất đơn giản để kích hoạt CORS.

188
00:15:28,940 --> 00:15:35,970
Bạn chỉ có thể bao gồm ứng dụng sử dụng CORS với dấu ngoặc trống, và

189
00:15:35,970 --> 00:15:41,370
điều đó về cơ bản có nghĩa là bạn đang mở máy chủ của bạn, và nó sẽ trả lời với

190
00:15:41,370 --> 00:15:47,180
Access-Control-All-Origin với ngôi sao thẻ hoang dã cho mỗi yêu cầu đến.

191
00:15:47,180 --> 00:15:51,940
Nhưng khi bạn đang cấu hình máy chủ của bạn, bạn có thể muốn kiểm soát nhiều hơn về điều đó, vì vậy

192
00:15:51,940 --> 00:15:57,190
đó là nơi chúng tôi có thể chỉ định các tùy chọn bổ sung cho CORS.

193
00:15:57,190 --> 00:16:02,790
Và không chỉ vậy, bạn có thể áp đặt xử lý CORS

194
00:16:02,790 --> 00:16:06,810
khác nhau cho các tuyến đường khác nhau bên trong máy chủ của bạn.

195
00:16:06,810 --> 00:16:12,320
Vì vậy, như chúng ta sẽ thấy trong bài tập, chúng tôi sẽ áp đặt các yêu cầu CORS khác nhau

196
00:16:12,320 --> 00:16:17,540
trên các tuyến đường khác nhau ở phía máy chủ của chúng tôi, và điều này được cấu hình bằng cách sử dụng

197
00:16:17,540 --> 00:16:22,690
các tùy chọn cấu hình khác nhau mà CORS NoDemodule hỗ trợ cho chúng tôi.

198
00:16:22,690 --> 00:16:28,620
Vì vậy, bằng cách sử dụng CORS NoDemodule, nó là rất dễ dàng để thiết lập máy chủ của bạn để xử lý

199
00:16:28,620 --> 00:16:34,020
bất kỳ yêu cầu cross-origin đến từ phía khách hàng của bạn và

200
00:16:34,020 --> 00:16:39,730
sau đó đáp ứng với thông tin tiêu đề

201
00:16:39,730 --> 00:16:45,310
thích hợp cho phía khách hàng với tiêu đề CORS thích hợp trong thư trả lời từ phía máy chủ.

202
00:16:45,310 --> 00:16:48,450
Với sự hiểu biết nhanh chóng này về CORS,

203
00:16:48,450 --> 00:16:54,730
tôi chắc chắn rằng bạn có nhiều câu hỏi tại thời điểm này hơn là câu trả lời từ bài giảng này.

204
00:16:54,730 --> 00:16:58,960
Nhưng nếu bạn muốn đọc nhiều chi tiết hơn về CORS,

205
00:16:58,960 --> 00:17:04,050
tôi đã cung cấp cho bạn các tài nguyên bổ sung vào cuối bài học này,

206
00:17:04,050 --> 00:17:06,804
cho phép bạn đọc thêm về chính CORS.

207
00:17:06,804 --> 00:17:11,553
Nhưng từ quan điểm của khóa học này, chúng tôi muốn cấu hình

208
00:17:11,553 --> 00:17:15,037
ứng dụng thể hiện của chúng tôi mà chúng tôi đã phát triển

209
00:17:15,037 --> 00:17:19,150
cho đến nay để xử lý các vấn đề liên quan đến CORS ở phía máy chủ.

210
00:17:19,150 --> 00:17:24,941
Vì vậy, chuyển sang bài tập, chúng tôi sẽ cài đặt mô-đun CORS npm và

211
00:17:24,941 --> 00:17:30,236
sau đó cấu hình nó trên các tuyến đường khác nhau trong máy chủ bổ sung của chúng tôi.

212
00:17:30,236 --> 00:17:33,629
[ NHẠC]