Video học lập trình mỗi ngày

Kịch bản phỏng vấn này sẽ được vào danh sách phát: "Tuần tới tôi đi Interview" trong member.

Hôm nay tiếp tục nói về JWT -> những kịch bản trong hệ thống ứng dụng đa nền tảng.

Nếu như vừa rồi, một công thần đã giúp cho chúng ta xử lý việc logout ra từ một thiết bị mà không ảnh hưởng đến các thiết bị khác một cách đơn giản có thể nói rất tuyệt vời. Nếu tôi gặp trường hợp tương tự như vậy chắc chắn tôi sẽ triển khai theo cách đó.

Khuyến nghị - Public : JWT: logout ra từ một thiết bị mà không ảnh hưởng đến các thiết bị khác

Bây giờ có một kịch bản mới xuất hiện và nó khó hơn rất nhiều so với trường hợp logout. Đó là kịch bản change password or relogin. Đầu tiên đi phân tích kịch bản hành vi này như những lần trước.

Câu hỏi phỏng vấn

Người phỏng vấn: "CV quá tốt, như vậy thì hệ thống xxxx.com bạn triển khai cho phép một user login trên được nhiều thiết bị phải không?"

Ứng viên: "Vâng! Đúng vậy. Nó là một thiết kế thân thiện phù hợp với xu thế hiện nay."

Người phỏng vấn: "Đồng ý. Vậy nếu một thiết bị thay đổi password thì bạn sẽ thu hồi các token trên các thiết bị còn lại thế nào?"

Ứng viên: "Đầu tiên..."

Người phỏng vấn: "Có cách nào tốt hơn không? Vì tôi thấy hệ thống bạn rất tốt.."

Kịch bản của việc change password

Trước tiên đi vào kịch bản này thì nhân tiện tôi trả lời câu hỏi của các anh chị trong member nodejs, java và go luôn: "Vì sao login lại thì phải tạo một cặp token mới?".

Đúng vậy, nguyên tắc là khi user or ai đó login lại thì phải tạo lại token mới. Không biết các anh chị đã có lần sao đang sử dụng FB mà bị đá ra và bắt login lại chưa? rất nhiều đúng không?

Là do hệ thống phát hiện điều gì đó đáng ngờ, ví dụ hiện tại đang truy cập tại HCM, nhưng 5 phút sau truy cập tại HN. Điều đó có nghĩa là token của bạn đang sử dụng bất thường, vì vậy hệ thông sẽ giải quyết bắt login lại và xác nhận chính xác, thằng nào là chính chủ.

Điều này cũng giống như việc changePassword cũng vậy, bank cũng có luật lệ 3 or 6 tháng sẽ thay đổi lại, vì nguy cơ rò rỉ dữ liệu bảo mật nên họ phải bảo vệ.

OK đến đây, anh em đã hiểu vì sao login và changePassword thì phải vô hiệu hoá các token đã cấp phát với cùng một tài khoản. Giờ đi vào cách triển khai.

Vô hiệu hoá jwt

Để triển khai vấn đề này thì đa số anh em sẽ đi từng trường hợp. Giả sử tôi có tài khoản uid=123. Muốn vô hiệu hoá token của tài khoản này khi changePassword thì bước 1 chúng ta phải quản lý được bao nhiêu thiết bị đang sử dụng của tài khoản này.

Nghĩa là phải lưu ở đâu đó để quản lý, với uid=123 này giả sử login trên 3 devices thì lúc này sẽ có 3 tokens hoạt động trên 3 thiết bị đó.

Bước hai: Nếu uid này changepassword trên iPhone, thì lúc này phải tìm tất cả các token này đưa vào tokenBlackList như video trước đúng không? Đây là câu trả lời như trên, nhưng không được đánh giá cao?

Vì sao? Trong video đã phân tích nhược điểm của cách này.

Vậy câu hỏi đặt ra có cách này tốt hơn nà không cần lưu những token đó không? Câu trả lời là CÓ. Cách sau đây.

Anh chị hãy xem lại code của mà tôi show cho anh chị có thất một chi tiết khi tạo token hay chưa? Đó là iat gọi là issued at gọi là thời gian phát hành token.

Đây là cách tốt nhất để trả lời câu hỏi phỏng vấn trên (kèm source): Thu hồi token trên nhiều thiết bị khi một thiết bị changePassword