Đây là phần thứ hai của Tập thể dục Express Sessions.
Chúng tôi đã hoàn thành phần đầu tiên trước đó,
nơi chúng tôi thêm hỗ trợ cho Express Sessions,
và sử dụng Express Sessions như một cách để theo dõi người dùng ở phía máy chủ,
và nhận ra các yêu cầu đến từ người dùng.
Trong bài tập này, chúng tôi không tập trung quá nhiều vào Express Sessions,
nhưng chúng tôi sẽ xem xét một cách mở rộng máy chủ REST API để hỗ trợ
một mô hình mới để đăng ký và xác thực người dùng.
Vì vậy, chúng tôi sẽ giới thiệu một mô hình người dùng mới và giản đồ vào ứng dụng của chúng tôi.
Chúng tôi đã có tuyến đường người dùng dấu gạch chéo mà
máy phát nhanh đã gắn bộ định tuyến của người dùng.
Vì vậy, chúng tôi sẽ tận dụng điều đó và sau đó cập nhật điều đó
để hỗ trợ đăng ký người dùng mới,
xác thực một người dùng hiện tại,
và cũng đăng xuất một người dùng từ trang web máy chủ của chúng tôi.
Vì vậy, chúng ta sẽ xem xét Express Sessions như một cách để theo dõi người dùng một khi người dùng đăng nhập,
và sau đó khi người dùng đăng xuất,
phiên sẽ bị xóa khỏi hệ thống.
Vì vậy, làm thế nào để chúng ta đi về làm phần mở rộng này trong bài tập này?
Chúng ta hãy đi và tìm hiểu.
Tiếp tục với máy chủ REST API nhanh của chúng tôi,
bây giờ chúng ta hãy đi vào các mô hình và thêm một tập tin mới có tên user.js.
Đây là tập tin mà chúng tôi sẽ tạo ra lược đồ người dùng và mô hình.
Chúng tôi sẽ tạo một lược đồ người dùng đơn giản theo dõi tên người dùng và mật khẩu,
và cũng là một lá cờ được đặt để chỉ ra
người dùng là người quản trị hay người dùng bình thường.
Vì vậy, đây là một cách để phân biệt giữa các loại người dùng khác nhau.
Vì vậy, trong tập tin này,
trước tiên chúng ta hãy yêu cầu Mongoose bởi vì chúng ta đang tạo ra một lược đồ Mongoose,
và sau đó chúng ta sẽ tạo ra một lược đồ tên Mongoose schema,
và sau đó chúng ta sẽ nói var user.
Vì vậy, đây là lược đồ người dùng mà chúng ta sẽ tạo ra,
và chúng ta sẽ nói lược đồ người dùng mới.
Các giản đồ người dùng sẽ được định nghĩa như tôi vừa đề cập,
với ba lĩnh vực ở đây được gọi là tên người dùng
mà rõ ràng sẽ là của chuỗi loại,
và đây là một lĩnh vực bắt buộc,
và đây là một lĩnh vực duy nhất.
Bạn không muốn hai người dùng có cùng tên người dùng trong hệ thống của bạn,
vì vậy chúng tôi tạo tên người dùng và sau đó trường thứ hai là trường mật khẩu.
Bây giờ, tất nhiên, bạn có thể mở rộng
lược đồ người dùng này để cho phép người dùng theo dõi toàn bộ hồ sơ của họ,
nhưng chúng tôi sẽ làm điều đó trong một trong những bài tập sau này, cho thời điểm này,
một người dùng được công nhận trong hệ thống bằng cách đơn giản là tên người dùng và mật khẩu.
Vì vậy, mật khẩu là của chuỗi loại và sau đó là bắt buộc.
Trường thứ ba mà tôi sẽ sử dụng được gọi là quản trị viên.
Vì vậy, quản trị viên là loại Boolean,
và chúng tôi sẽ nói mặc định false.
Vì vậy, theo mặc định khi một người dùng được tạo ra,
một người dùng mới được tạo
ra, cờ quản trị sẽ được đặt thành false.
Bạn có thể rõ ràng thiết lập nó thành true từ bên
trong mã của bạn để đánh dấu một người dùng là một người dùng quản trị.
Có lẽ bạn có thể cung cấp các đặc quyền bổ sung cho người dùng quản trị,
hoặc có thể cho phép người dùng quản trị thực hiện các
thao tác nhất định mà người dùng bình thường sẽ không làm như vậy.
Chúng ta sẽ xem xét điều đó trong một trong những bài tập sau này,
cho thời điểm này, đây là lược đồ người dùng mà chúng ta đã tạo ra, chúng ta
hãy tạo ra một mô-đun ra khỏi điều này và xuất từ
mô-đun này một mô hình Mongoose của người dùng tên.
Vì vậy, đây là mô hình Mongoose và giản đồ là lược
đồ người dùng mà chúng tôi vừa xác định trước đó một chút.
Vì vậy, đây là cách chúng tôi xác định lược đồ người dùng của chúng tôi.
Vì vậy, bây giờ chúng ta đã xác định lược đồ người dùng
của chúng tôi, chúng ta hãy đi vào bộ định tuyến đã được thiết lập
bởi bộ tạo nhanh khi nó tạo ra ứng dụng express này.
Vì vậy, nếu bạn đi vào thư mục route,
bạn sẽ thấy tệp này được gọi là users.js.
Vì vậy, tệp users.js này sẽ được mở rộng để tạo bộ định tuyến.
Vì vậy, ngay có những gì tôi sẽ làm là nhập khẩu cơ thể phân tích cú pháp,
và sau đó họ sẽ khai báo router nhanh,
và sau đó chúng ta sẽ nói cũng nhập khẩu
giản đồ người dùng và
mô hình từ người dùng mô hình,
và sau đó cho router nhanh chúng ta sẽ nói, bộ định
tuyến sử dụng cơ thể phân tích cú pháp.
Vì vậy, bây giờ mà chúng tôi đã tuyên bố phân tích cú pháp cơ thể trong đó,
chúng tôi sẽ để lại phần này như vậy,
sau đó chúng tôi sẽ sửa đổi này để cho phép các quản trị viên
để có thể truy xuất
tất cả các người dùng được đăng ký trong hệ thống nhưng cho thời điểm này,
chúng tôi sẽ rời khỏi tuyến đường đó như vậy.
Chúng tôi sẽ thêm vào một vài tuyến đường nữa ở đây,
vì vậy chúng tôi sẽ nói, “Bài đăng bộ định tuyến”.
Vì vậy, chúng tôi sẽ hỗ trợ hoạt động sau trên một tuyến đường được gọi là đăng
ký và như bạn mong đợi, tuyến đường đăng ký này sẽ cho phép người dùng đăng ký trên hệ thống,
vì vậy điều này sẽ hỗ trợ đăng ký của người dùng.
Vì vậy, chúng ta sẽ nói, “Rec, res, tiếp theo.”
Và vì vậy đây sẽ là đăng ký đăng ký bộ định tuyến,
các phương pháp còn lại sẽ không được phép trên phần cuối đăng ký.
Vì vậy, để truy cập điều
này, kể từ khi router người dùng này được gắn trên người dùng gạch
chéo, chúng tôi sẽ chỉ định điểm cuối này là người dùng gạch chéo slash đăng ký,
và đây là điểm cuối sẽ được sử dụng để đăng ký người dùng mới trong hệ thống.
Vì vậy, điều đầu tiên mà chúng tôi sẽ làm là sử dụng
phương pháp người dùng và kỳ vọng là đối với một người dùng để đăng ký, tên người
dùng và mật khẩu sẽ được cung cấp dưới dạng một chuỗi JSON
bên trong cơ thể của yêu cầu bài đăng đến.
Vì vậy, từ cơ thể,
vì cơ thể đã được phân tích cú pháp cơ thể, do đó,
từ cơ thể,
trước tiên sẽ kiểm tra để đảm bảo rằng
người dùng có tên người dùng đó không tồn tại trong hệ thống.
Nếu người dùng có tên người dùng đó tồn tại,
thì bạn đang cố gắng đăng ký một người dùng trùng lặp
và điều đó không nên được phép trong hệ thống.
Vì vậy, chúng tôi sẽ nói, “Người dùng tìm thấy một”, và sau đó chúng tôi sẽ cố gắng tìm xem
có một người dùng với tên người dùng đã được
chọn bởi khách hàng đang cố gắng đăng ký một người dùng mới hay không.
Nếu người dùng đã tồn tại,
thì rõ ràng bạn sẽ không cho phép người dùng mới đăng ký với cùng một tên người dùng.
Vì vậy, chúng tôi sẽ nói, “Sau đó người dùng.”
Vì vậy, điều này sẽ trả lại người dùng ở đây và bên trong trường người dùng này,
sau đó chúng tôi sẽ kiểm tra thực tế cho dù người dùng đã tồn tại,
và sau đó cho phép tôi bắt lỗi ở đây.
Vì vậy, chúng tôi sẽ nói, “Bắt lỗi”, và sau đó, “lỗi tiếp theo.”
Vì vậy, chúng tôi sẽ chỉ cần truyền cho trình xử lý lỗi ở đó.
Vì vậy, nếu tìm kiếm này cho người dùng trả về trường người dùng,
nếu người dùng không bằng null.
Vì vậy, nếu người dùng được trả về bởi tìm kiếm này
không phải là null thì điều đó có nghĩa là người dùng có tên người dùng đã cho đã tồn tại,
vì vậy bạn không nên cho phép đăng ký trùng lặp.
Vì vậy, chúng tôi sẽ nói, “Var err lỗi mới.”
Và chúng ta sẽ nói, “Người dùng req. body username.”
Đã tồn tại rồi. Vì vậy, về cơ bản,
bạn đang ngăn chặn một người dùng trùng lặp đăng ký và sau đó chúng tôi sẽ nói
err.status 403 so với bị cấm và sau đó thoát ra,
gọi trình xử lý lỗi, tiếp theo err.
Nếu không, điều này có nghĩa là người dùng không tồn tại
vì vậy bạn nên cho phép người dùng được đăng xuất.
Vì vậy, trong phần khác,
chúng ta sẽ nói, trả về user.create ().
Chúng tôi sẽ tạo một người dùng mới với tên người dùng được thiết lập để req.body.username,
và sau đó cho phép tôi đặt điều này trong dòng tiếp theo để nó rõ ràng hơn với bạn,
và chúng tôi sẽ nói mật khẩu: req.body.password.
Bây giờ, chúng ta đã biết rằng cờ admin mặc định sẽ được đặt thành false,
vì vậy chúng tôi sẽ để nó như vậy,
và điều này sẽ cho phép người dùng mới của chúng tôi được đăng ký và khi người dùng mới được đăng ký,
điều này sẽ trả lại một lời hứa và bên trong “sau đó” chúng tôi sẽ xử lý lời hứa này ở đây.
Vì vậy, điều này sẽ trả lại lời hứa từ
điều này “sau đó” và sau đó chúng tôi sẽ xử lý nó trong tiếp theo “sau đó” ở đây.
Sẽ nói sau đó, res.StatusCode là 200,
res.Setheader và chúng tôi sẽ nói nội dung loại ứng dụng/json
và chúng tôi sẽ nói, res.json (trạng thái: Đăng ký thành công),
và nếu bạn muốn,
chúng ta có thể tải người dùng vào
thông điệp trả lời này ở đây như là một tài sản trong json.
Sẽ nói Đăng ký thành công.
Sau đó, nếu có một lỗi trong
thao tác này sẽ nói “tiếp theo err”.
Vì vậy, điều đó sẽ xử lý các lỗi.
Nếu lời hứa không giải quyết thành công,
thì sẽ được xử lý bởi điều đó. Vậy là vậy.
Vì vậy, ở đây, chúng tôi có một cách để người dùng đăng ký.
Vì vậy, để người dùng đăng ký,
người dùng sẽ thực hiện một bài đăng trên /users/đăng ký và trong nội dung của tin nhắn,
khách hàng sẽ bao gồm một chuỗi json
với tên người dùng và mật khẩu thuộc tính trong chuỗi json đó.
Đó là cách bạn đăng ký một người dùng mới.
Bây giờ, chúng ta hãy xem làm thế nào chúng ta sẽ đăng nhập vào người dùng.
Bây giờ, chúng tôi vẫn sẽ sử dụng phiên Express mà chúng tôi đã thực hiện trước đó để theo dõi người dùng.
Vì vậy, để đăng nhập một người dùng sẽ nói “router.post” trên điểm kết thúc/đăng nhập.
Vì vậy, trên điểm cuối /login,
chúng tôi sẽ làm một router.post.
Chúng tôi rõ ràng sẽ thay vì nói chức năng,
bạn có thể sử dụng các chức năng mũi tên ở đây cho router.post,
Tôi sẽ làm điều tương tự ở đây.
Tôi đã nhận được thích các chức năng mũi tên.
Vì vậy, chúng tôi sẽ làm một chức năng mũi tên ở đây.
Vì vậy, đối với đăng nhập, đăng nhập tiến hành như thế nào?
Vì vậy, đối với đăng nhập,
những gì chúng tôi sẽ làm là chúng tôi sẽ đi đến các tập tin app.js và sau đó bên trong auth này,
chúng tôi đã làm điều đó đăng ký cho người dùng ở đó.
Vì vậy, điều tôi sẽ làm là tôi sẽ sao chép
toàn bộ điều này bởi vì tôi sẽ không làm tất cả điều này.
Vì vậy, thay vì để tôi sao chép tất cả các cách từ thời điểm này trở đi lên đến req.session.user.
Vì vậy, nếu một phần của req.session.user tôi sẽ sao chép,
và sau đó đến users.js và đăng nhập.
Đó là chính xác làm thế nào tôi sẽ làm xác thực.
Vì vậy, chúng tôi sẽ nói nếu không req.session.user.
Vì vậy, điều đó có nghĩa là người dùng chưa xác thực chính mình.
Sau đó, bạn mong đợi xác thực cơ bản như
là một cơ chế cho người sử dụng để xác thực.
Vì vậy, chúng tôi sẽ nói var AuthHeader nếu! AuthHeader sau đó chúng tôi sẽ nâng cao lỗi,
nếu không chúng tôi sẽ lấy tên người dùng và mật khẩu từ tiêu đề.
Bây giờ, ở đây chúng tôi đã làm nếu tên người dùng bằng admin và mật khẩu bằng mật khẩu.
Nhưng bây giờ, những gì chúng ta sẽ làm là chúng ta sẽ tìm kiếm trong
cơ sở dữ liệu để xem liệu người dùng cụ thể đó tồn tại.
Vì vậy, thay vì làm điều này ở đây,
thay vì làm điều này nếu tên người dùng và mật khẩu,
chúng tôi sẽ nói, user.findone
và chúng tôi sẽ nói tên người dùng là tên người dùng.
Vì vậy, tài sản này là bằng với tên người dùng này mà chúng tôi vừa lấy ra
và sau đó chúng tôi sẽ nói sau đó người dùng.
Vì vậy, bên trong này “sau đó”.
Vì vậy, tôi sẽ di chuyển mã này bên trong này “sau đó” bởi vì
bây giờ những gì tôi sẽ kiểm tra bây giờ rằng tôi đã lấy ra người dùng,
tôi cần phải kiểm tra để đảm bảo rằng người dùng này là chính xác những gì tôi đang tìm kiếm.
Vì vậy, tại thời điểm này,
chúng tôi sẽ kiểm tra đầu tiên để đảm bảo rằng người dùng không phải là null.
Vì vậy, chúng tôi sẽ nói nếu người dùng là null.
Vì vậy, nếu người dùng là null,
vì vậy điều đó có nghĩa là chúng tôi không thể tìm thấy một người dùng với tên người dùng cụ thể đó.
Vì vậy, bạn sẽ phải trả lại một lỗi ở đây.
Vì vậy, hãy để tôi chỉ cần sao chép phần này và sau đó dán nó vào
đây và sau đó chúng tôi sẽ trở lại nói var lỗi mới
và chúng tôi sẽ nói
tên người dùng
không gian không tồn tại.
Vì vậy, trong trường hợp
này, người dùng này không tồn tại vì vậy tôi chỉ cần loại bỏ phần này và
sau đó tình trạng lỗi tương ứng sẽ là 403 ở đây.
Vì vậy, đây là phần đầu tiên.
Nếu người dùng là null thì chúng ta rõ ràng sẽ nói rằng người dùng không tồn tại.
Phần thứ hai chúng tôi sẽ kiểm tra là Khác nếu mật khẩu người dùng.
Vì vậy, điều đó có nghĩa là người dùng tồn tại tại tại thời điểm này.
Vì vậy, kiểm tra thứ hai mà chúng tôi sẽ làm là mật khẩu người dùng không
bằng mật khẩu sau đó.
Chúng ta một lần nữa cần phải chỉ ra lỗi ở đó.
Vì vậy, lỗi sẽ được nói,
trong trường hợp này, chúng tôi sẽ nói
“mật khẩu của bạn là không chính xác”.
Đó là phần thứ hai ở đây.
Vì vậy, mật khẩu của bạn là không chính xác và sau đó là phần cuối cùng.
Chúng tôi sẽ nói “khác”.
Vì vậy, hãy để tôi thụt lề mã này.
Vì vậy, khác nếu user.username
là username mà rõ ràng phải đúng trong trường hợp này.
Sau đó, phần thứ hai,
user.password là bằng mật khẩu mà cũng rõ ràng nên được chính xác tại thời điểm này.
Nhưng trong mọi trường hợp,
tôi sẽ kiểm tra vấn đề đó ở đây và điều này khác sẽ không xảy ra ở tất cả trong trường hợp này.
Vì vậy, vào thời điểm bạn đạt đến thời điểm này,
tên người dùng nên
giống như tên người dùng và mật khẩu nên giống như mật khẩu,
nhưng trong mọi trường hợp tôi đặt trong một kiểm tra lại tại thời điểm đó chỉ để được chắc chắn gấp đôi.
Sau đó, trong trường hợp này,
sau đó chúng ta sẽ nói req.session.user được xác thực.
Vì vậy, chúng tôi sẽ thiết lập điều này để xác thực
và cũng là điều này, chúng tôi sẽ nói
res.StatusCode là 200.
Vì vậy, chúng tôi đã thành công có thể xác thực người dùng.
Vì vậy, chúng tôi sẽ nói res.StatusCode là 200 và sau đó chúng tôi sẽ nói res.Setheader
Content-Type văn bản đồng bằng và
res.end chúng tôi sẽ chỉ đơn giản là gửi một thông báo nói “Bạn đang xác thực”.
Đó là nó. Vì vậy, điều này bao gồm phần sau đó của người dùng FinDone.
Vì vậy, trước tiên, chúng tôi kiểm tra rằng nếu người dùng là null,
điều đó có nghĩa là chúng tôi không thể tìm thấy người dùng,
vì vậy chúng tôi rõ ràng là trả về một lỗi nói rằng tên người dùng không tồn tại.
Nếu mật khẩu của người dùng không khớp với mật khẩu,
vì vậy tại thời điểm này,
người dùng tồn tại nhưng mật khẩu không khớp, vì vậy chúng tôi sẽ nói,
“Mật khẩu của bạn không chính xác”, và sau đó, cuối cùng,
chúng tôi đạt được điểm này sau đó tên người dùng và mật khẩu phải được xác định chính xác.
Mặc dù tôi không cần kiểm tra này nhưng tôi chỉ cần đặt nó ở đó và sau đó tại thời điểm này,
tôi sẽ thiết lập req.session.user để xác thực
nó và sau đó thiết lập mã trạng thái để 200 có nghĩa là bạn đã
thành công có thể xác thực người dùng và sau đó bạn có thể kết thúc tại thời điểm đó.
Bởi vì đây là một sau đó,
tôi sẽ đặt trong một nắm bắt tại thời điểm này, vì
vậy chúng tôi sẽ nói lỗi bắt và nếu lỗi xảy ra,
sau đó tôi sẽ chỉ đơn giản là vượt qua
các lỗi tiếp theo để
xử lý lỗi sẽ có thể đối phó với các lỗi một cách thích hợp.
Vì vậy, kết thúc ra người dùng này FinDone.
Bây giờ, đây là trường hợp khi req.session.user không được thiết lập.
Nếu điều đó đã được thiết lập,
thì điều đó có nghĩa là người dùng đã đăng nhập.
Vì vậy, trong trường hợp này,
phần khác ở đây đề cập đến tình huống nói rằng chúng tôi sẽ thiết lập
StatusCode để 200
và Content-Type để văn bản/đồng bằng và sau đó chúng tôi sẽ nói,
“Bạn đã được xác thực.”
Vì vậy, nếu bạn đạt được phần khác này,
bạn sẽ đến đây vì req.session.user đã không phải là null,
do đó có nghĩa là người dùng đã được xác thực,
do đó, có nghĩa là khi bạn đạt đến điểm này,
sau đó người dùng đã đăng nhập trước đó,
vì vậy bạn không cần phải xác minh.
Vì vậy, bạn sẽ đơn giản nói,
“Bạn đã được chứng thực,” và sau đó kết thúc vào thời điểm này.
Được rồi. Vì vậy, bây giờ, phương pháp cuối cùng mà chúng tôi sẽ thực hiện là để đăng xuất người dùng.
Vì vậy, chúng tôi sẽ làm một router.get trên /logout.
Bạn phải tự hỏi tại sao chúng ta làm một get trên
đăng xuất chứ không phải là một bài mà chúng tôi đã làm trên đăng nhập? Khi
đăng nhập, bạn cần phải gửi tên người dùng và mật khẩu.
Để đăng xuất, bạn chỉ đơn giản
là đăng xuất bản thân khỏi hệ thống, vì vậy bạn không cần phải cung cấp thêm bất kỳ thông tin nào vì máy chủ đã theo dõi
bạn dựa trên ID phiên của bạn và bên trong cookie phiên ở đây.
Vì vậy, đó là lý do tại sao chúng tôi không
rõ ràng cần phải gửi thêm bất kỳ thông tin nào trong nội dung của thông điệp.
Vì vậy, chúng tôi sẽ nói nếu req.session để có nghĩa là phiên phải tồn tại
, nếu không, bạn đang cố gắng để đăng xuất một người dùng chưa đăng nhập.
Vì vậy, nó không có ý nghĩa.
Bây giờ, phiên bản chính nó cung cấp phương thức này
gọi là destroy và khi bạn gọi phương thức destroy,
phiên bị phá hủy và thông tin được gỡ bỏ
từ phía máy chủ liên quan đến phiên này.
Vì vậy, có nghĩa là nếu khách hàng cố gắng gửi lại
thông tin phiên được lưu trữ dưới
dạng cookie đã ký ở phía khách hàng,
điều đó sẽ không hợp lệ.
Vì vậy, chúng ta cần một phương pháp xóa cookie được lưu trữ ở phía khách hàng.
Bây giờ, thao tác này sẽ loại bỏ
thông tin phiên từ phía máy chủ để phiên không còn hợp lệ.
Vì vậy, tại thời điểm này,
chúng tôi sẽ nói req.session.destroy và sau đó chúng tôi sẽ nói, res.ClearCookie.
Vì vậy, ClearCookie là một cách để yêu cầu khách hàng
loại bỏ cookie và tên cookie là ID phiên.
Vì vậy, trong bài tập trước,
chúng tôi thấy rằng cookie đã được lưu trữ với tên của phiên ID ở phía khách hàng.
Vì vậy, chúng tôi đang yêu cầu khách hàng xóa cookie này khỏi
phía khách hàng trong tin nhắn trả lời và sau đó chúng tôi sẽ nói,
res.redirect và chúng tôi sẽ chuyển hướng nó đến trang chủ ở đây.
Vì vậy, đây là một cách chuyển hướng người dùng để nhập trang chuẩn của họ
, ví dụ như trang chủ của ứng dụng của bạn.
Vì vậy, đây là cách bạn sẽ xử lý đăng xuất của hệ thống.
Nếu req.session không tồn tại,
thì điều đó có nghĩa là bạn chưa đăng nhập,
vì vậy chúng tôi sẽ phải tạo ra lỗi.
Vì vậy, chúng tôi sẽ nói var err,
Lỗi mới, “Bạn không đăng nhập”,
và chúng tôi sẽ thiết lập trạng thái lỗi 403,
đây là một hoạt động bị cấm và
sau đó tạo ra lỗi cho trình xử lý lỗi, đó là nó.
Vì vậy, bây giờ, bạn thấy rằng chúng tôi đã mở rộng bộ định tuyến của người dùng để hỗ trợ ba điểm cuối mới, điểm
cuối đăng ký cho phép người dùng đăng ký, điểm
cuối đăng nhập cho phép người dùng đăng ký đăng nhập,
và sau đó là điểm cuối đăng xuất cho phép người dùng đăng nhập đăng nhập đăng xuất khỏi hệ thống.
Trong quá trình đăng xuất,
bạn đang phá hủy phiên ở phía máy chủ,
bạn cũng đang xóa cookie ở phía máy khách,
do đó máy khách không thể được sử dụng trong phiên hết hạn để cố gắng liên hệ với máy chủ đó.
Một điều chỉnh nhỏ trong users.js, điều
này nên được var Người dùng yêu cầu.. /models/user,
nhớ lại rằng tập tin users.js nằm trong thư mục route và sau đó
tập tin user.js nằm
trong thư mục model là lên một cấp độ và sau đó vào thư mục model.
Vậy nên, đây là... /mô hình/người dùng,
do đó, thực hiện điều chỉnh nhỏ, đó là nó.
Chúng tôi đã sửa đổi tệp users.js,
bây giờ điều cuối cùng mà chúng ta cần làm là đi và sửa tệp app.js.
Trong tệp app.js ứng dụng,
nếu bạn duyệt vào tệp app.js,
bạn sẽ thấy rằng chúng tôi có
chỉ số dấu gạch chéo này ở đây và gạch chéo người dùng ở đây sau khi xác thực.
Bây giờ, điều này sẽ không hiệu quả cho chúng tôi bởi vì nếu bạn cần đăng ký,
sau đó người dùng sẽ đăng ký và đăng nhập trước khi ủy quyền được xác nhận,
dù sao nếu đăng ký và đăng nhập là cho quá trình đăng ký,
vì vậy tôi sẽ di chuyển chúng lên trước khi bước xác thực ở đây.
Vì vậy, chúng ta sẽ chuyển nó lên vị trí này.
Vì vậy, do đó, một người dùng đến có thể truy cập
vào tập tin chỉ mục tại dấu gạch chéo và cũng truy cập vào điểm cuối của người dùng mà không được xác thực
, nhưng bất kỳ điểm cuối nào khác,
người dùng phải được xác thực,
vì vậy đó là cách chúng tôi thiết lập này.
Bên trong xác thực chức năng, chúng tôi sẽ nói,
“Nếu không req.session.user”, sau đó nhận thấy rằng nơi này,
chúng tôi sẽ không cho phép người dùng đến đây mà không có người dùng đã đăng nhập.
Vì vậy, nếu không req.session.user,
sau đó chúng tôi sẽ chỉ đơn giản nói rằng bạn không được chứng thực.
Xác thực này phải được thực hiện bằng cách sử dụng phương pháp đăng nhập ở đây.
Vì vậy, tôi sẽ loại bỏ toàn bộ phần này ở đây.
Vì vậy, chúng tôi sẽ nói, nếu không req.session.user,
chúng tôi sẽ nói rằng bạn không được xác thực và vì vậy chúng tôi sẽ phải gửi một bức ảnh ba ở đây,
do đó, có nghĩa là bạn không bao giờ nên đi xuống vào thời điểm này ở
tất cả mà không cần người dùng đăng nhập.
Vì vậy, chúng tôi sẽ nói rằng bạn không được chứng thực.
Nhớ lại rằng bạn cần phải xác thực bản thân bằng cách thực hiện một bài đăng trên
dấu gạch chéo người dùng dấu gạch chéo điểm kết thúc đăng nhập.
Vì vậy, chúng tôi sẽ nói rằng bạn không được xác thực,
nếu không, nếu req.session.user bằng,
nhớ lại rằng trong chức năng đăng nhập trong
users.js chúng tôi đã thiết lập người dùng phiên tiếp theo để chuỗi xác thực.
Vì vậy, đó là những gì chúng ta sẽ kiểm tra.
Chúng tôi sẽ nói, nếu req.session.user được xác thực,
chúng tôi sẽ nói tiếp theo, nếu không bạn không được xác thực một lần nữa.
Sau đó chúng tôi sẽ gửi lại một tin nhắn bị cấm. Đó là nó.
Vì vậy, với bản cập nhật này,
tệp app.js của tôi cũng đã sẵn sàng.
Bây giờ, sau khi thực hiện các bản cập nhật này, chúng
ta hãy đi và kiểm tra cách ứng dụng của chúng tôi hoạt động ngay bây giờ.
Đi đến thiết bị đầu cuối,
nếu máy chủ của bạn đang chạy dừng nó và sau đó khởi động lại máy chủ của bạn.
Máy chủ của tôi không chạy vào lúc này,
vì vậy tôi sẽ nói npm bắt đầu,
và máy chủ của tôi nên được lên và chạy.
Bây giờ chúng ta hãy xem cách chúng ta sẽ truy cập vào máy chủ.
Đi đến Postman, hãy để tôi làm một GET trên
localhost:3000/món ăn và sau đó bạn sẽ ngay lập tức thấy
rằng nó than phiền nói rằng bạn không được chứng thực.
Rõ ràng, tôi không được chứng thực ở đây.
Hãy để tôi cố gắng truy cập chỉ là localhost:3000 và bạn sẽ thấy
rằng, root đó có sẵn cho chúng tôi.
Bây giờ, tất nhiên, chúng tôi muốn đầu tiên đăng ký một người dùng và sau đó đăng nhập với
tư cách là người dùng và sau đó có quyền truy cập vào phần còn lại của các điểm cuối API REST.
Vì vậy, trước tiên, hãy để tôi đăng ký một người dùng.
Để đăng ký người dùng,
tôi cần phải làm một POST cho localhost:3000/users/đăng ký.
Đối với thông điệp POST này,
trong nội dung của thông điệp,
tôi cần phải bao gồm trong nội dung
của thông điệp một chuỗi JSON với tên người dùng.
Vì vậy, hãy để tôi đăng nhập bản thân mình và
sau đó tôi sẽ chỉ sử dụng mật khẩu làm mật khẩu.
Đây là một đăng ký hợp lệ.
Vì vậy, khi tôi đăng ký như là một người dùng với
thông tin này dưới dạng một chuỗi JSON bao gồm trong nội dung của tin nhắn,
hãy để tôi thấy rằng tiêu đề bây giờ chứa nội dung loại ứng dụng,
JSON bởi vì tôi đã thiết lập JSON trong nội dung của tin
nhắn và sau đó gửi POST để đăng ký.
Sau đó, khi tôi gửi POST đến đăng ký,
bạn ngay lập tức thấy những gì được trả lại bởi máy chủ ở đây.
Vì vậy, bạn thấy rằng máy chủ đã trở lại nói,
“Đăng ký thành công” và chính
nó, nó cung cấp cho tôi các chi tiết của người dùng ở đây.
Vì vậy, đây là một bản ghi tồn tại trong MongoDB của tôi và
lưu ý rằng kiểu mô hình là kiểu mô hình người dùng mà chúng tôi đã thiết lập.
Vì vậy, chúng tôi có tên người dùng và mật khẩu và
cờ quản trị như bạn có thể thấy được đặt thành false theo mặc định.
Một khi chúng tôi đăng ký người dùng,
người dùng này bây giờ là người dùng hợp lệ.
Vì vậy, hãy để tôi cố gắng một lần nữa POST cùng một người dùng và xem những gì xảy ra.
Vì vậy, khi tôi POST cùng một người dùng rõ ràng,
có từ phía máy chủ,
nó trả lời nói rằng người dùng này đã tồn tại.
Vì vậy, bạn có thể thấy rằng chúng tôi đã thiết lập thủ tục đăng ký của chúng tôi để không cho phép
người dùng trùng lặp đăng ký với cùng một ID người dùng.
Được rồi. Vì vậy, đó là phần thứ hai.
Bây giờ, chúng ta hãy làm một đăng nhập của người dùng.
Để làm một đăng nhập của người dùng,
hãy để tôi loại bỏ các loại nội dung và sau đó tôi cũng sẽ
loại bỏ các cơ thể bởi vì cho đăng nhập, đó là không cần thiết.
Vì vậy, tôi không điền vào bất cứ điều gì
trong tiêu đề và sau đó cố gắng để đăng nhập và khi tôi cố gắng để đăng nhập,
nó trả lời lại nói rằng bạn không được xác thực.
Anh không được phép.
Bây giờ, tôi cần phải đăng nhập vào bản thân mình.
Vì vậy, đây là nơi tôi có thể sử dụng xác thực cơ bản.
Vì vậy, trong xác thực cơ bản,
tôi chỉ cần nhập tên người dùng và
mật khẩu của tôi mà tôi vừa đăng ký ở bước trước và sau đó cập nhật yêu cầu của tôi,
và sau đó thực hiện một POST trên đăng nhập.
Vì vậy, khi tôi thực hiện một POST trên đăng nhập,
bạn thấy rằng máy chủ trả lời nói, “Bạn được xác thực”.
Vì vậy, tại thời điểm này,
tôi có thể thực hiện các
yêu cầu GET, PUT, POST và DELETE trên tất cả các điểm cuối khác.
Vì vậy, tại thời điểm này, nếu tôi làm một GET trên điểm cuối món ăn,
bạn sẽ thấy rằng điều này trả về
trường trống vì cơ sở dữ liệu của tôi hiện đang trống tại thời điểm này.
Hãy để tôi xóa ủy quyền và cũng từ tiêu đề loại bỏ
ủy quyền và sau đó làm GET và nó là hộp công cụ chỉ tốt.
Vì vậy, bạn có thể thấy rằng bây giờ tôi có thể
truy cập các điểm cuối bởi vì tôi đã đăng nhập bản thân mình.
Vì vậy, bây giờ, hãy để tôi làm một đăng xuất của người dùng.
Vì vậy, chúng ta sẽ nói, localhost:3000 và đăng xuất.
Cũng lưu ý rằng, trong cookie,
một cookie đã được thiết lập tại ID phiên ngay tại đó.
Vì vậy, cookie đó tồn tại trên trang web khách hàng của tôi.
Vì vậy, bây giờ, hãy để tôi đăng nhập bản thân mình ra bằng cách nói GET localhost:3000/users/logout.
Vì vậy, khi tôi làm một đăng xuất khỏi người dùng,
bạn sẽ ngay lập tức thấy rằng tôi được chuyển hướng đến
đó localhost:3000 điểm cuối và cũng nhận thấy rằng cookie đã biến mất.
Vì vậy, khi tôi nhìn vào cookie,
bạn thấy rằng localhost,
cookie đã biến mất bởi vì từ phía máy chủ của tôi khi tôi làm đăng xuất
nó sẽ gửi lại một cookie rõ ràng phần còn lại cho phía khách hàng và do đó cookie đã biến mất.
Bây giờ, nếu tôi cố gắng để làm một GET
trên localhost: 3000/món ăn điểm cuối,
điều này sẽ không làm việc vì tôi không được xác thực.
Vì vậy, điều này cho bạn thấy làm thế nào bạn có thể mở rộng máy chủ Express của bạn
để cho phép người dùng đăng ký bản thân và sau đó cho phép người dùng đăng nhập vào hệ thống,
và sau đó cũng đăng xuất từ hệ thống.
Ở phía máy chủ, bạn đang theo dõi một người dùng đăng nhập bằng cách sử dụng phiên làm
việc và sử dụng cookie ở phía máy khách và khi người dùng đăng
xuất cookie bị phá hủy ở phía máy khách.
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 cam kết,
với thông điệp, Express phiên phần hai.