kênh này kênh dạy hay nhất về lập trình. nói rõ ràng, sư phạm, dễ hiểu và rất đầy đủ cho người mới, rất có tâm. mong bạn phát huy và ra thật nhiều video , mình sẽ xem hết , chắc chắn kênh này sẽ phát triển lớn. mấy kênh khác chỉ dạy qua loa, k giống như làm thực tế !
Cảm ơn anh đã ra những video này. Nó giúp em rất nhiều trong những ngày đầu đi làm ngáo ngơ :v Mong anh luôn giữ nhiệt huyết và ra thêm nhiều video. Cảm ơn anh rất nhiều
anh em có hỏi sao đoạn 38:50, từ lần 2 post nên trong user có cả key refeshToken:'token key' lại bị chuỗi dài loằng ngoằng ra vậy? có phải là do dữ liệu đầu vào của jwt.sgin(user) cài nhiều ký tự, thì đoạn token key càng dài ra đúng k?
Anh cho e hỏi, e dùng dịch vụ Firebase Cloud Message để push notification từ server api Spring Boot sang android thì được, còn sang web frontend thì phải làm sao ạ ?. E làm mô hình 3 tier có máy chủ chạy front-end Reactjs nhưng chưa hiểu push qua thế nào. Mong a có clip hướng dẫn về FCM cho web app ạ.
Bạn ơi mình có thắc mà nếu mà người dùng đăng nhập từ nhiều nơi và nhiều thiết bị, mà mỗi lần đăng nhập refresh token đc update lại vậy những người dùng trên thiết bị cũ cái refresh token trong database đã bị thay đổi mất rồi thì sẽ bị out ra đúng không, và có cách nào khắc phục được không? Mình thấy nhiều hệ thống cho đăng nhập từ rất nhiều nơi và nhiều thiết bị. Mình cảm ơn
Ở route POST/token có nhất thiết phải verify refresh token ko anh? Khi mình check có refreshToken truyền lên, check được nó là chính xác và tìm ra được user rồi thì tác dụng của verify là gì thế anh?
verify cho đầy đủ và an toàn thôi bạn, tránh ví dụ ông dev nào táy máy sửa cái refreshToken được lưu lại thành một cái jwt token bậy bạ nào đó chẳng hạn.
Video của anh rất hay, nhưng anh cho em hỏi là khi người dùng logout thì chỉ xóa refresh_token, vậy người ta nếu có access_token chưa hết hạn thì vẫn có thể vượt qua middleware verifyToken đúng không anh
Đúng, đầy đủ ra thì phải xóa accessToken, nhưng đó là việc của client. Trong bài này chỉ lập server thôi, nên server có muốn xóa accessToken cũng k được, vì server đâu có lưu accessToken đâu.
Bạn cho mình hỏi chút, vậy là cái refresh token sinh ra chủ yếu để khi vào các route có verify Token thì xin lại accessToken thôi à? Các route sẽ verify bằng accessToken hay refreshToken?
refreshToken để phía front-end giữ lại, khi nào thấy accessToken sắp hết hạn thì mang refreshToken đi gửi tới /token để nhận accessToken mới, tránh việc người dùng bị đăng xuất. Các route sẽ được bảo vệ bằng accessToken. refreshToken chỉ có nhiệm vụ duy nhất là sử dụng để xin lại accessToken.
Bạn có thể nhồi thêm payload vào refreshToken , thay đổi thuật toán mã hóa cho refreshToken, vân vân, tùy hoàn cảnh cụ thể. Nhưng làm gì thì cuối cùng miễn là verify được refreshToken là được.
Em có chút câu hỏi 1- tại sao khi run `/token` lại phải tạo lại refreshToken 1 lần nữa ? nếu vậy thì refresh token cứ tạo mới tạo mới liên tục mỗi lần gọi /token vậy thì biết khi nào mới expired á anh ? (trừ tình huống login xong để quá time expired refresh token khi lần refresh token trước đó hết rồi gọi /token mới fail) 2- tại sao lại cần lưu refreshToken lại vào `users` ? bởi nếu ta decode ra được thì bản chất đã verify được refresh token rồi mà ? 3- Giả sử người ta ở máy 1 login có refresh token là A, sang máy B refresh token là B, làm sao login và sử dụng cả ở 2 máy ? Rất mogn anh giải đáp
1/ khi refreshToken hết hạn thì ở phía client yêu cầu người dùng login lại để lấy access lẫn refresh 2/ lưu refreshToken vào DB để có nhỡ hacker nó fake refreshToken(bằng 1 cách thần thành nào đó :v) thì mình lấy Token của hacker rồi so sánh với Token của mình ở trong DB, nếu không giống với token trong db thì bắt người dùng login lại tiếp, kiểu để refresh token trong db sẽ bảo mật hơn
Chắc vì video có thời hạn cũng như anh Henry chưa nghĩ đến trường hợp đăng nhập ở nhiều máy, mình nghĩ mỗi lần đăng nhập thì mình cứ xóa refresh token ở trong db ở máy 1, rồi cập nhập refresh token ở máy 2 vào, giống như chơi CF game vậy , ai vào sau thì đá người trước ra,🤣🤣
cho em hỏi chút là khi nào thì token hết hạn thì mminhf posst lene ở bên client à anh, dựa vào cái mesage mà server trả về 2. Cái Bearner là gì vậy sao, tại sao mình lại phải thêm cái đó
à ở phía client thì cần phải có kiểu đếm ngược khi gần hết hạn thì gửi request tới /token. Bearer là kiểu quy tắc truyền thống người ta thường hay viết như vậy thôi bạn.
ý bạn là sao mình chưa hiểu lắm, login thì sẽ trả về accessToken, còn ở front-end ta lưu vào đâu, hay là chúng ta đính kèm accessToken như thế nào vào header để truy xuất dữ liệu, thì đó là việc của front-end rồi, sẽ có video khác nói về cái này :D
Có, nhờ cái option revalidate trong getStatic... đó bạn, trong video mình cũng có dùng đến đó. nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration
anh cho em hỏi như khi mình tạo ra accessToken và refreshToken thì nó có lưu vào database hay ở đâu k mà nó có thể kiểm tra lại được là token đó của chính mình tạo v ạ ?
ý của e là khi mình kết hợp với Frontend thì mình sẽ viết code để gọi đến app.post(/tocken) khi mà accessTocken ban đầu hết hạn. Như thế là mình lại có accessaTocken mới. Em hiểu như thế này đúg k ạ?
@@anhthao12d15 đúng bạn, ở front-end cần có cơ chế quan sát xem lúc nào accessToken sắp hết hạn thì gửi request tới /token để xin accessToken mới, tránh cho người dùng bị đăng xuất.
@@anhthao12d15 bạn có thể đọc ở đây, đoạn //response interceptor to refresh token on receiving token expired error Bài này hình như nó sử dụng là cứ gửi request tới /post chẳng hạn, server sẽ báo lại là accessToken expire rồi, khi đó client sẽ lục đục chạy đi kiếm refreshToken, gửi lại server để xin cái accessToken mới. Còn đâu mình cũng đã nhìn thấy code đếm ngược thời gian hết hạn ở phía client nhưng lâu rồi giờ lục lại cũng khó.
vì sao mình lại tách ra 2 server 1 bên login riêng vậy anh. Và trong những dự án thực tế thì người ta có hay tách ra không ạ. Mong a trả lời em cảm ơn !
Thì mục đích của nó chính là để như vậy mà bạn. Thế nên mới cần phải bảo mật access token để không bị ăn trộm. Bạn có thể xem thêm hướng dẫn Full Stack nhé.
kênh này kênh dạy hay nhất về lập trình. nói rõ ràng, sư phạm, dễ hiểu và rất đầy đủ cho người mới, rất có tâm. mong bạn phát huy và ra thật nhiều video , mình sẽ xem hết , chắc chắn kênh này sẽ phát triển lớn. mấy kênh khác chỉ dạy qua loa, k giống như làm thực tế !
cảm ơn bạn nhé :3
Video chuẩn mực.
Không quá nhiều lý thuyết, tập trung code và giải thích.
Chủ đề đa dạng từng góc gách của trang web.
Chúc anh thành công hơn nhé!
cảm ơn a, 2025 xem lại qá hay
kênh này hay quá, nói ngắn gọi dễ hiểu, thực hành xúc tích, mong ra video nhiều hơn, rất ủng hộ kênh ạ ^^
Cảm ơn anh đã ra những video này. Nó giúp em rất nhiều trong những ngày đầu đi làm ngáo ngơ :v Mong anh luôn giữ nhiệt huyết và ra thêm nhiều video. Cảm ơn anh rất nhiều
Bài giảng rất đầy đủ, thực tế !
Ủng hộ chủ kênh nhé
Xem lần thứ n về refresh token, cuối cùng cx hiểu
xin đa tạ vị Huynh Đài :x
anh em có hỏi sao đoạn 38:50, từ lần 2 post nên trong user có cả key refeshToken:'token key' lại bị chuỗi dài loằng ngoằng ra vậy? có phải là do dữ liệu đầu vào của jwt.sgin(user) cài nhiều ký tự, thì đoạn token key càng dài ra đúng k?
Rất hay, cám ơn bạn nhiều
Cảm ơn anh về bài giảng!
Cảm ơn video của anh rất nhiều ạ
Hay quá anh
Video rất hữu ích, cảm ơn anh rất nhiều ♥
Thầy dạy hay quá
Anh cho e hỏi, e dùng dịch vụ Firebase Cloud Message để push notification từ server api Spring Boot sang android thì được, còn sang web frontend thì phải làm sao ạ ?. E làm mô hình 3 tier có máy chủ chạy front-end Reactjs nhưng chưa hiểu push qua thế nào. Mong a có clip hướng dẫn về FCM cho web app ạ.
Bạn ơi mình có thắc mà nếu mà người dùng đăng nhập từ nhiều nơi và nhiều thiết bị, mà mỗi lần đăng nhập refresh token đc update lại vậy những người dùng trên thiết bị cũ cái refresh token trong database đã bị thay đổi mất rồi thì sẽ bị out ra đúng không, và có cách nào khắc phục được không? Mình thấy nhiều hệ thống cho đăng nhập từ rất nhiều nơi và nhiều thiết bị. Mình cảm ơn
Em cảm ơn thầy ạ.
Khi đi làm bên của a thường check token die ở phía client ntn vậy ah? Như lưu time expired hay check theo từng request, thanks a :D
Khúc 45:00 sao anh k cho cái thời hạn token access no dài hơn , kiểu lúc đó anh làm video hơi rối
Ở route POST/token có nhất thiết phải verify refresh token ko anh? Khi mình check có refreshToken truyền lên, check được nó là chính xác và tìm ra được user rồi thì tác dụng của verify là gì thế anh?
verify cho đầy đủ và an toàn thôi bạn, tránh ví dụ ông dev nào táy máy sửa cái refreshToken được lưu lại thành một cái jwt token bậy bạ nào đó chẳng hạn.
dạ vâng em cảm ơn anh.
Video hay qúa ạ. Bao giờ thì có video mới vậy ạ
video sắp tới sẽ là TS trong React nhé bạn
Video của anh rất hay, nhưng anh cho em hỏi là khi người dùng logout thì chỉ xóa refresh_token, vậy người ta nếu có access_token chưa hết hạn thì vẫn có thể vượt qua middleware verifyToken đúng không anh
Đúng, đầy đủ ra thì phải xóa accessToken, nhưng đó là việc của client. Trong bài này chỉ lập server thôi, nên server có muốn xóa accessToken cũng k được, vì server đâu có lưu accessToken đâu.
Bạn cho mình hỏi chút, vậy là cái refresh token sinh ra chủ yếu để khi vào các route có verify Token thì xin lại accessToken thôi à? Các route sẽ verify bằng accessToken hay refreshToken?
refreshToken để phía front-end giữ lại, khi nào thấy accessToken sắp hết hạn thì mang refreshToken đi gửi tới /token để nhận accessToken mới, tránh việc người dùng bị đăng xuất.
Các route sẽ được bảo vệ bằng accessToken. refreshToken chỉ có nhiệm vụ duy nhất là sử dụng để xin lại accessToken.
@@HenryWebDev mình lưu refresh Token ở đâu a nhỉ
em thấy anh gen accessToken và refreshToken cùng bằng 1 hàm, 1 thuật toán. Vậy có cách nào để gen ra refreshToken bằng cách khác không ạ
Bạn có thể nhồi thêm payload vào refreshToken , thay đổi thuật toán mã hóa cho refreshToken, vân vân, tùy hoàn cảnh cụ thể. Nhưng làm gì thì cuối cùng miễn là verify được refreshToken là được.
Em có chút câu hỏi
1- tại sao khi run `/token` lại phải tạo lại refreshToken 1 lần nữa ? nếu vậy thì refresh token cứ tạo mới tạo mới liên tục mỗi lần gọi /token vậy thì biết khi nào mới expired á anh ? (trừ tình huống login xong để quá time expired refresh token khi lần refresh token trước đó hết rồi gọi /token mới fail)
2- tại sao lại cần lưu refreshToken lại vào `users` ? bởi nếu ta decode ra được thì bản chất đã verify được refresh token rồi mà ?
3- Giả sử người ta ở máy 1 login có refresh token là A, sang máy B refresh token là B, làm sao login và sử dụng cả ở 2 máy ?
Rất mogn anh giải đáp
1/ khi refreshToken hết hạn thì ở phía client yêu cầu người dùng login lại để lấy access lẫn refresh
2/ lưu refreshToken vào DB để có nhỡ hacker nó fake refreshToken(bằng 1 cách thần thành nào đó :v) thì mình lấy Token của hacker rồi so sánh với Token của mình ở trong DB, nếu không giống với token trong db thì bắt người dùng login lại tiếp, kiểu để refresh token trong db sẽ bảo mật hơn
Chắc vì video có thời hạn cũng như anh Henry chưa nghĩ đến trường hợp đăng nhập ở nhiều máy, mình nghĩ mỗi lần đăng nhập thì mình cứ xóa refresh token ở trong db ở máy 1, rồi cập nhập refresh token ở máy 2 vào, giống như chơi CF game vậy , ai vào sau thì đá người trước ra,🤣🤣
cám ơn ạ
cho em hỏi chút là khi nào thì token hết hạn thì mminhf posst lene ở bên client à anh, dựa vào cái mesage mà server trả về
2. Cái Bearner là gì vậy sao, tại sao mình lại phải thêm cái đó
à ở phía client thì cần phải có kiểu đếm ngược khi gần hết hạn thì gửi request tới /token.
Bearer là kiểu quy tắc truyền thống người ta thường hay viết như vậy thôi bạn.
khi mà login thì token có tự động được lưu vào header ko a ?
ý bạn là sao mình chưa hiểu lắm, login thì sẽ trả về accessToken, còn ở front-end ta lưu vào đâu, hay là chúng ta đính kèm accessToken như thế nào vào header để truy xuất dữ liệu, thì đó là việc của front-end rồi, sẽ có video khác nói về cái này :D
@@HenryWebDev có video đó chưa a
anh ơi cho e hỏi về nextjs với , hàm getStaticProps , getStaticPath sẽ lấy cập nhật được data khi data đó thay đổi ko ạ như thêm xóa sửa
Có, nhờ cái option revalidate trong getStatic... đó bạn, trong video mình cũng có dùng đến đó.
nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration
@@HenryWebDev tks kiu bro
Anh ơi lỡ reftoken nó hết hạn sau 1 tiếng thì user làm sao gửi lên được ạ?
thì ở front-end thường có code kiểm tra xem lúc nào gần hết hạn thì gửi request đi để xin cái accessToken mới
@@HenryWebDev dạ vâng
Anh ơi, thế nếu bị lộ cả refresh-token nữa thì người ta vẫn có thể truy cập vào thông tin của mình đúng không ạ
Thì có logout đó bạn
anh cho em hỏi như khi mình tạo ra accessToken và refreshToken thì nó có lưu vào database hay ở đâu k mà nó có thể kiểm tra lại được là token đó của chính mình tạo v ạ ?
Lưu vài localstorage
ah cho e hỏi là khi nào thì app.post(/tocken) sẽ được gọi ạ.
mình chưa hiểu ý bạn hỏi lắm :-?
ý của e là khi mình kết hợp với Frontend thì mình sẽ viết code để gọi đến app.post(/tocken) khi mà accessTocken ban đầu hết hạn. Như thế là mình lại có accessaTocken mới. Em hiểu như thế này đúg k ạ?
@@anhthao12d15 đúng bạn, ở front-end cần có cơ chế quan sát xem lúc nào accessToken sắp hết hạn thì gửi request tới /token để xin accessToken mới, tránh cho người dùng bị đăng xuất.
A có code ví dụ ở phía Frontend k ạ? E vẫn chưa hình dung đc ở Frontend mình sẽ gọi app.post(/tocken) như nào ạ.
@@anhthao12d15 bạn có thể đọc ở đây, đoạn //response interceptor to refresh token on receiving token expired error
Bài này hình như nó sử dụng là cứ gửi request tới /post chẳng hạn, server sẽ báo lại là accessToken expire rồi, khi đó client sẽ lục đục chạy đi kiếm refreshToken, gửi lại server để xin cái accessToken mới.
Còn đâu mình cũng đã nhìn thấy code đếm ngược thời gian hết hạn ở phía client nhưng lâu rồi giờ lục lại cũng khó.
vì sao mình lại tách ra 2 server 1 bên login riêng vậy anh. Và trong những dự án thực tế thì người ta có hay tách ra không ạ. Mong a trả lời em cảm ơn !
micro service á, b lên search thử
hơi dối não a ạ , e xem đi xem lại nhiều lần mà vẫn mơ màng
Hướng dẫn này bị kẽ hở, k an toàn, tròng vòng 5 phút, cái accessToken jwt còn thời gian nếu họ có được, bắn nên vẫn lấy được danh sách posts
Thì mục đích của nó chính là để như vậy mà bạn. Thế nên mới cần phải bảo mật access token để không bị ăn trộm. Bạn có thể xem thêm hướng dẫn Full Stack nhé.
cám ơn anh nha