@xdangminhtruong bài viết rất bổ ích

Add cho hoi anh sau khi lam mo, minh xem o dau.

thanks bạn nhé

Rất hay, cảm ơn bác đã chia sẽ, em biết thêm cách phối màu hay

https://topdev.vn/blog/tai-sao-khong-nen-luu-tru-data-user-tren-local-storage/

Đúng vậy ạ.

Cảm ơn em đã đặt câu hỏi cho a. Anh xin trả lời em lần lượt như sau

Câu 1.

Theo anh và những gì a đọc được ở bài viết này https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage, thì ta nên lưu ở cookie. Còn cụ thể em đọc bài đó nhé. A có thể cũng sẽ viết dịch thành 1 bài riêng để mọi người có thể dễ dàng theo dõ

Câu 2.

Nên sử dụng lưu JWT ở Cookie, và set flag HttpOnly để tránh việc truy cập thông qua JavaScript (https://kieblog.vn/httponly-flag-va-secure-flag-la-gi/) . Thêm nữa, ứng dụng cần sử dụng HTTPS/SSL như mình nói phía trên để ngăn việc người khác bắt gói tin ăn cắp mã JWT

Câu 3

• Câu hỏi này của em rất hay và có nhiều bạn hỏi anh như vậy rồi. JWT được sinh ra chỉ khi mà em thực hiện login (tức là gửi username/password lên) thôi. Nghĩa là trước khi update password, em login ở máy A và có JWT_1, em dùng JWT_1 này để truy cập hệ thống. Sau đó e sang máy B, e cũng fai login để có đc mã JWT_2. Sau đó e dùng máy B đổi password. Khi em đổi password, mã JWT_1 không hề bị ảnh hưởng. Em hiểu là chuỗi JWT_1 đó đang được client (tức là browser máy A) lưu rồi nên server không thực hiện làm gì đc chuỗi đó cả. Chuỗi JWT_1 vẫn hoàn toàn hợp lệ (KHÔNG HỀ SAI như em nêu ở trên) để truy cập hệ thống trừ khí nó bị hết hạn. Chính vì vậy, việc cân nhắc giảm thời gian hết hạn của chuỗi JWT là rất cần thiết.

• Trước đây có 1 bạn hỏi anh sao lúc check JWT sao ko so sánh thời gian tạo JWT với thời gian update password (nếu JWT tạo sớm hơn time update password thì nghĩa là JWT đó bị invalid). Nhưng nếu em làm như vậy, em đã phải truy cập vào DB và điều đó là đi ngược lại với những gì a đã giới thiệu ở trên, nghĩa là việc sử dụng JWT này giảm thiệu việc truy vấn DB khi xác thực người dùng.

• Một trong những cách a có thể suggest đó là: Khi em thay đổi gì đó mà cần loggout user ở các địa điểm khác, lưu cặp user_id - timeToCheck (với timeToCheck là thời gian trong trường hợp này là thời gian e update password). Trong hàm check JWT, e check create date của payload với timeToCheck tương ứng của user_id (lấy từ payload) và so sánh nếu JWT tạo sớm timeToCheck thì nghĩa là JWT đó bị invalid Tham khảo thử https://medium.com/devgorilla/how-to-log-out-when-using-jwt-a8c7823e8a6 (anh cũng chưa đọc đâu :p ) Hi vọng câu trả lời của a có thể khiến e hài lòng. cảm ơn em

hay đấy...

note lại mai đọc mới dc... đọc loáng thoáng thấy khá thú vị

mấy cái Token này tìm hiểu sâu cũng hay phết..

đi tìm lỗ hỏng cũng vui nhỉ. Thi thoảng dò được của mấy a lớn, kiếm ít tiền tiêu chơi

m sẽ cố gắng viết tiếp phần mới.

Bài viết rất hay, đợi bài mới....

vâng e sẽ cố gắng viết phần 2 ak.

ko biết có phần 2 ko :v

E xin có câu hỏi ạ:

• JWT chủ yếu được lưu trữ trực tiếp trong bộ lưu trữ web (local/session storage) hoặc ở cookies. Theo a thì lưu ở đâu tốt hơn.
• Nếu lưu ở client như vậy thì sẽ bị người khác lấy được token của mình, vậy cách nào để ngăn chặn người khác lấy token của mình
• E có 1 token "A" sau khi login với username: admin, pass:admin, vậy trường hợp e đổi pass đi, thì sẽ sinh ra token "B" mới. Vậy nếu ai đó lấy dc token A của e thì làm sao e biết token A đó là sai nếu chỉ check Signature. Thanks a

cảm ơn bạn đã quan tâm đến bài viết cuả mình, hy vọng bài viết giup ích cho bạn

hay qua bạn ạ

Thank bạn nhé

Hi anh, bài viết rất hay. Tuy nhiên em có thắc mắc về những cái này:

Disposable disposable = requestInterface.register() .observeOn(AndroidSchedulers.mainThread()) .subscribeOn(Schedulers.io())

Anh có thể giải thích giúp em đươc không ạ. Thanks a