Ở 35:05 anh nói "chúng ta lưu accessToken ở server" em chưa hiểu, nếu lưu trên server là lưu trên RAM chẳng phải nếu mỗi lần deploy thì data sẽ bị mất hay sao ? đoạn này em chưa hiểu - Mong anh là một video nữa về cách lưu trữ accessToken + refreshToken như thế nào cho phù hợp.
cho em hỏi là tại sao thường thấy anh check if là (msg && msg === 'jwt expired') mình không phải chỉ cần check trường hợp msg === 'jwt expired' là ok rồi sao anh
Cho e hỏi, có 1 api lấy danh sách người dùng. Khi api bắt đầu được thực thi thì phát hiện access token hết hạn, khi đó server sẽ trả về code 401. Tiếp theo axios sẽ thực thi interceptor.response để lấy lại access token và set vào Locastorage thành công. Rồi làm sao cái api đó có thể tiếp tục chạy lại lần nữa để tự động lấy danh sách người dùng và hiện lên giao diện. Rõ ràng là Interceptor của axios chỉ có nhiệm vụ lấy lại token và gán vào Locastorage. Rất mong được admin và mọi người trả lời.
@@anonystick Hay quá, e cảm ơn ạ. 🤩. Thành công bước đầu hoàn thành cơ chế refresh token, tuy vẫn thiếu xót chưa hiểu mấy cú pháp và cơ chế hoạt động của thằng Interceptor axios lắm. Nhưng thực sự cảm ơn video của thầy rất nhiều.
@@anonystick Có một vấn đề nữa, e chưa tìm được lời giải ở đâu, đó là. Khi 1 api "get" thì refresh token vẫn hoạt động bình thường. Nhưng 1 api "post" (api cần đưa dữ liệu lên server) được gọi mà token hết hạn. Sau đó Interceptor tiếp tục lấy token thành công. Nhưng khi api post được gọi lại thì dữ liệu req.body bị null hoàn toàn thì mình giải quết như thế nào vậy thầy.
Mình thì không khuyến khích lắm với việc lưu cả AccessToken vào DB hoặc nơi nào đó trên server khi đã lưu RefreshToken dù đồng ý là nó sẽ dễ dàng revoke (nhưng đa số trường hợp là không cần thiết). Thứ 1 nó sẽ khiến cho ứng ụng stateful (trong Rest thì điều này là vi phạm). Thứ 2 thì với mỗi Request lên server đều phải check database hoặc cache để kiếm tra AccessToken (Đây lại là nhược điểm của Session so với JWT, vậy tại sao phải khiến JWT có thêm nhược điểm này ?). Tóm lại đây là quan điểm của mình, các bạn có thể tham khảo.
Mình nghĩ là tùy yêu cầu hệ thống. sẽ có trường hợp cụ thể như sau : 1. Mình cần loại bỏ tất cả access token và refresh token của 1 user cụ thể sau khi user bị deleted. 2. Mình cần buộc phải loại bỏ tất cả access token và yêu cầu client refresh lại token để thay đổi roles/permissions trong token sau khi admin thay đổi roles/permissions của 1 user.
ปีที่แล้ว
Đồng ý, nếu phải lưu access token vào db thì m dùng session luôn cho rồi
@@anonystick cũng ko được luôn thầy ơi. Em kiểm tra network thì thấy sau khi nó gọi refreshToken thành công, lưu trong localstorage cũng thành công xong nó dừng lại , ko thực hiện tiếp việc gọi lên server lấy users.🥲
anh cho em hỏi nếu xử lý theo cơ chế này thì việc trả về refresh token sau khi login và lưu refresh token vào Redis có còn cần thiết không ạ ? thay vào đó sẽ chỉ lưu access token trong redis để dễ dàng revoke. em đang xử lý refresh token bằng cách, nếu token đó hết hạn, thì sẽ gửi request cấp access token mới với thông tin ng dùng (vd: email và id) -> check database nếu có thông tin người dùng tương ứng sẽ cấp token mới ok -> clone lại request trước đó đã failed (do lỗi 'jwt expired') fail -> logout theo a cách này có ổn không ạ ? rất mong được anh giải đáp
@@anonystick anh cho e hỏi, nếu sử dụng refresh token được tạo ra khi đăng nhập để xác thực người dùng sau đó cấp lại access token mới nếu access token đó hết hạn, vậy trong trường hợp refresh token đó hết hạn sẽ bắt người dùng phải đăng nhập lại ạ ?
Thầy ơi, cho em hỏi trong video hình như bị thiếu bước 4 đúng không ạ, vì sau khi refreshToken để có accessToken mới rồi thì sẽ tiếp tục gọi cái api cũ tiếp để get resource đúng không ạ. Nếu chỉ đến bước 3 là lấy token xong rồi set vào local storage là người dùng click get data xong thì UI nó đứng im, phải click thêm một cái nữa thì nó mới get được data thì phải.
@@PhongNguyen-ho7oj Bạn có thể giải thích cụ thể được không, mình đang chưa hiểu sao mà sau khi chạy refeshToken thì data trả về là success mà vẫn vào qua 2 cái check if đó
thầy ơi cho em hỏi là tự trả về token mới mỗi lần hết hạn như vậy thì khi mình đưa token cho người khac hoặc lỡ lưu token ở một máy tạm nào đó là cái máy đó luôn truy cập vào được tài khoản của mình đúng không ạ? Vì dù token có hết hạn thì nó cũng tự refresh lại mà đúng không thầy, vậy hết hạn cũng giống như không hết hạn đúng không ạ thầy.
Thật ra nếu Token bị chiếm thì không thể mãi mãi được. Nếu AccessToken bị lộ thì sẽ hết hạn nhanh vì sao lại hết hạn nhanh thì bạn xem lại video trước, còn FreshToken (FT) mà bị lộ thì nguy hiểm hơn chút nhưng không có nghĩa là chiếm mãi mãi, vì hệ thống được bảo mật tốt sẽ cho chúng ta biết FT được truy cập ở một thiết bị lạ or một location khác...
Vâng cám ơn anh, em cũng nghĩ là khi tạo token cần bổ sung các định danh phụ như IP, Divice, Location ... nếu phát hiện token được requets từ định danh không trùng khớp với lúc tạo sẽ block token luôn hoặc yêu cầu Xác thực hai yếu tố (2FA)
ví dụ có 100 request trên fe hết hạn cùng lúc thì mình có thể chỉ cho 1 request refresh token xuống server rồi 99 thằng kia đợi lấy từ thằng 1 rồi xài chung được không a?
Anh nghĩ sao về việc token sẽ lưu ở local còn refreshtoken lưu ở cookie, khi gửi request lên thì gửi cả 2 thằng này,...nếu hết hạn thì server tự lấy refreshtoken trong cookie gửi lên để làm mới lại token gửi về lại cho client ạ?
Mình nghĩ vì session chỉ lưu đc trên 1 server . Mà hiện nay 1 web có nhiều server vì vậy để login 1 ở 1 server bất kỳ , mà tất cả server biết thì cách hiện nay là dùng jwt. ,mà khi request lên server (chưa biết server nào ) thì làm sao lấy đc refreshtoken. Mình có sai gì mong mọi người góp ý . Mình cảm ơn
@@hunghung-mu6se cái này bạn lưu refreshToken vào redis, service nào cần thì request tới redis đó để lấy refreshToken để authen thôi, còn SSO là khác nữa =]
Mong đợi video tiếp theo của anh. Rất bổ ích ạ
tuyệt vời, âm thanh cực tốt, mong anh có thời gian ra thêm video ạ
Ở 35:05 anh nói "chúng ta lưu accessToken ở server" em chưa hiểu, nếu lưu trên server là lưu trên RAM chẳng phải nếu mỗi lần deploy thì data sẽ bị mất hay sao ? đoạn này em chưa hiểu
- Mong anh là một video nữa về cách lưu trữ accessToken + refreshToken như thế nào cho phù hợp.
giải đáp: nói "chúng ta lưu accessToken ở server" ? -> lưu trong database, trong bảng user.
tuyệt vời
Nay âm thanh và nội dung tốt quá chú ơi
cho em hỏi là tại sao thường thấy anh check if là (msg && msg === 'jwt expired') mình không phải chỉ cần check trường hợp msg === 'jwt expired' là ok rồi sao anh
Cho e hỏi, có 1 api lấy danh sách người dùng. Khi api bắt đầu được thực thi thì phát hiện access token hết hạn, khi đó server sẽ trả về code 401. Tiếp theo axios sẽ thực thi interceptor.response để lấy lại access token và set vào Locastorage thành công. Rồi làm sao cái api đó có thể tiếp tục chạy lại lần nữa để tự động lấy danh sách người dùng và hiện lên giao diện. Rõ ràng là Interceptor của axios chỉ có nhiệm vụ lấy lại token và gán vào Locastorage. Rất mong được admin và mọi người trả lời.
Em xem lại phút 32:41, dòng 89.
@@anonystick Hay quá, e cảm ơn ạ. 🤩. Thành công bước đầu hoàn thành cơ chế refresh token, tuy vẫn thiếu xót chưa hiểu mấy cú pháp và cơ chế hoạt động của thằng Interceptor axios lắm. Nhưng thực sự cảm ơn video của thầy rất nhiều.
@@anonystick Có một vấn đề nữa, e chưa tìm được lời giải ở đâu, đó là. Khi 1 api "get" thì refresh token vẫn hoạt động bình thường. Nhưng 1 api "post" (api cần đưa dữ liệu lên server) được gọi mà token hết hạn. Sau đó Interceptor tiếp tục lấy token thành công. Nhưng khi api post được gọi lại thì dữ liệu req.body bị null hoàn toàn thì mình giải quết như thế nào vậy thầy.
@@thiinh9289 Khả năng bạn chưa xử lý bất đồng bộ nên nó gửi lên trước khi token mới nó được gắn vào. trên server nó sẽ hiểu đó là null.
Với cơ chế này thì accessToken được lưu vào Redis rất phù hợp để tăng tốc độ verify accessToken
Cách này có kết hợp với blacklisted trên redis được không anh
Qúa tốt luôn!
file init_jwt này thường nằm trong folder nào ạ
Unauthorized mà trả về 200 + response(code, message) thế có vi phạm quy chuẩn không anh nhỉ
Có em, em xem lại file mà anh cung cấp httpStatusCode trên git nha em
tuyệt vời anh ơi,
Âm thanh và content quá tốt
Mình thì không khuyến khích lắm với việc lưu cả AccessToken vào DB hoặc nơi nào đó trên server khi đã lưu RefreshToken dù đồng ý là nó sẽ dễ dàng revoke (nhưng đa số trường hợp là không cần thiết). Thứ 1 nó sẽ khiến cho ứng ụng stateful (trong Rest thì điều này là vi phạm). Thứ 2 thì với mỗi Request lên server đều phải check database hoặc cache để kiếm tra AccessToken (Đây lại là nhược điểm của Session so với JWT, vậy tại sao phải khiến JWT có thêm nhược điểm này ?). Tóm lại đây là quan điểm của mình, các bạn có thể tham khảo.
Mình nghĩ là tùy yêu cầu hệ thống. sẽ có trường hợp cụ thể như sau :
1. Mình cần loại bỏ tất cả access token và refresh token của 1 user cụ thể sau khi user bị deleted.
2. Mình cần buộc phải loại bỏ tất cả access token và yêu cầu client refresh lại token để thay đổi roles/permissions trong token sau khi admin thay đổi roles/permissions của 1 user.
Đồng ý, nếu phải lưu access token vào db thì m dùng session luôn cho rồi
thầy ơi nó bị lỗi này là gì vậy ạ : Failed to execute 'setRequestHeader' on 'XMLHttpRequest' : is not a valid HTTP header field value
Em đang send một text. Nên bỏ vào data ví dụ: method : "POST",
data: {
...
'text' : text
}
@@anonystick cũng ko được luôn thầy ơi. Em kiểm tra network thì thấy sau khi nó gọi refreshToken thành công, lưu trong localstorage cũng thành công xong nó dừng lại , ko thực hiện tiếp việc gọi lên server lấy users.🥲
anh cho em hỏi nếu xử lý theo cơ chế này thì việc trả về refresh token sau khi login và lưu refresh token vào Redis có còn cần thiết không ạ ? thay vào đó sẽ chỉ lưu access token trong redis để dễ dàng revoke.
em đang xử lý refresh token bằng cách, nếu token đó hết hạn, thì sẽ gửi request cấp access token mới với thông tin ng dùng (vd: email và id) -> check database nếu có thông tin người dùng tương ứng sẽ cấp token mới
ok -> clone lại request trước đó đã failed (do lỗi 'jwt expired')
fail -> logout
theo a cách này có ổn không ạ ? rất mong được anh giải đáp
Việc lưu RT vào database là để theo dõi có bị ai đó đánh cắp và dùng lại hay không?
@@anonystick anh cho e hỏi, nếu sử dụng refresh token được tạo ra khi đăng nhập để xác thực người dùng sau đó cấp lại access token mới nếu access token đó hết hạn, vậy trong trường hợp refresh token đó hết hạn sẽ bắt người dùng phải đăng nhập lại ạ ?
ko có bước gọi lại api cũ khi refreshtoken thành công à a
Thầy cho em hỏi nếu Refresh Tokens hết hạn thì chuyện gì sẽ xảy ra ạ?
Login lại từ đầu và nếu thành công cấp lại 2 loại token
Góp ý cho bác là nên up lên github để ae xem nữa coi cứ loạn lên ạ
Mấy video đầu quên mất. xl anh em
@@anonystick dạ
thầy ơi nếu mình lưu accessToken ở Redux store và refreshToken ở cookies thì có tốt không ạ
Tốt nhất là cookies
video của thầy tốt quá, thầy có thể nào làm video chỉ cách, quy ước đặt tên biến hay tên hàm sao cho chuẩn để đi làm được k ạ.
Thầy ơi, cho em hỏi trong video hình như bị thiếu bước 4 đúng không ạ, vì sau khi refreshToken để có accessToken mới rồi thì sẽ tiếp tục gọi cái api cũ tiếp để get resource đúng không ạ. Nếu chỉ đến bước 3 là lấy token xong rồi set vào local storage là người dùng click get data xong thì UI nó đứng im, phải click thêm một cái nữa thì nó mới get được data thì phải.
Không cần bước 4. Nó tự động chạy lại api trước đó nếu get token thành công. Vậy nới hay chứ, nếu không dở ẹc à
@@anonystick thầy cho em hỏi cơ chế tại sao nó chạy lại vs thầy
@@uchung2890 này do interceptors của axios hỗ trợ tận răng rồi b .
Bạn có thể để ý là chúng ta đang gọi trong intercepter để check phần acceesstoken hết hạn và suy nghĩ tiếp nha bạn
@@PhongNguyen-ho7oj Bạn có thể giải thích cụ thể được không, mình đang chưa hiểu sao mà sau khi chạy refeshToken thì data trả về là success mà vẫn vào qua 2 cái check if đó
Âm thanh chất lượng rồi
thầy ơi cho em hỏi là tự trả về token mới mỗi lần hết hạn như vậy thì khi mình đưa token cho người khac hoặc lỡ lưu token ở một máy tạm nào đó là cái máy đó luôn truy cập vào được tài khoản của mình đúng không ạ? Vì dù token có hết hạn thì nó cũng tự refresh lại mà đúng không thầy, vậy hết hạn cũng giống như không hết hạn đúng không ạ thầy.
Đây là cách làm mới thôi. Chứ để mất thì phải làm thêm cách khác
cùng thắc mắc
@@tipsmooc cách nào hả bạn
Vậy nếu mất *access token* và *refresh token* thì có nghĩa người khác có khả năng truy cập vào tài khoản của mình mãi mãi đúng không vậy anh?
nhiều hệ thống yêu cầu bảo mật cao sẽ có kiểm tra devices và ip nữa
Thưa anh, nhược điểm có phải là nếu bị lộ token thì hacker sẽ chiếm quyền user mãi mãi không ạ. Mong anh phản hồi comment của em, chúc anh sức khoẻ.
Thật ra nếu Token bị chiếm thì không thể mãi mãi được. Nếu AccessToken bị lộ thì sẽ hết hạn nhanh vì sao lại hết hạn nhanh thì bạn xem lại video trước, còn FreshToken (FT) mà bị lộ thì nguy hiểm hơn chút nhưng không có nghĩa là chiếm mãi mãi, vì hệ thống được bảo mật tốt sẽ cho chúng ta biết FT được truy cập ở một thiết bị lạ or một location khác...
Vâng cám ơn anh, em cũng nghĩ là khi tạo token cần bổ sung các định danh phụ như IP, Divice, Location ... nếu phát hiện token được requets từ định danh không trùng khớp với lúc tạo sẽ block token luôn hoặc yêu cầu Xác thực hai yếu tố (2FA)
@@lequan4689 OK em!
ví dụ có 100 request trên fe hết hạn cùng lúc thì mình có thể chỉ cho 1 request refresh token xuống server rồi 99 thằng kia đợi lấy từ thằng 1 rồi xài chung được không a?
Đúng rồi...
Cho mình hỏi ngu phát: sao thấy refresh token dễ cấp vậy ạ? mình rất hứng thú với series này. mong đc ra nhiều video hơn ạ
Không dễ đánh cắp, do anh em mình bất cẩn trong khi triển khai thôi. kakak
anh làm video tiếp theo về xử lý nhiều request có token hết hạn được không ạ, em đang gặp vấn đề chỗ này hic
E chào a, a cho e hỏi a có video nói về vấn đề token hết hạn và có nhiều request đồng thời lúc đó k ạ
anh ơi, video tiếp theo của anh về xử lý nhiều request có token hết hạn ra chưa ạ?
Anh nghĩ sao về việc token sẽ lưu ở local còn refreshtoken lưu ở cookie, khi gửi request lên thì gửi cả 2 thằng này,...nếu hết hạn thì server tự lấy refreshtoken trong cookie gửi lên để làm mới lại token gửi về lại cho client ạ?
Mình cũng thấy cách này khá ổn. Vì lưu ở cookie sẽ bảo mật hơn cho refreshtoken . Không biết ý kiến thầy ntn mong thầy phản hồi.
cùng thắc mắc luôn ạ
Mình nghĩ vì session chỉ lưu đc trên 1 server . Mà hiện nay 1 web có nhiều server vì vậy để login 1 ở 1 server bất kỳ , mà tất cả server biết thì cách hiện nay là dùng jwt. ,mà khi request lên server (chưa biết server nào ) thì làm sao lấy đc refreshtoken. Mình có sai gì mong mọi người góp ý . Mình cảm ơn
@@hunghung-mu6se BAN NEN TIM HIEU VE SSO single sign on nhe.
@@hunghung-mu6se cái này bạn lưu refreshToken vào redis, service nào cần thì request tới redis đó để lấy refreshToken để authen thôi, còn SSO là khác nữa =]