Bây giờ chúng ta hãy nói chuyện bằng một số ngôn ngữ CORS.
Bây giờ chính xác là gì chia sẻ kết quả chéo nguồn gốc, và tại
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
ứng dụng siêu di động như chúng ta đã làm trong chuyên môn hóa này?
Như bạn đã hiểu, hầu hết các trang web bây giờ kéo dữ liệu từ
nhiều trang web khác nhau để xây dựng một trang web.
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,
chính sách nguồn gốc tương tự đã được áp đặt bởi nhiều trình duyệt.
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
trong bối cảnh của các framework mà chúng tôi đã thảo luận trong
chuyên môn đặc biệt này, như Angular, Ionic, và NativeScript,
nhiều trong số này sẽ liên quan đến kịch bản, mã JavaScript,
mà có thể phải truy cập tài nguyên từ các trang web khác nhau.
Và đây là nơi vấn đề CORS phát triển rất dễ dàng.
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à
bài tập sau.
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.
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
hạn chế làm thế nào một tài liệu hoặc một kịch bản được
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.
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.
Bây giờ rõ ràng, khi bạn có một trang web có liên quan đến kịch bản,
mã JavaScript, có thể truy cập tài nguyên từ một vị trí khác,
mã độc có thể được tiêm vào trang web của bạn và
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.
Bây giờ, đó là lý do nhiều trình duyệt áp đặt chính sách cùng nguồn này.
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?
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.
Đầu tiên, giao thức được sử dụng để truy cập tài nguyên.
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 đó.
Và thứ ba, số cổng mà tại đó tài nguyên đang được truy cập.
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.
Tài nguyên trong trường hợp này có thể là một trang html, một hình ảnh,
dữ liệu JSON được lấy từ một điểm cuối REST API, và nhiều hơn nữa.
Để 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ụ.
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,
www.abc.com, và trong một thư mục xyz, và
page.html đang được tải ở đây.
Trang này có thể liên quan đến các liên kết hoặc thậm chí mã JavaScript có thể
phát hành XMLHttpRequest cho các tài nguyên khác trên trang web.
Bây giờ, trong trường hợp này, nếu chúng ta cố gắng truy cập
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à
từ cùng một trang web nhưng từ một thư mục khác.
Điều này là chấp nhận được, bởi vì nguồn gốc, trong trường hợp này,
giao thức đang được sử dụng và số cổng, vẫn giữ nguyên.
Vì vậy, điều này là chấp nhận được để truy cập tài nguyên này.
Tương tự như vậy trong trường hợp thứ hai, chúng tôi có thể có dưới
nhiều cấp của thư mục con một tài nguyên đang được truy cập.
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.
Nhưng chúng ta hãy nhìn vào ví dụ thứ ba ở đây.
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
giao thức https, mà rõ ràng vi phạm hiệu trưởng cùng nguồn
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.
Vì vậy, điều đó sẽ được coi là một thất bại trong trường hợp này.
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.
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.
Bây giờ, tất cả ba cái này sẽ được đánh dấu là không hợp lệ hoặc
không thể truy cập theo chính sách cùng nguồn đó.
Vì vậy, nếu bạn áp đặt chính sách cùng nguồn để truy cập từ, ví dụ,
XMLHttpRequest của bạn, sau đó ba cuối cùng sẽ không được phép trong trường hợp này.
Nhưng tất nhiên, có rất nhiều tình huống mà nhà thiết kế trang web đó
thực sự có thể lưu trữ tài nguyên trên các trang web khác nhau,
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
để 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 .
Vì vậy, để thích ứng với những tình huống này, việc
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.
Vì vậy, chúng tôi xem xét một yêu cầu là một
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,
hoặc tại một số cổng khác, hoặc với một giao thức khác.
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,
nhưng vì chính sách cùng nguồn,
trình duyệt của bạn sẽ từ chối tải tài nguyên này?
Bây giờ đây là nơi, như tôi đã đề cập,
nhiều trình duyệt sẽ hạn chế các yêu cầu http chéo nguồn gốc,
đặc biệt là những người được khởi xướng bởi XMLHttpRequest hoặc
giao thức Fetch để lấy dữ liệu.
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.
Vì vậy, trong những trường hợp đó, nó có ý nghĩa để áp đặt chính sách cùng nguồn,
nhưng sau đó chúng ta nên có một cách để làm việc xung quanh tình huống mà
một yêu cầu hợp pháp có thể được ban hành.
Đây là nơi mà phương pháp tiếp cận CORS, phương pháp
chia sẻ tài nguyên chéo, đến với sự trợ giúp của chúng tôi.
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
yêu cầu cross-domain, hoặc các yêu cầu cross-origin.
Vì vậy, ở đây trình duyệt và máy chủ
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à
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.
Vì vậy, khi đạt được thỏa thuận,
thì yêu cầu này có thể được trình duyệt của bạn cho phép.
Vì vậy, trình duyệt và máy chủ sẽ tương tác với nhau để
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.
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
vào các thông điệp trả lời HTTP đến từ phía máy chủ.
Các tiêu đề này cho phép các máy chủ để mô tả tập hợp
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.
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
được chấp nhận để được cho phép, mặc dù họ đang vi phạm
chính sách cùng nguồn mà chúng ta đã thấy trước đó.
Vì vậy, trong trường hợp này, chúng tôi có tiêu đề như, ví dụ,
Access-Control-Allow-Origin, Access-Control-Allow-Credentials,
Access-Control-Allow-Headers, Access-Control-Allow-Methods, và
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
đâ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.
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ủ,
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.
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ể
đáp ứng với các trường tiêu đề và
thông tin tiêu đề bao gồm trong thư trả lời đến từ phía máy chủ.
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
nhiều loại.
Chúng tôi có một trong những đầu tiên là yêu cầu cross-site đơn giản.
Trong yêu cầu cross-site đơn giản, bạn có thể đang sử dụng GET hoặc
POST với nội dung yêu cầu.
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
hai ứng dụng/X-WWW-urlencoded,
hoặc multipart/form-data, hoặc văn bản/plain.
Sau đó, nó được coi là một yêu cầu cross-site đơn giản và
không có tiêu đề tùy chỉnh sẽ được cho phép trong trường hợp này.
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,
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.
Vì vậy, ví dụ, đối với các tài nguyên được truy cập rộng rãi, ví dụ,
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 để
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
bất kể nguồn gốc yêu cầu đó có nguồn gốc từ nào.
Vì vậy, trong trường hợp đó, máy chủ của bạn sẽ trả lời cho máy khách,
nói rằng Access-Conrol-Allow-Origin, với ngôi sao ký tự đại diện
đó ở đâ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à
trình duyệt nên cho phép yêu cầu được thực hiện đến máy chủ đó.
Và bây giờ, bạn cũng có thể hạn chế quyền truy cập vào nguồn gốc.
Trong trường hợp này, bạn có thể nói cụ thể rằng nếu nguồn gốc là
một trang web cụ thể, thì có thể chấp nhận được để phục vụ yêu cầu này.
Vì vậy, trình duyệt thấy rằng việc gửi yêu cầu
với trang gốc cụ thể này trong yêu cầu là chấp nhận được và
chúng tôi sẽ cho phép yêu cầu chéo nguồn.
Vì vậy, bạn có thể kiểm soát cách thức nguồn gốc được
chỉ định trong thông điệp yêu cầu đến từ phía khách hàng.
Vì vậy, máy chủ có thể chấp nhận các yêu cầu như vậy.
Một số yêu cầu khác sẽ thuộc thể loại yêu cầu trước.
Trong yêu cầu preflighted, bạn mong đợi rằng trước khi khách hàng
gửi yêu cầu thực tế, khách hàng sẽ gửi một yêu cầu preflight, có
nghĩa là nó liên hệ với máy chủ để lấy
thông tin từ máy chủ trước khi yêu cầu thực tế được ban hành.
Điều này đặc biệt là trường hợp mà bạn vấn đề PUT và DELETE yêu cầu
bởi vì PUT và DELETE yêu cầu có thể gây ra thay đổi ở phía máy chủ.
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à
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.
Trong cách tiếp cận preflight, ý tưởng là máy khách
đầu tiên sẽ gửi một yêu cầu HTTP OPTIONS đến phía máy chủ, và
trả lời thông điệp yêu cầu OPTIONS từ phía máy khách, máy chủ sẽ
đáp ứng với Access-Control-Allow-Headers tương ứng,
Access-Control-Allow-Origin, và
thông tin tiêu đề Access-Control-Allow-Credentials trong câu trả lời cho một thông báo OPTIONS.
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
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.
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
có thể được cho phép và phục vụ bởi phía máy chủ.
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,
nơi bạn mong đợi các khách hàng để bao gồm thông tin đăng nhập trong tiêu đề
của thư yêu cầu.
Vì vậy, các yêu cầu được đi kèm với cookie, ví dụ, để
nhận dạng phiên ở phía máy chủ, hoặc một số loại
thông tin xác thực HTTP trong tiêu đề ủy quyền trong thông báo yêu cầu.
Vì vậy, trong trường hợp này, máy chủ cần phải đáp ứng với
Access-Control-Allow-Credentials: đúng với phía khách hàng.
Vì vậy, trong trường hợp này, máy chủ sẽ đáp ứng với điều này và
sau đó máy khách sẽ được phép gửi
thông tin ủy nhiệm của họ trong yêu cầu đến từ phía máy khách.
Bây giờ, trong trường hợp này, Access-Control-Allow-Origin không được
phép có thẻ hoang dã, ngôi sao, trong tin nhắn trả lời.
Nó dự kiến sẽ xác định rõ ràng nguồn gốc
mà yêu cầu có thể được khởi xướng.
Bây giờ, rõ ràng, chúng ta có thể thực hiện nhiều công việc,
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
chọn để xử lý các câu trả lời liên quan đến CORS từ phía máy chủ.
Nó rất đơn giản, như chúng ta đã thấy trong mã mà chúng tôi đã thực hiện.
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ủ,
nhưng may mắn thay, chúng tôi có một CORS NoDemodule cụ thể
được thiết kế để xử lý loại
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.
Vì vậy, CORS NoDemodule cho phép chúng tôi cấu hình CORS ở phía máy chủ,
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
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ủ
để 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
trình duyệt để đáp ứng thông báo yêu cầu.
Để cài đặt CORS NoDemodule, rõ ràng bạn thấy npm cài đặt cors,
và sau đó cấu hình phần mềm trung gian CORS trong ứng dụng express của bạn.
Bản thân mô-đun CORS cung cấp một cách rất đơn giản để kích hoạt CORS.
Bạn chỉ có thể bao gồm ứng dụng sử dụng CORS với dấu ngoặc trống, và
đ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
Access-Control-All-Origin với ngôi sao thẻ hoang dã cho mỗi yêu cầu đến.
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
đó là nơi chúng tôi có thể chỉ định các tùy chọn bổ sung cho CORS.
Và không chỉ vậy, bạn có thể áp đặt xử lý CORS
khác nhau cho các tuyến đường khác nhau bên trong máy chủ của bạn.
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
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
các tùy chọn cấu hình khác nhau mà CORS NoDemodule hỗ trợ cho chúng tôi.
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ý
bất kỳ yêu cầu cross-origin đến từ phía khách hàng của bạn và
sau đó đáp ứng với thông tin tiêu đề
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ủ.
Với sự hiểu biết nhanh chóng này về CORS,
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.
Nhưng nếu bạn muốn đọc nhiều chi tiết hơn về CORS,
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,
cho phép bạn đọc thêm về chính CORS.
Nhưng từ quan điểm của khóa học này, chúng tôi muốn cấu hình
ứng dụng thể hiện của chúng tôi mà chúng tôi đã phát triển
cho đến nay để xử lý các vấn đề liên quan đến CORS ở phía máy chủ.
Vì vậy, chuyển sang bài tập, chúng tôi sẽ cài đặt mô-đun CORS npm và
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.
[ NHẠC]