Bây giờ chúng tôi đã hiểu được xác thực dựa trên mã thông báo bằng cách sử dụng Token Web JSON,
và cũng hiểu được những lợi thế của việc sử dụng cách tiếp cận này.
Thực tế là chúng tôi đang xây dựng một máy chủ dựa trên Rest API,
trong khóa học này có nghĩa
là xác thực dựa trên JSON Web Token là phù hợp nhất cho máy chủ này mà chúng tôi đang xây dựng.
Vì vậy, chúng ta hãy cập nhật máy chủ API Rest của chúng tôi để sử dụng JSON Web Tokens trong bài tập này.
Để bắt đầu cập nhật máy chủ tại thiết bị đầu cuối
của bạn, trước tiên hãy cài đặt JSON Web Token và mô-đun JWT Node hộ chiếu.
Vì vậy, tại dấu nhắc nhập npm, cài đặt,
hộ chiếu JWT JSON Web Token và trừ đi lưu.
Như bạn có thể thấy, tôi đang sử dụng JSON Web Token 8.3.0 và hộ chiếu JWT 4.0.0 trong khóa học này.
Bây giờ chúng tôi đã hoàn thành quá trình cài đặt chúng ta hãy tiếp tục và cập nhật máy chủ nhanh của chúng tôi.
Đi bây giờ để mã của chúng tôi, chúng
ta hãy thêm vào một tập tin có tên
conflict.js trong thư mục gốc của dự án của chúng tôi.
Bây giờ, tập tin conflict.js này tôi sẽ sử dụng nó
để lưu trữ một số thông tin cấu hình cho máy chủ của chúng tôi.
Bây giờ, đây là một cách tập trung tất cả các cấu hình cho máy chủ của chúng tôi.
Trong tập tin conflict.js này,
cho phép tôi xuất một đối tượng JSON ở đây.
Vì vậy, chúng tôi sẽ nói, SecretKey,
và đây là nơi
tôi sẽ chỉ định khóa bí mật mà tôi sẽ được sử dụng để ký JSON Web Token của tôi,
và cũng cho phép tôi chỉ định một URL Mongo ở đây,
đó sẽ là URL cho
máy chủ MongoDB của tôi localhost 27017.
Một khi chúng tôi đã hoàn thành điều
đó, sau đó chúng tôi sẽ đi đến tập tin authenticate.js,
và trong tập tin authenticate.js chúng tôi
bây giờ sẽ tạo ra chiến lược JWT.
Đây là chiến lược mã thông báo web JSON được cung cấp bởi
mô-đun nút JWT hộ chiếu của chúng tôi mà chúng tôi vừa bao gồm và vì vậy chúng tôi sẽ nói,
hào phóng chiến lược hộ chiếu generativity.strategy.
Điều này sẽ cung cấp cho chúng tôi
một chiến lược dựa trên JSON Web Token để cấu hình mô-đun hộ chiếu của chúng tôi,
sau đó trích xuất JWT, mà tôi
cũng sẽ nhận được từ hộ chiếu JWT.
Chúng tôi sẽ yêu cầu hộ chiếu JWT,
sau đó chúng tôi sẽ nói “Extract JWT.”
Sau đó, chúng ta hãy
nhập mô-đun JSON Web Token
mà chúng tôi vừa cài đặt.
Một khi chúng tôi đã nhập khẩu những điều này, chúng
ta hãy tiếp tục và bắt đầu cấu hình một vài điều.
Cùng với những điều này, hãy để tôi nhập cấu hình mà tôi đã
tạo ra các tập tin config.js mà tôi vừa thêm vào dự án của tôi.
Một khi tôi hoàn thành điều này sau đó cho phép tôi đi trước và
giới thiệu một vài chức năng bổ sung mà tôi sẽ xuất khẩu từ đây.
Chúng ta sẽ nói, Exports.getToken,
chức năng này khi cung cấp với một tham số mà tôi sẽ chỉ đơn giản gọi là người dùng,
đó sẽ là một đối tượng JSON,
điều này sẽ tạo ra mã thông báo và cung cấp cho chúng tôi.
Để tạo mã thông báo, chúng tôi sẽ sử dụng mô-đun jsonwebtoken mà chúng tôi vừa nhập khẩu.
Vì vậy, ở đây chúng ta sẽ nói trở lại JWT.Sign,
điều này giúp chúng ta tạo ra JSON Web Token và do đó bên trong nó sẽ
cho phép tôi cung cấp tải trọng và
tải trọng ở đây đi kèm như tham số ở đây được gọi là người dùng,
và sau đó tham số thứ hai là
bí mật hoặc khóa riêng mà tôi nhận được từ cấu hình. khóa bí mật,
mà tôi vừa cấu hình một chút trước đó.
Chúng tôi có thể cung cấp các tùy chọn bổ sung ở đây.
Một lựa chọn mà tôi sẽ cung cấp cho điều này là-.
Được rồi, để tôi đi đến dòng tiếp theo ở đây,
tùy chọn mà tôi sẽ cung cấp là ExpiResin.
ExpiResin sẽ cho bạn biết jsonwebtoken sẽ có
giá trị bao lâu vì vậy trong trường hợp này tôi nói 3,600 nghĩa là 3,600 giây hoặc khoảng một giờ.
Một giờ sau, bạn sẽ phải gia hạn jsonwebtoken.
Một giờ là đủ dài để chúng tôi có thể kiểm tra ứng dụng của chúng tôi.
Bạn có thể đặt điều này lâu hơn nếu bạn chọn.
Trong một ứng dụng thực sự, bạn có thể đặt điều này là một giá trị lâu hơn nhiều có thể
một vài ngày và mong đợi người dùng để xác thực lại mình mỗi vài ngày.
Bây giờ, chúng tôi cũng sẽ cấu hình
chiến lược dựa trên jsonwebtoken cho ứng dụng hộ chiếu của chúng tôi.
Vì vậy, hãy để tôi khai báo một biến được gọi là opt,
đó là không có gì ngoài các tùy chọn mà tôi sẽ chỉ định cho chiến lược dựa trên JWT của tôi.
Vì vậy, chúng tôi sẽ nói opt JWTFromRequest.
Bây giờ tùy chọn này xác
định cách jsonwebtoken nên được trích xuất từ thông điệp yêu cầu đến.
Đây là nơi chúng tôi sẽ sử dụng chiết xuất JWT.
Điều này trích xuất JWT hỗ trợ các phương pháp khác nhau
để trích xuất thông tin từ tiêu đề.
Nó sẽ nói từ AuthHeader từ AuthHeader như mã thông báo mang,
từ tiêu đề mà lược đồ và vân vân.
Nếu bạn đọc tài liệu, nó sẽ cho
bạn biết nhiều cách khác nhau để trích xuất jsonwebtoken.
Bạn có thể vượt qua mã thông báo trong nội dung
của thông báo yêu cầu đến và sau đó bạn có thể trích xuất nó từ đó,
bạn cũng có thể sử dụng trình trích xuất tùy chỉnh và vân vân.
Trong khóa học này, tôi sẽ sử dụng phương pháp đơn giản nhất được gọi là
từ tiêu đề xác thực như một mã thông báo mang.
Chúng tôi đã quen
thuộc với Tiêu đề xác thực bởi vì chúng tôi đã sử dụng nó với
xác thực cơ bản và xác thực dựa trên cookie trước đó.
Vì vậy, tôi chỉ sẽ sử dụng
cùng một lĩnh vực tiêu đề trong thông điệp yêu cầu để thực hiện jsonwebtoken.
Vì vậy, tôi sẽ nói opt như người mang mã thông báo jsonwebtoken.
Tiếp theo chúng ta sẽ nói opts.SecretorKey,
đây là tham số thứ hai giúp tôi
cung cấp khóa bí mật mà tôi sẽ sử dụng trong chiến lược của tôi cho đăng nhập.
Vì vậy, đó là tùy chọn khác mà tôi sẽ chỉ định ở đây.
Một khi tôi xác định hai,
hãy để tôi xuất khẩu chiến lược hộ chiếu
mà tôi sẽ cấu hình ở đây vì vậy chúng tôi sẽ nói ExportJWTPassport,
sau đó chúng tôi sẽ nói passport.use.
Nhớ lại cách bạn chỉ định chiến lược địa phương trước đó.
Ở đây chúng ta đang xác định chiến lược dựa trên JWT,
sau đó chúng ta sẽ tạo ra một chiến lược JWT mới,
nhớ lại rằng chúng ta vừa nhập khẩu chiến lược JWT
ở đây đó là những gì chúng ta sẽ sử dụng để tạo ra một chiến lược mới.
Chiến lược JWT này có
đối tượng tùy chọn mà tôi vừa tạo ra như là tham số đầu tiên.
Các tùy chọn chiến lược và thứ hai là chức năng xác minh mà tôi cần phải cung cấp,
và do đó, chức năng xác minh tôi sẽ cung cấp nó trong dòng tiếp theo ở đây,
chúng ta sẽ nói FunctionJWT_Payload.
Xong rồi. Vì vậy, khi chức năng này được gọi,
thực hiện là gọi lại được cung cấp bởi hộ chiếu.
Vì vậy, bất cứ khi nào bạn có hộ chiếu mà bạn đang cấu hình với một chiến lược mới,
bạn cần phải cung cấp các tham số thứ hai được thực hiện.
Thông qua tham số đã thực hiện này,
bạn sẽ được chuyển trở lại thông tin cho hộ chiếu mà sau đó nó sẽ
sử dụng để tải mọi thứ vào thông điệp yêu cầu.
Vì vậy, khi hộ chiếu phân tích thư yêu cầu,
nó sẽ sử dụng chiến lược và sau đó trích xuất thông tin,
và sau đó tải nó vào thông điệp yêu cầu của chúng tôi.
Vì vậy, kể từ khi điều này xảy ra là một chức năng,
tôi sẽ chỉ sử dụng một chức năng mũi tên ở đây,
tôi đã nhận được thích các chức năng mũi tên.
Vì vậy, hãy để tôi tạo ra rằng như là một hàm mũi tên ở đây,
và bên trong của chức năng này,
chúng ta sẽ được xác định các chức năng.
Vì vậy, chúng ta làm gì bên trong chức năng?
Hãy để tôi làm một console.log của
JWT trọng tải và sau đó
cho phép tôi chỉ cần đăng xuất các tùy chọn đến ở đây,
các JWT trọng tải Tùy chọn đến đây,
để bạn có thể xem những gì là bên trong trọng tải JWT.
Sau đó, chúng tôi sẽ tìm kiếm một người dùng bằng cách nói user.findone,
và sau đó tôi biết rằng trong jwt.payload,
có một lĩnh vực ID đi kèm.
Vì vậy, đó là những gì tôi sẽ được gán là lĩnh vực ID ở đây.
Vì vậy, tôi sẽ nói, user.Findone và thứ hai
là một chức năng gọi lại.
Như bạn nhận ra, người dùng này Mongoose phương pháp và bạn cố gắng tìm.
Vì vậy, chúng tôi sẽ nói nếu sai lầm sau đó, trở lại xong.
Chuyện này đã làm gì? Điều này thực hiện là gọi lại
hộ chiếu sẽ vượt qua vào chiến lược của bạn ở đây.
Vì vậy, chúng ta sẽ được gọi là chức năng thực hiện này.
Điều này được thực hiện trong hộ chiếu có ba thông số.
Vì vậy, bạn có thể thấy ba mẩu thông tin này thực hiện mong đợi nó nói, lỗi: bất kỳ.
Vì vậy, nếu bạn có một lỗi, bạn sẽ vượt qua nó như là tham số đầu tiên.
Tham số thứ hai, người dùng? ,
Nếu một người dùng tồn tại,
sau đó giá trị người dùng sẽ được thông qua và sau đó nếu có thông tin? :, bất kỳ.
Vì vậy, hai là các tham số tùy chọn và vì vậy,
nếu bạn vượt qua bất kỳ thông tin nào,
thì điều đó sẽ được sử dụng trong ứng dụng.
Nếu tôi vượt qua sai là tham số thứ hai,
thì điều đó có nghĩa là người dùng không tồn tại hoặc đó.
Vì vậy, nó sẽ giải thích rằng người dùng không tồn tại.
Vì vậy, tôi có thể nói, sai,
sai, bởi vì đây là một lỗi.
Vì vậy, tôi sẽ không đi qua một giá trị người dùng ở đó,
tôi chỉ đi qua sai.
Ở đó, tiếp theo,
chúng ta có thể nói, nếu không (người dùng).
Vì vậy, nếu người dùng không phải là null,
chúng ta sẽ nói return done (null).
Không có lỗi vì vậy, tham số đầu tiên sẽ là
null và tham số thứ hai là người dùng,
nhưng chúng tôi chỉ nhận được từ MongoDB.
Nếu không, chúng tôi sẽ trở lại
thực hiện với null, false.
Vì vậy, trong trường hợp cuối cùng,
chúng tôi không thể tìm thấy người dùng,
vì vậy chúng tôi sẽ đi qua sai.
Vì vậy, chúng ta sẽ xử lý nó như thế này.
Nếu bạn muốn, bạn có thể tạo một tài khoản người dùng mới tại thời điểm này
nhưng tôi sẽ giữ cho điều này đơn giản chỉ để nó dễ dàng cho chúng tôi để hiểu.
Vì vậy, chúng tôi sẽ chỉ nói, null, false. Đó là sáu.
Vì vậy, đây là chiến lược hộ chiếu JsonWebToken mà tôi vừa cấu hình ở đây.
Ngoài ra, hãy để tôi xuất
thêm một chức năng từ đây gọi là VerifyUser.
Bây giờ, chức năng VerifyUser này,
tôi sẽ sử dụng nó để xác minh một người dùng đến.
Vì vậy, đây là nơi tôi sẽ sử dụng passport.authenticate.
Vì vậy, passport.authenticate, chiến lược là chiến lược jwt mà tôi vừa cấu hình,
chiến lược JsonWebToken mà tôi vừa cấu hình.
Sau đó, phần thứ hai,
tôi sẽ nói, phiên: false.
Vì vậy, điều đó có nghĩa là,
chúng ta sẽ không được tạo ra các phiên trong trường hợp này.
Như bạn nhớ lại, một ứng dụng nghịch đảo,
chúng tôi đang sử dụng xác thực dựa trên Token.
Vì vậy, chúng ta sẽ không tạo ra các phiên.
Vì vậy, đó là lý do tại sao tôi thiết lập phiên tùy chọn này để sai ở đây
, và tất nhiên, người đầu tiên chỉ định chiến lược mà tôi sẽ được sử dụng.
Vì vậy, để xác minh một người dùng,
tôi sẽ sử dụng chiến lược JWT.
Chiến lược JWT hoạt động như thế nào?
Trong yêu cầu đến,
mã thông báo sẽ được bao gồm trong tiêu đề xác thực như chúng ta đã thấy ở đây.
Chúng tôi nói tiêu đề xác thực như mã thông báo mang.
Nếu nó được bao gồm, sau đó nó sẽ được trích xuất và nó sẽ được
sử dụng để xác thực người dùng dựa trên mã thông báo.
Chỉnh sửa nhỏ ở đây, điều này nên là user.findone_id bằng jwt_payload. _id,
bởi vì đó là giá trị id nằm trong tải trọng của JsonWebToken của tôi.
Vì vậy, chúng tôi đang tìm kiếm người dùng với ID đã cho.
Vì vậy, một khi chúng ta đã hoàn thành điều này, thì bây giờ,
phần thứ hai mà chúng ta cần làm là chúng ta cần tạo ra mã thông báo ở đâu đó.
Bây giờ, chúng ta tạo ra mã thông báo ở đâu?
Vì vậy, đây là nơi mà một cái gì đó mà chúng tôi đang làm trong tập tin users.js là rất hữu ích cho chúng tôi.
Trong tệp users.js,
nhớ lại rằng bạn đã có điểm cuối này gọi là đăng nhập.
Trong điểm cuối đăng nhập,
bạn đã sử dụng tên người dùng và mật khẩu để xác thực người dùng.
Vì vậy, ngay cả với JsonWebToken để phát hành JsonWebToken,
trước tiên bạn cần phải xác thực người dùng bằng cách sử dụng một trong các chiến lược khác,
và nếu bạn đang sử dụng chiến lược cục bộ đầu tiên,
chúng tôi sẽ xác thực người dùng bằng cách sử dụng tên người dùng và mật khẩu.
Một khi người dùng được xác thực với tên người dùng và mật khẩu,
sau đó chúng tôi sẽ phát hành mã thông báo cho người dùng nói,
“Được rồi, bạn là người dùng hợp lệ,
tôi sẽ cung cấp cho bạn mã thông báo”.
Tất cả các yêu cầu tiếp theo sẽ chỉ đơn giản mang mã thông báo
trong tiêu đề của thông báo yêu cầu đến.
Vì vậy, trước đó, chúng tôi đã sử dụng để tạo ra các phiên.
Khi người dùng được xác thực,
chúng tôi sẽ không sử dụng phiên nữa.
Thay vào đó, khi người dùng được xác thực bằng cách sử dụng chiến lược cục bộ,
chúng tôi sẽ phát hành một mã thông báo cho người dùng.
Vì vậy, bên trong phương pháp Router.post này mà chúng tôi đã thực hiện trên đó /login terminal,
Tôi sẽ tạo ra một mã thông báo và vượt qua mã thông báo này trở lại cho người dùng.
Vì vậy, ở đây, chúng ta sẽ nói một Router.Post.
Để tôi tạo ra một mã thông báo.
Để tạo một mã thông báo,
chúng ta có hàm này trong mô-đun xác thực gọi là Authenticate.getToken.
Vì vậy, nhớ lại, rằng chúng tôi đã có,
để tận dụng điều đó tất nhiên,
ngay cả trước khi chúng tôi bắt đầu có,
tôi cần phải nhập chứng thực.
Mô-đun ở đây. Vì vậy, chúng tôi sẽ nói xác thực yêu cầu. /authenticate.
Vì vậy, sau đó, khi trong mã của bạn ở đây,
bây giờ chúng ta có thể nói Authenticate.GetToken,
và GetToken mất tham số ở đây.
Bây giờ, nhớ lại, quay lại tập tin authenticate.js.
Tệp authenticate.js có một tham số ở đây
sẽ được sử dụng làm trọng tải khi bạn đang tạo JsonWebToken.
Vì vậy, trong tập tin users.js,
tôi sẽ tạo ra một mã thông báo bằng cách đưa ra một trọng tải,
chỉ chứa ID của người dùng.
Vì vậy, chúng ta sẽ nói id: req.user.
Đó là đủ để tạo JsonWebToken.
Chúng tôi không muốn bao gồm bất kỳ thông tin nào khác của người dùng.
Nếu bạn chọn, bạn có thể bao gồm các phần khác của thông tin người dùng,
nhưng tôi sẽ đề nghị rằng giữ JsonWebToken nhỏ.
ID người dùng là đủ vì nếu bạn cần tìm kiếm người dùng,
ID người dùng là đủ để tìm kiếm trong MongoDB cho người dùng.
Vì vậy, tôi sẽ chỉ mã hóa ID của người dùng ở đây.
Bây giờ, bạn biết rằng req.user sẽ có mặt,
bởi vì khi passport.authenticate ('địa phương') xác thực thành công người dùng,
điều này sẽ tải lên tài sản người dùng vào thông báo yêu cầu.
Vì vậy, đó là lý do tại sao tôi có thể làm điều này ở đây.
Vì vậy, đây là những gì tôi sẽ sử dụng để tạo mã thông báo.
Bây giờ, một khi mã thông báo được tạo ra,
tôi muốn chuyển mã thông báo này trở lại cho người dùng.
Vì vậy, trong đối tượng rest.json mà tôi đang cung cấp ở đây,
tôi đã mang cờ thành công và cũng có thể,
một thông báo trạng thái ở đây.
Hãy để tôi thêm vào mã thông báo
như là một trong những thuộc tính trong thư trả lời ở đây.
Vì vậy, mã thông báo mà tôi vừa tạo ra,
tôi sẽ vượt qua này trở lại như là tài sản thứ hai bên trong chuỗi Json này ở đây.
Vì vậy, bây giờ, khi khách hàng của tôi nhận được chuỗi Json này trong cơ thể của thông điệp trả lời,
nó có thể đi vào và trích xuất mã thông báo từ đó.
Đó là nó. Vì vậy, bây giờ chúng tôi đã cập nhật các tập tin users.js,
và bây giờ bạn có thể thấy cách mã thông báo sẽ được
tạo ra và gửi lại cho người dùng khi người dùng được xác thực thành công.
Bây giờ, chương trình này cũng có thể được sử dụng
khi bạn sử dụng xác thực của bên thứ ba như dựa trên OAuth 2.0,
mà chúng tôi sẽ kiểm tra trong mô-đun tiếp theo.
Bây giờ, thủ tục sẽ tương tự.
Bạn sẽ tạo một mã thông báo khi người dùng được xác thực bởi
nhà cung cấp xác thực của bên thứ ba hoặc OAuth,
và sau đó bạn sẽ chuyển mã thông báo trở lại cho người dùng, theo
cách tiếp cận tương tự như bạn thấy ở đây.
Bây giờ, một khi chúng tôi đã làm điều này,
sau đó chúng tôi đi đến tập tin app.js.
Trong tập tin app.js, bởi vì chúng tôi đã bao gồm một tập tin cấu hình ở đây.
Vì vậy, hãy để tôi yêu cầu các tập tin cấu hình ở đây,
và sau đó URL mà tôi đang sử dụng ở đây thay vì hardcoding URL này,
tôi sẽ nói config.mongourl.
Vì vậy, bây giờ, bạn thấy cách tập tin config.js của tôi có thể được sử dụng như
một nơi tập trung, nơi tôi có thể chuẩn bị cấu hình cho ứng dụng của tôi.
Đó là nó. Vì vậy, những gì xảy ra bây giờ là khi người dùng
authenticates trên điểm cuối /login và người dùng được xác thực thành công,
sau đó mã thông báo sẽ được tạo ra bởi máy chủ và gửi lại cho khách hàng hoặc người dùng.
Vì vậy, khách hàng sẽ bao gồm mã thông báo trong
mọi yêu cầu đến tiếp theo trong tiêu đề ủy quyền.
Bây giờ, làm thế nào để nó bao gồm tiêu đề ủy quyền?
Hãy quay trở lại authentic.js và ở đây,
bạn thấy rằng chúng tôi đã nói ExtractJWt.FromAuthHeaderasBearerToken đây.
Vì vậy, điều này sẽ được bao gồm trong tiêu đề xác thực như một mã thông báo mang.
Tôi sẽ cho bạn thấy làm thế nào điều này được thực hiện,
sau đó chúng tôi sử dụng người đưa thư để bao gồm mã thông báo người mang vào tiêu đề xác thực.
Bây giờ, khi điều này đi vào,
sau đó bạn nhớ lại rằng ngay dưới đây,
bạn đã cấu hình phương pháp này ở đây gọi là VerifyUser,
mà kêu gọi chứng thực hộ chiếu với JWT.
Vì vậy, điều này sử dụng mã thông báo
đi kèm trong tiêu đề xác thực và sau đó xác minh người dùng.
Vì vậy, bất cứ lúc nào tôi muốn xác minh tính xác thực của người dùng,
tôi chỉ có thể gọi xác minh người dùng,
và điều đó sẽ bắt đầu cuộc gọi đến passport.authenticate và xác minh sser.
Nếu điều này thành công,
nó sẽ cho phép tôi tiếp tục.
Thủ tục này rất giống với những gì bạn đã làm trong
tập tin users.js nơi bạn gọi cùng passport.authenticate ('địa phương').
Vì vậy, nếu điều này là thành công,
sau đó bạn đi về phía trước.
Nếu nó không thành công, chức năng xác thực sẽ trả
lại thông báo lỗi cho khách hàng nói rằng người dùng không được ủy quyền.
Vì vậy, điều đó đã được thực hiện chăm sóc.
Vì vậy, bây giờ, rằng chúng tôi đã bao gồm điều này vào tập tin authenticate.js của tôi,
bất kỳ nơi nào mà tôi muốn xác minh người dùng,
tôi chỉ có thể gọi đến
chức năng VerifyUser này mà
tôi đã chỉ định ở đây hoặc xuất khẩu mà tôi đã chỉ định ở đây,
mà chúng tôi sẽ gọi khi passport.authenticate sử dụng
chiến lược JWT để xác thực người dùng.
Bây giờ, làm thế nào để chúng ta sử dụng nó?
Bây giờ, những gì chúng ta sẽ làm là chúng ta sẽ đi vào mỗi bộ định tuyến của chúng ta,
và kiểm soát các tùy chọn trên tất cả các tuyến đường mà chúng ta muốn điều khiển.
Vì vậy, quay trở lại tập tin app.js, bây giờ,
rằng chúng tôi không sử dụng phiên tôi sẽ loại bỏ phiên này từ đây,
bởi vì chúng tôi không còn sử dụng phiên nữa.
Tương tự như vậy, tôi sẽ loại bỏ passport.session này từ đây cũng.
Điều đó cũng không cần thiết.
Ngoài ra, xác thực này, xem trước đó,
khi tôi cấu hình xác thực này, xác
thực này đã được áp dụng cho mỗi yêu cầu đến duy nhất.
Bây giờ, tôi sẽ thay đổi ứng dụng của tôi,
theo đó tôi sẽ yêu cầu xác thực chỉ trên các tuyến đường nhất định và không phải trên tất cả các tuyến đường.
Vì vậy, hãy để tôi loại bỏ xác thực này hoàn toàn từ app.js.
Vì vậy, bây giờ, khi yêu cầu đi vào,
nếu nó là trên/điểm cuối,
chỉ số sẽ được phục vụ.
Nếu nó là trên /users điểm cuối nó sẽ cho phép bạn điều hướng đến
các tuyến đường khác nhau được gắn vào /users trong users.js,
và sau đó, phần còn lại của những tuyến đường khác nhau.
Những gì tôi sẽ làm bây giờ là tôi sẽ để lại
thư mục công cộng mở cho bất cứ ai để truy cập.
Bây giờ, trong nhiều ứng dụng,
điều này có thể là tốt.
Vì vậy, tôi sẽ để nó mở ra.
Bây giờ, trên các món ăn,
chương trình khuyến mãi, và điểm cuối của các nhà lãnh đạo,
tất cả các yêu cầu nhận được.
Tôi sẽ để những người được trả lời mà không yêu cầu bất kỳ xác thực nào.
Bây giờ tại sao tôi lại muốn làm điều đó?
Nếu một người dùng đang thực hiện một yêu cầu nhận được,
người dùng chỉ muốn truy xuất thông tin.
Vì vậy, ví dụ, ở phía khách hàng nếu tôi đang thực hiện một ứng dụng web bằng cách sử dụng Angular
hoặc một ứng dụng khách hàng sử dụng Ionic hoặc kịch bản gốc,
sau đó có lẽ tôi muốn thực hiện ứng dụng của tôi trong
một cách mà các trang chính sẽ hiển thị thông tin đã,
các thông tin di truyền mà bạn muốn cung cấp cho bất kỳ ai
truy cập trang web của bạn hoặc mở ứng dụng của bạn.
Vì vậy, thông tin cơ bản có thể được hiển thị ở đó.
Nhưng nếu bạn muốn thay đổi bất cứ điều gì,
sau đó bạn mong đợi người dùng được xác thực.
Vì vậy, bạn sẽ cho phép các hoạt động POST, đặt các hoạt động
và xóa các hoạt động chỉ được thực hiện bởi người dùng xác thực.
Tương tự như vậy, ví dụ như nhận xét,
bạn có thể nói rằng nhận xét chỉ có thể được đăng hoặc sửa đổi bởi người dùng xác thực.
Vì vậy, bạn có thể hạn chế chỉ một số tuyến đường cho người dùng xác thực,
các tuyến đường khác bạn có thể để chúng mở. Làm thế nào để chúng ta làm được điều đó?
Bây giờ đây là nơi người dùng xác minh rằng chúng tôi
đã xuất khẩu từ tập tin authenticate.js có ích.
Bây giờ thay vì kiểm soát tất cả các điểm kết thúc,
tất cả các hoạt động khác nhau trên các món ăn, chương trình khuyến mãi
và các nhà lãnh đạo trong các điểm,
chúng tôi sẽ chỉ mở các hoạt động get cho bất kỳ ai
, nhưng các
hoạt động post, put và delete sẽ bị hạn chế chỉ cho người dùng xác thực.
Trong nhiệm vụ, bạn sẽ thêm vào một thể loại khác của người dùng được gọi là người dùng quản trị.
Bây giờ bạn sẽ hạn chế các hoạt động nhất định chỉ được thực hiện bởi người dùng quản trị.
Vì vậy, ví dụ, sửa đổi các món ăn
hoặc xóa các món ăn thông tin từ cơ sở dữ liệu,
sẽ chỉ bị hạn chế cho người dùng quản trị.
Nhưng người dùng cơ bản có thể đăng bình luận,
sửa đổi các nhận xét mà họ đã đăng,
và thậm chí có thể lưu một số món ăn yêu thích.
Chúng ta sẽ làm phần đó trong mô-đun thứ tư.
Vậy làm thế nào để chúng ta kiểm soát các tuyến đường cụ thể?
Vì vậy, đây là nơi chúng ta phải đi vào mỗi bộ định tuyến
và sau đó nhập khẩu điều khiển trên các tuyến đường cụ thể.
Vì vậy, chúng ta hãy bắt đầu với các món ăn tuyến đường.
Vì vậy, đối với các món ăn tuyến đường,
bạn sẽ nhớ lại rằng điều này được kiểm soát trong tập tin dishRouter.js.
Vì vậy, đi đến dishRouter.js,
trước tiên chúng ta hãy nhập xác thực ở đây.
Vì vậy, chúng ta sẽ nói, const authenticate
yêu cầu../authenticate vì
tập tin authenticator.js này nằm trong thư mục cấp cao hơn.
Vì vậy, hãy nhớ../xác thực ở đây.
Vì vậy, một khi bạn nhập chứng thực,
cho tuyến đường bộ định tuyến món ăn cho tuyến đường này,
các hoạt động get, tôi sẽ cho phép mà không có bất kỳ vấn đề.
Vì vậy, đó là mở cửa.
Vì vậy, tôi sẽ không áp đặt bất kỳ hạn chế nào.
Từ bài đăng, nếu chúng ta muốn áp dụng nhiều middleware,
chúng ta chỉ có thể thêm chính bên trong cái này đằng sau cái kia.
Bây giờ khi bài đăng được gọi,
ngay bây giờ bạn chỉ đơn giản là thực hiện chức năng này ở đây.
Bây giờ ngay trước đó,
tôi có thể đi vào và nói, Authenticate.VerifyUser, ở đó.
Vậy, điều này có tác dụng gì?
Điều này nói rằng nếu một bài yêu cầu đi vào,
đầu tiên tôi sẽ thực hiện middleware này,
mà tôi đã xuất khẩu từ các tập tin authentic.js,
đầu tiên tôi áp dụng
điều đó, tương đương với nói hộ chiếu xác thực JWT và bạn đang kiểm tra người dùng.
Sau đó, nếu điều này thành công,
sau đó tôi sẽ tiếp tục làm phần còn lại của nó.
Nếu xác thực không thành công tại thời điểm này,
sau đó hộ chiếu xác thực sẽ trả lời
lại cho khách hàng với thông báo lỗi thích hợp.
Vì vậy, điều đó đã được xử lý bởi chứng thực hộ chiếu,
vì vậy tôi không phải lo lắng bất cứ điều gì ngoài thời điểm đó.
Nếu tôi đã vượt qua middleware này và sau đó nhận được để
thực hiện các chức năng tiếp theo có nghĩa là xác thực của tôi đã thành công,
vì vậy tôi có thể tiến hành về phía trước từ thời điểm này.
Vì vậy, điều này hoạt động như là rào cản cho phương pháp bài này.
Bây giờ sử dụng cùng một đối số,
tôi chỉ có thể áp dụng phần mềm trung gian đặc biệt này cho tất cả các phương pháp khác.
Tôi có thể làm điều đó để đặt chỗ.
Mặc dù trong trường hợp này,
đặt sẽ không được làm bất cứ điều gì.
Nhưng trong mọi trường hợp,
tôi sẽ chỉ đơn giản là vì lợi ích của sự đồng nhất,
tôi sẽ áp dụng xác minh người dùng cũng đặt và tất nhiên,
để xóa quá, tôi sẽ áp dụng đặt.
Tương tự như vậy, đi xuống đến /disHid,
nhận được tôi sẽ cho phép điều đó để làm việc mà không có bất kỳ vấn đề.
Bài viết, tôi sẽ áp dụng người dùng xác minh.
Đặt cũng tôi sẽ áp dụng xác minh người dùng và xóa cũng giống nhau.
Đối với các /dishid/bình luận, tôi sẽ để lại get open,
nó là okay cho bất cứ ai để lấy ý kiến về một món ăn cụ thể.
Đăng bài, tôi sẽ đóng bài này,
vì vậy chỉ có người dùng đã xác minh mới có thể đăng bình luận.
Đặt cũng tôi sẽ đóng cửa này và xóa quá.
Bạn cần phải đi thêm một bước nữa và nói,
“Chỉ những người dùng đã đăng nhận xét mới có thể xóa bài đăng của riêng họ.”
Nhưng chúng tôi sẽ làm điều đó trong mô-đun tiếp theo.
Trong thời điểm này, tôi sẽ nói,
“Được rồi, một người dùng đã xác minh có thể xóa bất kỳ bình luận nào.”
Điều này là tất nhiên không đúng,
chúng tôi có thể đặt một kiểm tra bổ sung,
nhưng chúng tôi sẽ làm điều đó trong mô-đun tiếp theo của khóa học này.
Vì vậy, để xóa cũng tôi áp dụng như nhau.
Một lần nữa, cho các bình luận bộ định tuyến món ăn/ý kiến Id,
có được tôi sẽ để nó như mở.
Bài viết, tôi sẽ để nó đóng lại.
Đặt cũng đóng nó đi và sau đó cho xóa cũng tôi sẽ đóng này đi.
Xóa tất nhiên như tôi đã nói,
thao tác xóa nên được phép chỉ có một người dùng
đã tạo ra bình luận nên được yêu cầu xóa điều đó,
nhưng bạn cần phải thiết lập một vài điều bổ sung để làm việc một cách chính xác,
mà chúng tôi sẽ làm trong mô-đun tiếp theo.
Hiện tại, chúng tôi đang nói rằng một người dùng đã được xác minh có thể xóa một nhận xét cụ thể, đó là nó.
Bây giờ chúng tôi sẽ áp dụng cùng một nguyên tắc cho bộ định tuyến quảng cáo và cũng là bộ định tuyến lãnh đạo.
Vì vậy, đi vào router quảng cáo,
hãy để tôi nhập xác thực
và sau đó nhận được là mở,
vì vậy đây là router lãnh đạo.
Vì vậy, nhận được là mở.
Bài viết, Tôi sẽ kiểm soát điều đó,
đặt, kiểm soát, xóa, kiểm soát,
lãnh đạo router, lãnh đạo ID,
nhận được là okay, bài viết,
kiểm soát, đặt được kiểm soát và xóa được kiểm soát.
Cùng một điều với bộ định tuyến quảng cáo.
Hãy để tôi, yêu cầu xác thực
và sau đó cho các tuyến đường được mở,
POST được kiểm soát, đặt được kiểm soát,
xóa được kiểm soát, điều tương tự cho các promorouter/promoid.
Get là mở, POST được kiểm soát,
đặt và xóa cũng được kiểm soát, đó là nó.
Hãy lưu tất cả các thay đổi.
Vì vậy, một khi chúng tôi hoàn thành tất cả các thay đổi, chúng
ta hãy lưu các thay đổi.
Bây giờ, ứng dụng của chúng tôi đã sẵn sàng để được kiểm tra.
Vì vậy, chúng ta hãy đi và khởi động lại máy chủ của chúng tôi,
hoặc nếu máy chủ không chạy,
chúng tôi sẽ chỉ khởi động máy chủ.
Đi đến thiết bị đầu cuối,
máy chủ của tôi không chạy.
Vì vậy, hãy để tôi bắt đầu máy chủ bằng cách gõ npm start.
Thật thú vị, nó chỉ ném một lỗi ở đây,
Tôi chỉ muốn minh họa cho bạn rằng ngay cả tôi có thể phạm sai lầm,
vì vậy bạn sẽ thấy rằng có một lỗi ở đây nói,
“Không thể tìm thấy module.authenticate”, và sau đó nếu tôi nhìn qua mã,
tôi thấy rằng vấn đề này xảy ra trong,
nó đã xảy ra ở đâu?
Vì vậy, tôi chỉ tìm kiếm ở đây,
và sau đó một nơi nào đó xuống đây,
tôi nhận thấy rằng vấn đề này xảy ra bên trong tập tin users.js của tôi.
Vì vậy, ngay tại đó, nó nói,
đây là trong tập tin users.js.
Vì vậy, đi đến tập tin users.js, chúng ta hãy sửa chữa điều đó.
Đi đến tập tin users.js,
ngay ở trên cùng khi tôi yêu cầu xác thực, tôi nói,
“.authenticate”, và như tôi đã nói với bạn,
đó phải là một dấu chấm vì nó nằm trong thư mục phía trên.
Tệp users.js này trong thư mục Routes,
và xác thực là trong thư mục Projects Route vì vậy điều này nên được chấm chấm xác thực.
Vì vậy, nếu bạn phạm sai lầm,
đó là cách bạn sẽ được nhắc nhở về lỗi mà bạn đã giới thiệu.
Vì vậy, chúng ta hãy lưu các thay đổi và sau đó khởi động lại máy chủ của chúng tôi.
Một lần nữa, quay trở lại thiết bị đầu cuối đó,
hãy để tôi bắt đầu máy chủ của tôi và máy chủ của tôi bây giờ là lên và chạy, chúng
ta hãy đi đến Postman và sau đó kiểm tra ứng dụng của chúng tôi.
Bây giờ, trong Postman, hãy để tôi đầu tiên cố gắng làm
một GET trên localhost:3000/món ăn và sau đó khi tôi làm một GET,
nó là thành công bởi vì điểm cuối GET không được kiểm soát.
Vì vậy, tôi có thể làm một GET trên các món ăn,
Tôi có thể làm một GET trên chương trình khuyến mãi,
và tất cả các hoạt động tốt.
Nhưng nếu tôi cố gắng làm một bài đăng trên các món ăn,
vì vậy hãy để tôi tìm nơi tôi đã thực hiện một bài đăng trên các món ăn.
Ở đây tôi đã thực hiện một bài đăng trên các món ăn.
Vì vậy, khi tôi cố gắng để làm một POST trên các món ăn,
nó ngay lập tức nói trái phép.
Vì vậy, mô-đun hộ chiếu của tôi đã nhận ra rằng tôi không được phép để tôi không được phép làm điều này,
vì vậy đó là những gì nó đang nhắc nhở tôi về.
Hãy để tôi làm sạch các cookie từ,
trong trường hợp bạn tìm thấy một cookie trong Postman của bạn chỉ
cần loại bỏ các cookie tương ứng với localhost bởi vì
cookie đó không còn cần thiết và sẽ không được yêu cầu.
Vì vậy, ngay cả khi tôi loại bỏ các cookie và sau đó POST,
nó vẫn sẽ nói trái phép.
Vì vậy, tôi không được phép thực hiện các hoạt động này.
Vì vậy, tôi phải đăng nhập.
Bây giờ, nếu bạn đã thực hiện bài tập trước đó,
bạn đã rời khỏi người dùng mà bạn đã đăng ký trước đó.
Vì vậy, ví dụ, bạn đã đăng ký người dùng cụ thể này trong bài tập trước đó,
hãy để tôi cố gắng đăng ký cùng một người dùng một lần nữa và
máy chủ của tôi nên phàn nàn rằng useRexistSerror để có nghĩa là người dùng tồn tại,
vì vậy tôi không cần phải đăng ký lại.
Nếu bạn đã xóa người dùng khỏi MongoDB của bạn,
chỉ cần đăng ký người dùng đó một lần nữa và sau đó chúng ta hãy đăng nhập.
Vì vậy, chúng tôi sẽ gửi một yêu cầu đăng nhập đến điểm kết thúc đó.
Vì vậy, khi tôi gửi yêu cầu đăng nhập bằng cách thực hiện một POST cho người dùng cuối, hãy
chú ý những gì được trả lại bởi máy chủ của tôi.
Bạn ngay lập tức nhận thấy rằng trong thư trả lời
cùng với cờ thành công và thông báo trạng thái,
bạn cũng nhận được một mã thông báo ở đây.
Bây giờ, mã thông báo đặc biệt này,
tôi cần phải sao chép mã thông báo này,
bởi vì trong các yêu cầu tiếp theo của tôi,
tôi sẽ cần phải bao gồm mã thông báo này.
Vì vậy, để tôi đi đến phiên bản thô của điều này và rằng tôi sẽ sao chép mã thông báo này.
Mã thông báo này không chỉ là một chuỗi dài ở đó,
vì vậy hãy để tôi sao chép mã thông báo này.
Sau đó, bây giờ nếu bạn tò mò về những gì được chứa trong mã thông báo này,
JSON Web Token có thể được kiểm tra.
Có một trang web cụ thể mà bạn có thể vào và gõ
vào JSON Web Token của bạn và sau đó thực sự kiểm tra những gì bên trong JSON Web Token.
Hãy làm điều đó như là bước tiếp theo.
Trong một cửa sổ trình duyệt,
chỉ cần gõ jwt.io và điều này sẽ đưa bạn đến trang web này được gọi là JSON Web Token jwt.io.
Nếu bạn nhớ lại, trong bài giảng,
tôi đã cho bạn thấy cấu trúc của JSON Web Token
và đã cho bạn thấy rằng JSON Web Token chứa ba phần: tiêu đề
, tải trọng và thông tin ở đó.
Bây giờ, trong trường hợp này,
thông tin là lên ở đây vì vậy
tôi sẽ dán JSON Web Token của tôi vào phía bên trái này,
vì vậy hãy để tôi chọn đó và sau đó dán JSON Web Token của tôi vào
phía bên trái trong phần mã hóa và sau đó ở phía bên phải,
nó hiển thị cho bạn chính xác những gì là bên trong JSON Web Token mà tôi vừa tạo ra.
Vì vậy, nó nói tiêu đề chứa hai mẩu thông tin này.
Tải trọng thông báo rằng nó chứa ID của
người dùng và sau đó là chữ ký ở dưới cùng ở đây.
Vì vậy, đây là những gì được chứa bên trong JSON Web Token của tôi.
Quay lại Postman,
bây giờ để tôi thử lấy các món ăn.
Vì vậy, khi tôi nói GET localhost:3000/món ăn,
nó vẫn sẽ trả về một chuỗi rỗng,
mảng rỗng ở đây vì cơ sở dữ liệu của tôi không chứa nó.
Vì vậy, hãy để tôi đăng một món ăn vào cơ sở dữ liệu của tôi.
Vì vậy, tôi sẽ chọn hoạt động POST và trong cơ thể,
bạn thấy rằng tôi có món ăn của tôi ở đây.
Trong tiêu đề, tôi sẽ thêm vào tiêu đề mới gọi là
ủy quyền và bạn nhớ lại rằng trước đó cho phép cơ bản,
bạn nói cơ bản và sau đó bạn đã có cơ sở 64 mã hóa chuỗi đó.
Nếu bạn muốn bao gồm JSON Web Token của bạn trong tiêu đề ủy quyền,
bởi vì trong mã của chúng
tôi, chúng tôi đã nói ủy quyền như token mang.
Vì vậy, nếu bạn muốn bao gồm mã thông báo trong tiêu đề ủy quyền,
trong ủy quyền chúng tôi sẽ nói người mang và sau đó chúng tôi sẽ dán
chuỗi mã thông báo mà chúng tôi vừa sao chép từ yêu cầu đến của chúng tôi.
Vì vậy, chúng tôi sẽ dán chuỗi mã thông báo trong đó.
Vì vậy, đây là những gì sẽ được chứa
trong tiêu đề ủy quyền của yêu cầu đi của tôi ở đây,
yêu cầu POST đi đây.
Vì vậy, thông báo, phía bên trái nói người mang và phía bên phải là chuỗi,
mã thông báo mà tôi vừa sao chép từ
điểm mà tôi đăng nhập và sau đó cho phép tôi gửi tin nhắn POST ngay bây giờ
và POST của tôi bây giờ là thành công và điều này được đăng lên cơ sở dữ liệu của tôi.
Bây giờ, nếu bạn muốn chắc chắn rằng nó đã được đăng,
chúng ta hãy làm một GET và khi bạn làm một GET,
bạn có thể thấy rằng thực sự món ăn đó đã được chèn vào cơ sở dữ liệu của tôi như được hiển thị ở đây.
Vì vậy, đây là cách bạn sẽ sử dụng JSON Web Token trong ứng dụng của bạn.
Vì vậy, bất cứ khi nào bạn cần thực hiện một POST, PUT,
hoặc một thao tác DELETE trên bất kỳ điểm cuối nào,
bạn sẽ được kèm theo.
Vì vậy, hãy để tôi quay lại yêu cầu POST này ở đây.
Trong tiêu đề, bạn sẽ đặt
trường ủy quyền này và sau đó điều này sẽ được bao gồm trong ủy quyền,
bạn sẽ bắt đầu nó với người mang và sau đó là chuỗi mã thông báo,
sau đó không gian mang,
một không gian duy nhất và sau đó là chuỗi mã thông báo sau đó.
Vì vậy, đó là cách tin nhắn yêu cầu của bạn sẽ
mang theo JSON Web Token trong tiêu đề của thông báo yêu cầu đi.
Bạn cũng có thể bao gồm mã thông báo trong nội dung của thư yêu cầu đi.
Bây giờ, cho điều đó, bạn sẽ phải cấu hình
máy chủ express của bạn đặc biệt là JWT bổ sung trong
tập tin authenticate.js để chấp nhận nó từ
cơ thể, vì vậy bạn nhớ lại rằng ở đó chúng tôi đã thấy rằng
JWT bổ sung hỗ trợ nhiều cách khác nhau để trích xuất
JSON Web Token từ yêu cầu.
Vì vậy, ở đó bạn cần phải chỉ định,
nếu bạn sẽ được bao gồm nó trong cơ thể,
bạn cần phải xác định thông tin đó ở đó.
Bây giờ, các chi tiết về làm thế nào để làm điều đó bạn có thể tham khảo
tài liệu mô-đun Passport JWT để hiểu làm thế nào điều này được thực hiện.
Trong khóa học này, tôi sẽ chỉ đơn giản là sử dụng trong tiêu đề ủy quyền
như tôi đã trình bày ở đây và điều này hoạt động tốt cho hầu hết các trường hợp.
Bây giờ, nếu bạn đang phát triển một ứng dụng Web,
một ứng dụng Angular, hoặc một ứng dụng Ionic hoặc NativeScript,
bạn cần có khả năng cấu hình
ứng dụng đó theo đó JSON Web Token sẽ được bao gồm trong tiêu đề ủy quyền.
Trong bài học cuối cùng của khóa học này,
tôi sẽ chỉ cho bạn cách tích hợp khách hàng và máy chủ,
khách hàng mà bạn đã phát triển trong các khóa học trước đó với
máy chủ mà chúng tôi đã phát triển trong khóa học này.
Với điều này, chúng tôi hoàn thành bài tập này.
Trong bài tập này, chúng ta đã thấy làm thế nào chúng ta
có thể cấu hình ứng dụng của chúng tôi để sử dụng JSON Web Token,
và chúng tôi đã thấy cách chúng tôi xử lý xác thực của người dùng bằng cách sử dụng JSON Web Token,
sử dụng sự hỗ trợ từ các mô-đun Passport và các mô-đun Passport JWT,
và các mô-đun JSON Web Token Node.
Với điều này, chúng tôi hoàn thành bài tập này.
Đây là thời điểm tốt để bạn thực hiện một Git Commit với thông điệp Passport JWT.