Vâng bác, hehe. Cái này thì cũng thoảng ạ. Sendo bounty khá rõ ràng vì có chính sách nên là em vẫn chơi với bên này lâu lâu. Từ ngày đó năm 2018 tới giờ vẫn ra bug bác ạ :v
trong phần color x11 của web w3schools có chocolate1,chocolate2,chocolate3 chả lẽ bạn không thấy à những cái có ghi 1,2,3 thì dùng mã hex chứ không dùng tên thường gọi!mình đã từng thử với màu chocolate,nghĩ mấy cái kia cũng thế
Bản thân thế giới máy tính được thiết kế từ điện tử, không phải sinh học, bản thân nó mình tin rằng có là một tổng thể các thành phần độc lập và được gắn lại với nhau. >> Like!
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
THẢO LUẬN
Vâng bác, hehe. Cái này thì cũng thoảng ạ. Sendo bounty khá rõ ràng vì có chính sách nên là em vẫn chơi với bên này lâu lâu. Từ ngày đó năm 2018 tới giờ vẫn ra bug bác ạ :v
trong phần color x11 của web w3schools có chocolate1,chocolate2,chocolate3 chả lẽ bạn không thấy à những cái có ghi 1,2,3 thì dùng mã hex chứ không dùng tên thường gọi!mình đã từng thử với màu chocolate,nghĩ mấy cái kia cũng thế
Em cảm ơn a nhiều ạ. E hiểu rồi ạ.
Chào bạn! Để so sánh time created_at với thời gian hiện tại thì bạn dùng:
Bản thân thế giới máy tính được thiết kế từ điện tử, không phải sinh học, bản thân nó mình tin rằng có là một tổng thể các thành phần độc lập và được gắn lại với nhau. >> Like!
ナイス！
toàn những trick hay tiếc là các browser chưa support hết
@HuyDQ (tat)
@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ị