Thời gian cho bài tập thứ ba trong khóa học này.
Trong mô-đun này, chúng tôi đã tìm hiểu về xác thực người dùng rất nhiều chi tiết.
Bây giờ, trong nhiệm vụ này,
chúng tôi sẽ làm việc thêm về xác thực người dùng.
Chúng tôi sẽ thêm một loại tài khoản khác được gọi là Quản trị viên.
Tài khoản Admin là một tài khoản siêu có
nhiều đặc quyền thực hiện các hoạt động khác nhau.
Một tài khoản người dùng thông thường chỉ có thể thực hiện các thao tác nhất định trên máy chủ của chúng tôi.
Tương tự, một yêu cầu chưa đăng ký đến từ một máy khách
không đăng nhập chỉ có thể thực hiện các thao tác nhất định trên máy chủ của chúng tôi.
Bây giờ, chúng tôi sẽ sửa đổi máy chủ của chúng tôi như vậy
mà get các hoạt động có thể được thực hiện bởi bất cứ ai.
Bạn không cần phải đăng nhập vào hệ thống để thực hiện các thao tác get trên
các điểm cuối API còn lại khác nhau ngoại trừ việc gửi nhận xét.
Đối với các thao tác còn lại trên các điểm cuối API còn lại,
các thao tác POST put và delete,
các thao tác này sẽ bị hạn chế chỉ được thực hiện bởi người dùng quản trị,
một người dùng thông thường không thể thực hiện các thao tác này.
Rõ ràng, bạn không muốn một người dùng bình thường gửi các món ăn mới, hoặc chương trình khuyến mãi,
hoặc thông tin lãnh đạo, hoặc sửa đổi thông tin hiện có,
hoặc thậm chí xóa các thông tin hiện có.
Đây chỉ là đặc quyền của quản trị viên hệ thống cho máy chủ của chúng tôi.
Ngoài ra, chúng tôi sẽ đảm bảo rằng một người dùng thông thường có thể
đăng bình luận về các món ăn cụ thể, đó là chấp nhận được.
Tương tự, một người dùng thông thường có thể cập nhật và xóa các nhận xét mà họ đã đăng.
Người dùng khác hoặc thậm chí là người quản trị không thể cập nhật hoặc xóa nhận xét được đăng bởi người dùng khác.
Vì vậy, đây là một hạn chế khác mà chúng tôi sẽ đặt trong máy chủ của chúng tôi.
Bây giờ, chúng ta hãy đi trước và kiểm tra làm thế nào chúng ta sẽ đi về việc
thực hiện điều này và làm thế nào chính xác máy chủ của chúng tôi thực hiện các hoạt động này.
Trước hết, tôi sẽ minh họa cho bạn cách bạn
tạo một tài khoản quản trị viên trong hệ thống của bạn.
Bạn sẽ nhận ra rằng chúng tôi phải đi đằng sau
hậu trường để tạo một tài khoản quản trị đơn giản bởi vì,
chúng tôi không muốn một tài khoản quản trị viên được tạo ra bằng cách thực hiện
thao tác đăng ký trên tài khoản người dùng/đăng ký của chúng tôi.
Điều này sẽ khiến máy chủ của chúng tôi dễ bị tấn công.
Vì vậy, một tài khoản quản trị chỉ có thể được thiết lập
đằng sau hậu trường bằng cách truy cập trực tiếp vào cơ sở dữ liệu.
Vì vậy, chúng ta hãy nhìn vào cách chúng ta làm điều
này trong hình minh họa mà tôi sẽ cho các bạn thấy ngay sau đó.
Bây giờ, để kiểm tra cơ sở dữ liệu của chúng
tôi, hãy để tôi bắt đầu Mongo Ripple tại dấu nhắc lệnh,
và sau đó đi đến thư mục nhầm lẫn và sau đó cho phép tôi
kiểm tra những người dùng được đăng ký trong cơ sở dữ liệu của tôi tại thời điểm này.
Vì vậy, bạn có thể thấy rằng tôi chỉ có một người dùng đăng ký.
Vì vậy, hãy để tôi thiết lập hai tài khoản bổ sung,
một cho một người dùng thông thường,
và một trong đó sẽ là một quản trị viên.
Vì vậy, chúng tôi sẽ đăng ký quản trị viên và người dùng thứ hai cũng từ điểm đăng ký của chúng tôi,
sau đó họ sẽ trở lại Mongo Ripple và sau đó thiết lập tài khoản quản trị một
cách rõ ràng bằng cách sửa đổi hồ sơ trong cơ sở dữ liệu của chúng tôi.
Đi đến Postman pin,
hãy để tôi đăng ký thêm hai người dùng.
Vì vậy, trước đó chúng tôi đã đăng ký một người dùng với tên này,
vì vậy tôi sẽ đăng ký một người dùng khác vào hệ thống của tôi,
và do đó, một người dùng thứ hai bây giờ đã đăng ký thành công.
Bây giờ, hãy để tôi đăng ký một tài khoản quản trị viên.
Vì vậy, đối với tài khoản quản trị viên,
tôi sẽ thiết lập tên người dùng là quản trị viên và sau đó đăng ký một người dùng quản trị viên.
Vì vậy, chúng ta thấy rằng bây giờ chúng ta đã thêm hai tài khoản mới vào hệ thống của chúng tôi.
Đi đến Mongo Ripple,
hãy để tôi lặp lại
db.user.find () và để tôi làm điều đó khá để nó trông dễ đọc hơn.
Vì vậy, khi tôi làm điều này,
bạn có thể thấy rằng chúng tôi có một tài khoản quản trị viên ở đây với tên người dùng là một quản trị viên.
Bỏ qua tên và họ,
tôi sẽ thiết lập tên và họ này để được giống nhau cho cả ba.
Sau đó, chúng tôi có tài khoản người dùng khác mà tôi đã thiết lập với tên người dùng ở đây
và tài khoản người dùng thứ ba mà chúng tôi đã có trong cơ sở dữ liệu của chúng tôi.
Vì vậy, bây giờ chúng ta có ba tài khoản người dùng;
hai tài khoản người dùng ở đây
và một tài khoản quản trị viên.
Bây giờ, tất nhiên, bạn sẽ thấy rằng trong tài khoản người dùng,
chúng tôi có cờ này gọi là cờ quản trị được đặt thành false cho
bất kỳ tài khoản nào được đăng ký trên điểm cuối /users/đăng ký này.
Đó là cách mặc định mà bạn nên thiết lập tài khoản.
Bạn không thể cho phép người dùng cấu hình tài khoản quản trị
bằng cách thực hiện bất cứ điều gì trực tiếp trên điểm cuối API còn lại.
Thay vào đó, chúng tôi sẽ đi đằng sau hậu trường và sau đó trong Mongo Ripple,
tôi sẽ sửa đổi hồ sơ này cho người dùng quản trị bằng cách
nói db.users.update và sau đó
chúng tôi sẽ cung cấp tên người dùng như quản trị viên ở đây.
Vì vậy, chúng tôi sẽ cập nhật bản ghi câu thơ và sau đó chúng tôi sẽ nói {$set:
nhớ lại cách chúng tôi đã thao tác MongoDB để chúng tôi sẽ
nói {$set: {"admin”: “true”}}.
Vì vậy, những gì chúng tôi đang làm ở đây là chúng tôi đang tìm
kiếm tài khoản người dùng này với quản trị viên tên người dùng,
và sau đó chúng tôi đang thiết lập cờ quản trị thành true
ở đây bằng cách sử dụng tùy chọn $set.
Vì vậy, đây là cách chúng tôi sẽ cập nhật một tài khoản để trở thành một tài khoản quản trị viên.
Vì vậy, bạn thấy rằng điều này đã sửa đổi kết quả.
Vì vậy, chúng ta hãy kiểm tra lại các tài khoản.
Bây giờ, khi bạn kiểm tra tài khoản,
bạn sẽ thấy rằng đối với tài khoản quản trị viên,
cờ quản trị viên bây giờ được đặt thành true,
vì vậy đó là cách bạn sẽ kết thúc tạo một tài khoản quản trị viên.
Bây giờ, tài khoản Admin như chúng tôi mong đợi có các đặc quyền bổ sung.
Vì vậy, một khi bạn hoàn thành nhiệm vụ này sau đó,
bạn sẽ nhận thấy rằng các hoạt động get có thể được thực hiện bởi bất kỳ người dùng trên
/món ăn/món ăn/aspecificdishendt/chương trình khuyến mãi
và /promotions/specificpromotionendpoint và tương tự,
cho các nhà lãnh đạo trong điểm cũng.
Nhưng các hoạt động POST, đặt
và xóa các hoạt động trên các điểm cuối này chỉ có thể được thực hiện bởi người dùng quản trị.
Bây giờ, ngoài ra, điểm cuối ý kiến,
chúng tôi sẽ chỉ cho phép một người dùng đăng ký đã đăng nhập để
truy cập ý kiến cho một món ăn cụ thể,
chúng tôi sẽ cho phép một người dùng đăng nhập để đăng bình luận.
Chúng tôi đã thiết lập điều này trong bài tập vì vậy,
khi người dùng đăng bình luận,
chúng tôi đã đảm bảo rằng chúng tôi xác minh
tính xác thực của người dùng và sau đó khi nhận xét được đăng,
chúng tôi đã thiết lập ID tác giả cho nhận xét bằng cách sử dụng ID người dùng.
Vì vậy, chúng tôi đã hoàn thành điều đó.
Nhưng bây giờ, ngoài ra,
đối với các hoạt động đặt và xóa trên nhận xét,
chỉ có người dùng đã gửi nhận xét cụ thể sẽ được
phép thực hiện đặt và xóa các hoạt động trên nhận xét của riêng mình.
Bất kỳ người dùng nào khác không thể sửa đổi nhận xét của người khác.
Tương tự như vậy, ngay cả người quản trị cũng không thể sửa đổi nhận xét của
người khác, hoặc xóa nhận xét của người khác.
Vì vậy, đó là phần thứ hai của nhiệm vụ mà bạn sẽ thực hiện.
Phần thứ ba là một quản trị viên có thể truy vấn
điểm kết thúc /users và yêu cầu danh sách người dùng đã đăng ký,
không người dùng thông thường nào khác có thể thực hiện truy vấn này.
Vì vậy, đây là một hạn chế khác mà chúng ta sẽ đưa vào đó.
Bây giờ, để xác minh rằng người dùng là quản trị viên,
trước tiên chúng tôi sẽ xác minh rằng người dùng là người dùng đã đăng ký.
Vì vậy, chức năng xác minh người dùng mà chúng tôi đã thực hiện trong
authenticate.js nên được áp dụng ngay cả khi bạn cần kiểm tra quản trị viên.
Trước tiên, bạn kiểm tra xem có phải là người dùng đã xác minh không, sau đó,
bạn sẽ giới thiệu một chức năng khác gọi là VerifyAdmin trong
tập tin authenticate.js mà sẽ kiểm tra để đảm bảo rằng người dùng là người quản trị.
Bây giờ, để kiểm tra xem người dùng có phải là quản trị viên hay không,
tất cả những gì bạn cần làm là kiểm tra rec.user có trên
đối tượng yêu cầu rec.user ở đó,
hãy kiểm tra xem cờ quản trị viên có đúng hay không.
Nếu cờ quản trị là đúng,
bạn sẽ cho phép quá trình bình thường tiến hành hơn nữa để [không nghe được] xảy ra.
Nếu người dùng không phải là quản trị viên,
bạn sẽ tạo ra một lỗi và gửi lại một thông báo lỗi về phía khách hàng.
Vì vậy, đó là cách chúng tôi sẽ xử lý tài khoản người dùng quản trị.
Bây giờ, khi một người dùng đang cố gắng sửa đổi hoặc xóa nhận xét của mình,
chúng tôi phải kiểm tra để đảm bảo rằng tác giả của nhận xét
giống như người dùng đang cố gắng sửa đổi nhận xét.
Bây giờ, rec.user cũng có trường ID,
vì vậy bạn cần phải kiểm tra chéo với trường tác giả của nhận xét.
Nếu hai khớp này,
thì bạn sẽ cho phép người dùng thực hiện các thao tác đặt hoặc xóa.
Nếu họ không khớp,
sau đó bạn sẽ không cho phép đặt hoặc xóa các hoạt động trên nhận xét cụ thể đó.
Vì vậy, đây là khía cạnh khác mà bạn
sẽ thực hiện như là một phần của nhiệm vụ thứ ba của bạn.
Hãy nhìn vào cách tất cả những thứ này hoạt động bằng cách
sử dụng Postman để thực hiện các hoạt động khác nhau trên máy chủ của chúng tôi.
Quay trở lại Postman,
trước tiên tôi thực hiện một thao tác GET trên
các món ăn để chỉ kiểm tra xem những gì có trong cơ sở dữ liệu của tôi.
Vì vậy, nếu tôi thực hiện một hoạt động GET trên các món ăn,
lưu ý rằng tôi không đặt bất kỳ xác thực trong tiêu đề.
GET hoạt động được cho phép bởi bất cứ ai.
Vì vậy, khi tôi thực hiện thao tác GET,
tôi có thể thấy rằng tôi đã có một món ăn với một nhận xét đã có trong món ăn đó.
Nhận xét này đã được đăng bởi người dùng này.
Vì vậy, chúng tôi đã có một món ăn trong hệ thống ở đó.
Vì vậy, điều này là hoàn toàn tốt,
tôi sẽ xóa các món ăn.
Bây giờ, để xóa các món ăn,
rõ ràng rằng hoạt động không thể được thực hiện bởi một người dùng bình thường.
Vì vậy, hãy để tôi đăng nhập như,
vì vậy bạn có thể thấy rằng tôi đang đăng nhập như một người dùng thông thường.
Vì vậy, hãy để tôi đăng nhập với tư cách là một người dùng thông thường.
Vì vậy, khi tôi đăng nhập, tôi sẽ nhận được mã thông báo.
Vì vậy, tôi sẽ sao chép mã thông báo này và lưu nó.
Bây giờ, tôi có mã thông báo của tôi,
hãy để tôi thực hiện một thao tác DELETE trên các món ăn.
Vì vậy, khi tôi đi đến hoạt động DELETE.
Vì vậy, hãy để tôi chọn GET này và sau đó thực hiện một thao tác DELETE với các món ăn.
Trong tiêu đề, hãy để tôi bao gồm ủy quyền ở đây và bạn sẽ nhận thấy
rằng khi chúng tôi dán vào yêu cầu và sau đó gửi ủy quyền DELETE,
bạn sẽ nhận thấy rằng nó ngay lập tức trở lại với thông báo này ở đây,
như bạn có thể thấy trong bản xem trước,
nó nói “Bạn không được ủy quyền thực hiện thao tác này! “
Sau đó, mã lỗi là 403 bị cấm.
Vì vậy, đây là một thông báo đã tạo ra bởi
chức năng VerifyAdmin mà bạn sẽ được thực hiện như là một phần của bài tập này.
Vì vậy, nếu người dùng không phải là quản trị viên,
thì đây là thông báo mà VerifyAdmin của bạn sẽ
tạo ra và nó sẽ không cho phép yêu cầu vượt quá thời điểm đó.
Vì vậy, bạn có thể thấy rằng tôi đã đóng tắt hoạt động DELETE.
Bây giờ, làm thế nào để bạn làm điều này?
Trong mã của bạn, bạn đã thấy rằng để áp dụng VerifyUser,
chúng tôi thiết lập Authenticate.VerifyUser trong các
hoạt động POST, PUT và DELETE.
Bây giờ, bạn có thể chuỗi các middleware cái này đến cái khác.
Vì vậy, chúng ta có thể nói Authenticate.VerifyUser dấu phẩy
và sau đó sau đó bạn có thể nói Authenticate.VerifyAdmin,
để áp dụng VerifyAdmin ngay sau khi VerifyUser.
Vì vậy, nếu bạn muốn một hoạt động được giới hạn chỉ cho người quản trị,
trước tiên bạn làm phần VerifyUser và sau đó ngay lập tức sau đó,
bạn áp dụng phần mềm trung gian VerifyAdmin.
Ngay sau đó. Vì vậy, nếu hai kiểm tra này, đi
qua thành công, sau đó bạn sẽ đi vào thực hiện các hoạt động.
Nếu kiểm tra VerifyAdmin không thành công,
bạn sẽ trả lại thông báo lỗi này như bạn thấy
ở đây và sau đó hủy bỏ hoạt động đó một phần.
Vì vậy, bạn sẽ trả lại lỗi tiếp theo từ VerifyAdmin của bạn,
nếu người dùng không phải là quản trị viên.
Vì vậy, tôi đã chứng minh cho bạn cách bạn sẽ
sử dụng tài khoản người dùng quản trị để hạn chế hoạt động cho một PUT
, POST và DELETE hoạt động.
Điều tương tự, POST và PUT hoạt động cũng sẽ không được phép trên bất kỳ của các n phần.
Bây giờ, để tôi thể hiện khía cạnh khác ở đây.
Vì vậy, bạn đã thấy rằng trong đó,
khi chúng tôi thực hiện thao tác GET,
bạn thấy rằng đã có một bình luận được đăng bởi tên người dùng Jogesh,
người dùng đầu tiên trong hệ thống của tôi.
Bây giờ, tôi sẽ đăng nhập với tư cách là người dùng khác.
Vì vậy, tôi sẽ đăng nhập như vào tài khoản thứ hai của tôi là Muppala và sau đó khi tôi đăng nhập,
tôi lại nhận được mã thông báo.
Vì vậy, để tôi lấy mã này ở đây.
Để tôi sao chép mã thông báo này.
Bây giờ, những gì tôi sẽ làm là tôi sẽ làm một GET trên các món ăn localhost.
Vì vậy, hãy để tôi làm một GET trên các món ăn localhost để cho bạn thấy bình luận cụ thể bên trong đây.
Vì vậy, nhận xét đặc biệt này với ID này.
Vì vậy, những gì tôi sẽ làm là,
tôi sẽ sao chép ID món ăn đó.
Tôi cũng sẽ sao chép ID nhận xét từ đây và tôi sẽ thực hiện
một hoạt động DELETE trên món ăn cụ thể này
và nhớ lại rằng chúng ta có
dấu gạch chéo ý kiến và sau đó ID nhận xét đặc biệt này.
Bây giờ, hãy nhớ rằng bình luận này đã được đăng bởi tên người dùng này,
nhưng bây giờ tôi đã đăng nhập vào bản thân mình như là người dùng khác với một tên người dùng khác.
Vì vậy, khi bây giờ tôi thực hiện thao tác DELETE bằng cách sử dụng tài khoản khác,
bạn sẽ ngay lập tức nhận thấy rằng ở đây nó nói,
“Bạn không được phép xóa nhận xét này! “
Sau đó, nó nói 403, cùng một điều.
Nếu bạn cố gắng thực hiện một thao tác PUT trên nhận xét cụ thể đã đăng nhập với tư cách người dùng khác
, nó sẽ nói, “Bạn không được phép cập nhật nhận xét này!”
Vì vậy, cả PUT, DELETE và UPDATE nhận xét của người khác đều không được phép.
Vì vậy, bây giờ, hãy để tôi đăng nhập như quản trị viên tại thời điểm này và sau đó cho phép tôi cố gắng để xóa
nhận xét cụ thể và bạn sẽ thấy rằng cùng một thông điệp sẽ được tạo ra.
Vì vậy, một quản trị viên cũng không thể xóa hoặc cập nhật ý kiến của người khác.
Vì vậy, để đăng nhập như một quản trị viên,
hãy để tôi đi vào POST ở đây và sau đó cho phép tôi đăng nhập như một quản trị viên.
Bây giờ, hãy nhớ rằng các thẻ này sẽ có giá trị trong 33,600 giây.
Vì vậy, bạn có thể lưu các thẻ ba mà bạn tạo ra cho ba người dùng.
Vì vậy, bạn không cần phải tiếp tục đăng nhập với tư cách là người dùng cụ thể đó.
Miễn là bạn sử dụng đúng mã thông báo trong tiêu đề, các
hoạt động của bạn sẽ thực hiện tốt xác định ba người dùng khác nhau.
Vì vậy, hãy để tôi đăng nhập với tư cách là quản trị viên ở đây.
Vì vậy, khi tôi đăng nhập với tư cách quản trị viên,
tôi nhận được mã thông báo ở đây.
Vì vậy, tôi sẽ sao chép và lưu mã thông báo này.
Chỉ cần nhớ mã thông báo nào thuộc về ai khi bạn tạo một bản sao của điều này.
Bây giờ, quay trở lại này, xóa hoạt động bình luận.
Tôi sẽ đi vào tiêu đề và sau đó tôi sẽ thay đổi điều này để mã thông báo cho
quản trị viên và sau đó cố gắng thực hiện thao tác DELETE tương tự và sau đó bạn thấy
rằng ngay cả quản trị viên không được phép xóa nhận xét được đăng bởi người dùng khác.
Điều này hoàn toàn chấp nhận được.
Nhưng chúng ta hãy cố gắng xóa cùng một nhận xét,
bởi người dùng này đã tạo ra
nhận xét đó và bạn sẽ thấy rằng điều đó có thể được thực hiện thành công.
Vì vậy, chúng ta hãy thực hiện thao tác đó.
Vì vậy, để làm điều đó, tôi sẽ quay trở lại và lấy mã thông báo mà tôi đã
nhận được cho người dùng đầu tiên và sau đó thay đổi trường ủy quyền.
Bây giờ, cho hoạt động DELETE này,
tôi sẽ thay đổi điều này để mang,
và sau đó đây là mã thông báo cho người dùng đầu tiên với tên người dùng Jogesh.
Vì vậy, khi tôi cố gắng xóa nhận xét đó,
bạn sẽ nhận thấy rằng nhận xét bây giờ bị xóa thành công.
Vì vậy, như bạn có thể thấy từ các bước,
nhận xét chỉ có thể bị xóa bởi người dùng đã tạo nhận xét đó.
Bây giờ, bước tiếp theo,
khi chúng tôi thực hiện thao tác DELETE trên các món ăn,
chúng tôi đã thấy trước đó rằng nếu chúng tôi đã thực hiện thao tác DELETE như một người dùng thông thường,
bạn sẽ nhận được một thông báo nói,
“Bạn không được phép thực hiện thao tác này!”
Vì vậy, tôi sẽ thay đổi mã thông báo này thành mã thông báo của quản trị viên và sau đó
cho bạn thấy rằng một quản trị viên có thể thực hiện thao tác DELETE trên các món ăn và nồi.
Vì vậy, đi vào yêu cầu này,
hãy để tôi thay đổi mã thông báo để là mã thông báo cho người dùng quản trị.
Vì vậy, khi tôi thực hiện thao tác DELETE như người dùng quản trị,
bạn sẽ nhận thấy rằng thao tác DELETE là
thành công và sau đó trả lời lại với thông báo ở đây.
Bây giờ, khi tôi làm một GET trên điểm cuối món ăn,
bạn sẽ nhận thấy rằng các hoạt động GET cho thấy rằng các món ăn của tôi đã được làm trống.
Bây giờ, các hoạt động khác mà bạn cũng sẽ thực hiện trong nhiệm vụ này,
là chúng ta có thể làm một hoạt động GET trên điểm cuối người dùng gạch chéo.
Vì vậy, khi bạn thực hiện một thao tác GET trên điểm cuối của người dùng gạch chéo,
bạn sẽ nhận thấy rằng nếu bạn không phải là một người dùng được ủy quyền,
nó sẽ nói rằng bạn không được phép thực hiện thao tác này.
Vì vậy, localhost:3000/users/endpoint,
bây giờ bạn sẽ cho phép điều này được thực hiện chỉ bởi quản trị viên.
Vì vậy, nếu một người dùng thông thường,
nếu bạn đăng nhập như một người dùng thông thường với tiêu đề,
bạn sẽ không được phép thực hiện thao tác này.
Bây giờ, hãy để tôi thay đổi mã thông báo này thành mã thông báo
ra khỏi quản trị viên và sau đó bạn sẽ thấy rằng
quản trị viên sẽ được phép thực hiện thao tác này.
Vì vậy, đi đến GET,
hãy để tôi thay đổi mã thông báo này thành mã thông báo cho
người dùng quản trị và sau đó khi tôi thực hiện thao tác GET trên đó, nó sẽ trả về.
Như bạn có thể thấy, ba người dùng được đăng ký trong hệ thống của tôi,
nó hiển thị số người dùng một,
số người dùng hai và số người dùng ba.
Tất nhiên, nhận thấy rằng băm và muối được loại bỏ,
khi thông báo được trả về bởi phía máy chủ cho phía máy khách.
Vì vậy, thông tin băm và muối sẽ không bao giờ được tiết lộ bên ngoài.
Vì vậy, người Mông Cổ sẽ tự động chăm sóc lọc
ra thông tin đó trước khi nó gửi lại thông tin của người dùng.
Vì vậy, bởi vì bạn không nên tiết lộ thông
tin băm và muối cho thế giới bên ngoài.
Vì vậy, đây là thông tin tài khoản người dùng ba được trả lại.
Vì vậy, điều này được trả lại chỉ khi bạn thực hiện các thao tác GET
trên điểm cuối người dùng gạch chéo như người dùng quản trị.
Nếu bạn thực hiện yêu cầu tương tự như bất kỳ người dùng nào khác,
điều này sẽ không được phép.
Vì vậy, một lần nữa bạn sẽ kiểm tra đầu tiên,
VerifyUser và sau đó kiểm tra VerifyAdmin và chỉ khi nó là một quản trị viên,
sau đó thao tác này có thể được thực hiện trên điểm kết thúc này.
Vì vậy, đây là tất cả các nhiệm vụ khác nhau mà bạn sẽ làm như một phần của nhiệm vụ này.
Các chi tiết về cách này cần phải được thực hiện được ghi lại trong hướng dẫn phân công.
Vì vậy, đọc qua các hướng dẫn trước khi bạn tiến hành để hoàn thành nhiệm vụ thứ ba.
Hãy vui vẻ hoàn thành nhiệm vụ thứ ba.