032-Phân quyền cho từng Request với JWT middleware

[@Seiba15]

Nay thầy đăng tận 35 video luôn, khóa mới hả thầy? 😯

[@NguyenDucHoang]

Yes, đăng full luôn, mn xem ủng hộ đuê

[@mindev1701]

Anh triển khai thêm phân quyền chi tiết kiểu crud riêng lẻ từng routes được không ạ, thêm cái quản lý devices revoke token các kiểu nữa. Em cảm ơn

[@NguyenDucHoang]

Có phân quyền dùng middleware cho từng method đó em

[@NguyenDucHoang]

À nói kỹ mấy case revoke token anh nghe nào 😊

[@mindev1701]

​@@NguyenDucHoang Đây ạ. TH1. Người dùng chủ động logout thì chúng ta vô hiệu hoá token đó luôn, chứ không đơn giản là xoá access or refresh. TH2. Quản lý từng phiên, thiết bị đăng nhập giống fb, zalo admin + user có quyền chủ động logout từ xa.

[@mindev1701]

@@NguyenDucHoang Em thấy có nhiều hệ thống không chỉ phân quyền theo role admin, sp admin, mod. Mà phân quyền kiểu chi tiết từng routes crud. VD: quản lý banner account mod1 có quyền add, remove, update. Còn Mod2 chỉ có quyền update

[@tuannguyenthai]

Hình như hướng thầy làm là cho accesstoken khoảng 30d thì hết hạn bắt đăng nhập lại. Xong cấp token mới Nếu như em muốn làm theo phong cách accesstoken và refreshtoken Thì em sẽ lưu refreshtoken vào trong db. Sau đó giới hạn accesstoken còn 15m Sau mỗi 15m mình sẽ cho token hết hạn và viết ra 1 controller refreshToken nhấn vào kiểm tra refreshToken còn hạn hay không nếu còn mới cấp cho accesstoken mới Trong trường hợp refreshtoken hết hạn sẽ bắt đăng nhập lại và cấp cho accesstoken và refreshtoken mới luôn. làm theo luồng như này trông ổn không ạ

[@Pinga-x1u]

Ko nên lưu token trong db nhé b. Giả sử có người hack dc bảng lưu token là đi một sải rồi

[@tienthaithanh8673]

@@Pinga-x1u luu refresh token la dung r, DB ma bao bi hack thi lam an gi nua kk

[@Pinga-x1u]

@ thế b biết vì sao mật khẩu phải hash ko?

[@phamucbinh1217]

có fe với backend này không thầy

[@NguyenDucHoang]

@@phamucbinh1217 list này là backend, fe sẽ làm bằng nextjs cho lên udemy

[@phamucbinh1217]

@@NguyenDucHoang bao giờ có ạ