[MUSIC]
Máy chủ Express REST API mà chúng tôi thực hiện trong
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.
Không có kiểm soát ai có thể thực hiện thao tác này.
Vì vậy, có nghĩa là,
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à
bắt đầu thao tác các thông tin có trong cơ sở dữ liệu của bạn.
Đây rõ ràng là một tình huống nguy hiểm.
Cách mà máy chủ nên được thực hiện là,
bạn cần phải có một số loại hạn chế về
loại người dùng nào đó sẽ được phép thực hiện loại hoạt động nào.
Vì vậy, có lẽ, bạn sẽ cho phép và
một người dùng được ủy quyền chỉ để thực hiện các thao tác GET.
Vì vậy, ví dụ, nếu bạn muốn một khách có thể xem thông tin
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à
như vậy, điều đó là hoàn toàn chấp nhận được.
Tuy nhiên, bạn chỉ có thể cho phép quản trị viên vào và
sửa đổi thông tin về món ăn hoặc xóa một món ăn khỏi menu.
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,
hoặc thông tin về các nhà lãnh đạo ở phía máy chủ của bạn.
Bây giờ, bạn cũng có thể có một nhóm người dùng khác sẽ được đăng ký
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ọ,
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ọ.
Vì vậy, đó là một mức độ ủy quyền hoặc
xác thực khác mà bạn cần phải thực hiện.
Vì vậy, bạn có các cấp độ khác nhau của người dùng, và
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.
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
vào phía máy chủ của bạn.
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à
sau đó quyết định loại người dùng này là gì.
Và sau đó tùy thuộc vào loại người dùng,
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.
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
là Xác thực cơ bản ở phía máy chủ cho
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.
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ế,
do đó, cho phép người dùng tự đăng ký.
Và, người dùng đã đăng ký có thể thực hiện các thao tác nhất định
mà người dùng chưa đăng ký không thể, v.v.
Vì vậy, chúng tôi sẽ áp đặt các loại điều khiển truy cập
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.
Vì vậy, điều đó đặt cho bạn quan điểm, hoặc
đúng hơn là ý tưởng về những gì bạn sẽ gặp phải trong mô-đun này.
Hãy bắt đầu với xác thực cơ bản,
cơ chế rất cơ bản sẽ cho phép chúng tôi xác thực người dùng.
Xác thực cơ bản trong HTTP là một cơ chế rất đơn giản
, nó sẽ yêu cầu người dùng cho một tên người dùng và
mật khẩu được gửi kèm theo một yêu cầu.
Và có một cấu trúc cụ thể
về cách thông tin này sẽ được gửi từ khách hàng đến phía máy chủ.
Vì vậy, đây là một vấn đề, xác thực truy cập cơ bản, mà HTTP hỗ trợ,
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
tên người dùng và mật khẩu được gửi bởi khách hàng.
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
thông tin này.
Khách hàng cần gửi tên người dùng và
mật khẩu để đáp ứng với thách thức từ phía máy chủ.
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
nên bao gồm các hình thức mã hóa của tên người dùng và
mật khẩu trong tiêu đề yêu cầu đi từ khách hàng đến phía máy chủ.
Vì vậy, khi máy chủ nhận được yêu cầu,
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.
Và sau đó, sử dụng nó để xác thực khách hàng trước khi
cho phép truy cập vào các hoạt động khác nhau ở phía máy chủ.
Vì vậy, làm thế nào để xác thực này hoạt động?
Nếu một client gửi một yêu cầu tới server, và
yêu cầu client này không bao gồm sự hình thành ủy quyền, thì server
sẽ thách thức client, họ đang yêu cầu client gửi thông tin này.
Máy chủ thách thức khách hàng bằng cách bao gồm
một tiêu đề vào thư trả lời sắp tới.
Các tiêu đề với các loại như WWW xác thực, và
sau đó là phần thứ hai mà nó xác định các loại là nơi nó sẽ
xác định loại xác thực khách hàng cần phải gửi.
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.
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,
đó là trái phép, mà là viết tắt của trái phép.
Vì vậy, khi trả lời trở lại từ phía máy chủ, sau đó khách hàng,
để đá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ọ,
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.
Và trường tiêu đề ủy quyền này sẽ chứa một số thông tin trong đó.
Đối với một xác thực cơ bản, thông tin này sẽ ở dạng,
như từ đầu tiên ở đây, sẽ là cơ bản.
Và sau đó là một không gian ở đây, và tiếp theo là một chuỗi mã hóa Base64 ở đây.
Chuỗi mã hóa Base64 này mã hóa tên người dùng và
mật khẩu trong một định dạng cụ thể, và sau đó bao gồm trong tiêu đề.
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,
bao gồm cả điều này, trong tiêu đề, sau đó bất cứ ai ở giữa.
Vì vậy, nếu bạn biết bất cứ điều gì về an ninh và
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,
điều này có thể được lấy ra bởi một kẻ xâm nhập ở giữa,
và sau đó có thể được sử dụng để giả mạo khách hàng thực sự.
Một lần nữa, chúng ta không nhận được câu hỏi đó vào lúc này.
Khi tôi nói về HTTPS trong mô-đun tiếp theo,
tôi sẽ trở lại để giải quyết vấn đề đó một chút chi tiết hơn.
Nhưng cho thời điểm này, thông tin trong tiêu đề sẽ được gửi qua
mà không được mã hóa trong tiêu đề tại thời điểm này.
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
vào tiêu đề trực tiếp và sau đó xem thông tin này trong tiêu đề chính nó.
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
thông tin từ tiêu đề ủy quyền này trong tiêu đề request.
Và sau đó sử dụng thông tin này để xác minh xem đây là
yêu cầu khách hàng được ủy quyền hay không.
Bây giờ tất nhiên câu hỏi tiếp theo của bạn sẽ là,
tiêu đề ủy quyền này chứa chính xác những gì?
Tiêu đề ủy quyền chính nó được xây dựng như sau.
Nếu bạn có tên người dùng và mật khẩu, đây là hai
phần thông tin mà bạn sẽ sử dụng để xác thực một khách hàng.
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
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.
Vì vậy, chuỗi tên người dùng, dấu hai chấm và
mật khẩu sẽ được nối lại với nhau thành một chuỗi toàn bộ ở đây.
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.
Nếu bạn biết về cách mã hóa được thực hiện cơ bản để mã hóa,
chuyển đổi nó thành một tiêu đề ASCII như thể hiện trong ví dụ này ở đây,
vì vậy đây là không có gì ngoài một chuỗi các tiêu đề ASCII.
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ó,
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.
Vì vậy, Basic64 mã hóa chuỗi, vì vậy
thông tin đặc biệt này được mã hóa thành một chuỗi như thế này, và
sau đó được bao bọc trong tiêu đề yêu cầu đi từ máy khách đến máy chủ.
Tiêu đề yêu cầu chính nó là của ủy quyền loại,
và sau đó theo sau là giá trị thực tế ở đây, mà nói,
cơ bản, và một không gian ở đây, và Base64 mã hóa chuỗi ở đây.
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,
và sau đó từ đây, nó sẽ trích xuất tên người dùng và mật khẩu, và
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ủ.
Để 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
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
ứng dụng thể hiện bản thân được tổ chức trong một bộ phần mềm trung gian.
Và cách ứng dụng express hoạt động là phần mềm trung gian
được áp dụng cho yêu cầu và thông điệp phản hồi
theo thứ tự mà nó được khai báo trong ứng dụng express của tôi.
Vì vậy, nếu bạn có một express.use và
sau đó bạn có một trong những đầu tiên nói một máy chủ tĩnh, sau đó,
bạn có một middleware khác, sau đó sau đó, bạn có một middleware khác.
Trình tự trong đó chúng được khai báo trong tệp app.js máy chủ nhanh,
ví dụ, là trình tự chính xác trong đó phần mềm trung gian sẽ được áp dụng.
Vì vậy, một yêu cầu đến từ phía máy chủ như bạn nhớ lại trong
ứng dụng express của bạn, yêu cầu đến được coi là một đối tượng request.
Đối tượng phản hồi là những gì máy chủ thể hiện xây dựng, và
sau đó tiếp theo là cho phép bạn đi vào phần mềm trung gian tiếp theo
mà bạn sẽ được áp dụng, và như vậy.
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.
Và sau đó một khi middleware đó đã chuyển đổi cả yêu cầu và
phản hồi, nó chuyển sang phần mềm trung gian tiếp theo, sau đó được áp dụng cho nó.
Ví dụ, chúng tôi thấy rằng chúng tôi áp dụng Morgan đầu tiên,
sau đó chúng tôi áp dụng bộ phân tích cơ thể cho phần mềm trung gian.
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.
Và sau đó, chúng ta có thể bao gồm một middleware xác thực tại chỗ đó.
Các middleware xác thực sẽ xác thực yêu cầu.
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
phải chứa trong tiêu đề tiêu đề ủy quyền tại chỗ ở đó.
Vì vậy, tiêu đề ủy quyền sẽ được trích xuất bởi các middleware xác thực
và sau đó kiểm tra xem người dùng có được ủy quyền hay không.
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,
thì bạn sẽ được phép tiến tới bộ phần
mềm trung gian tiếp theo sau bước xác thực.
Và hồ sơ của bạn sẽ được xử lý bởi phần mềm trung gian tiếp theo.
Nhưng mặt khác,
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,
sau đó các middleware xác thực sẽ đưa bạn dọc theo một con đường khác đi.
Và sau đó tạo ra một lỗi, và sau đó gửi lại
một câu trả lời lỗi thích hợp cho phía khách hàng đó và
sẽ được chuyển hướng đến trình xử lý lỗi.
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
với lỗi là tham số để tiếp theo ở đây.
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.
Và như vậy, điều đó sẽ đưa bạn xuống trình xử lý lỗi,
đ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,
cho thấy sự thất bại của việc xác thực.
Vì vậy, đây là cách ủy quyền cơ bản điển hình của bạn, hoặc
xác thực cơ bản hoạt động trong ứng dụng phía máy chủ của bạn.
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
sẽ thực hiện xác thực cơ bản trong ứng dụng của chúng tôi và
xem làm thế nào nó xác thực người dùng.
[ NHẠC]