Hey! Yeah, I've wrestled with ransackable scopes before. It looks like you're on the right track with defining the scope and whitelisting it. Is the issue that the scope always defaults to all? Sometimes, I find the way params are passed from the view can be tricky. It might be worth double-checking that the boolean value is being sent correctly as a string ("true" or "false") from the form. It reminds me of playing Agario; sometimes you think you’re safe, but a tiny change in position means you're suddenly someone's lunch! Good luck debugging!
@phhuy38 Hoàn toàn có thể dùng song song cả 2 ông nhé, không bắt buộc phải chọn 1. Tuy nhiên, sẽ ít ai cắm thẳng cả Session và JWT chung vào một cụm API hay service vì chi phí bảo trì khá mệt: code phải rẽ nhánh check 2 luồng auth liên tục, ví dụ một tính năng như "Logout khỏi tất cả các thiết bị" sẽ cực kỳ cồng kềnh vì phải đi dọn rác ở cả 2 nơi, vừa phải chọc DB xóa session cho Web, lại vừa phải đi xử lý revoke JWT cho mobile. Thực tế các hệ thống lớn vẫn xài cả 2 nhưng họ chia lớp rõ ràng: Web dùng Session gọi đến cổng Gateway cho an toàn, rồi Gateway mới đúc ra JWT đẩy xuống vùng lõi Microservices bên trong. Còn nếu làm chung một API phơi ra ngoài cho cả web lẫn mobile gọi trực tiếp, anh em thường quy về 1 chuẩn JWT từ đầu để đồng nhất và dễ maintain thôi.
78win là nền tảng giải trí trực tuyến được nhiều người tin tưởng nhờ hình ảnh chuyên nghiệp và định hướng phát triển bền vững. Sở hữu giao diện hiện đại, tối ưu trên mọi thiết bị, 78WIN mang đến trải nghiệm mượt mà, tiện lợi cùng dịch vụ hỗ trợ tận tâm, tạo dựng uy tín và dấu ấn riêng trên thị trường.
Ông vừa chạm đúng chỗ ngứa đấy =))). Nếu kiến trúc chỉ phục vụ Web thuần túy, Session + Cookie là vua. Nhưng khi có thêm Mobile App (Client không có trình duyệt chuẩn), việc ép mobile xài cookie đúng là cực hình. Lúc này, dùng JWT để đồng nhất giao tiếp cho cả Web và Mobile lại là sự đánh đổi hoàn toàn xứng đáng. Use-case của ông chính là một ngoại lệ hoàn hảo để chứng minh cho việc kiến trúc không có đúng sai tuyệt đối, chỉ có phù hợp với hoàn cảnh và bối cảnh nào thôi =)))😁
Bài viết khá hay và chi tiết. Nhưng mình có một thắc mắc nếu 'Monolith thì nên ưu tiên Session'. Trong trường hợp backend Monolith của mình phải phục vụ cả Web (React) và Mobile App (iOS/Android) thì sao? Quản lý cookie trên mobile khá phiền phức và khó chịu, lúc này dùng JWT chẳng phải tiện hơn Session nhiều sao??
Ông nhắc đến Keycloak là quá chuẩn rồi. Tool với framework bây giờ làm quá tốt, config vài dòng là xong, abstract kỹ quá nên nhiều anh em cứ cắm vào là chạy mà không rành luồng. Nhưng tới lúc trace bug mà không hiểu bản chất thì rớt nước mắt ngay. Rất vui vì bài viết có sự đồng điệu với ông 🤜🤛
Chính xác là không có gì tuyệt đối cả. Ý tưởng dùng jwks sinh ra cặp khóa cho từng microservice thực ra đã được áp dụng ở thằng keycloak. Có điều giờ nhiều ae dev chỉ dùng mà ko hiểu bản chất của nó. Cảm ơn chủ tus về 1 bài viết hữu ích
THẢO LUẬN
1 ý tưởng hay , cảm ơn tác giả
Cảm ơn ô😁thấy hay thì share cho mn cùng đọc nhé
cảm ơn bạn
quá hay
Rất đầy đủ và chi tiết, đi thẳng vào vấn đề. Cần nhiều những bài viết kiểu này. Cảm ơn tg
rất bổ ích thanks!
Đỉnh quá a ơi, chia sẻ hay quá
Hey! Yeah, I've wrestled with ransackable scopes before. It looks like you're on the right track with defining the scope and whitelisting it. Is the issue that the scope always defaults to all? Sometimes, I find the way params are passed from the view can be tricky. It might be worth double-checking that the boolean value is being sent correctly as a string ("true" or "false") from the form. It reminds me of playing Agario; sometimes you think you’re safe, but a tiny change in position means you're suddenly someone's lunch! Good luck debugging!
cứ học chắc network trước e nhé
@phhuy38 Hoàn toàn có thể dùng song song cả 2 ông nhé, không bắt buộc phải chọn 1. Tuy nhiên, sẽ ít ai cắm thẳng cả Session và JWT chung vào một cụm API hay service vì chi phí bảo trì khá mệt: code phải rẽ nhánh check 2 luồng auth liên tục, ví dụ một tính năng như "Logout khỏi tất cả các thiết bị" sẽ cực kỳ cồng kềnh vì phải đi dọn rác ở cả 2 nơi, vừa phải chọc DB xóa session cho Web, lại vừa phải đi xử lý revoke JWT cho mobile. Thực tế các hệ thống lớn vẫn xài cả 2 nhưng họ chia lớp rõ ràng: Web dùng Session gọi đến cổng Gateway cho an toàn, rồi Gateway mới đúc ra JWT đẩy xuống vùng lõi Microservices bên trong. Còn nếu làm chung một API phơi ra ngoài cho cả web lẫn mobile gọi trực tiếp, anh em thường quy về 1 chuẩn JWT từ đầu để đồng nhất và dễ maintain thôi.
78win là nền tảng giải trí trực tuyến được nhiều người tin tưởng nhờ hình ảnh chuyên nghiệp và định hướng phát triển bền vững. Sở hữu giao diện hiện đại, tối ưu trên mọi thiết bị, 78WIN mang đến trải nghiệm mượt mà, tiện lợi cùng dịch vụ hỗ trợ tận tâm, tạo dựng uy tín và dấu ấn riêng trên thị trường.
@ngocbach99 mình muốn hỏi là tại sao không thể dùng Session cho web và JWT cho Mobile cùng lúc mà bắt buộc phải dùng JWT cho cả 2.
bước 4 low threshold là ngương gì vậy ạ
Bài chi tiết quá ạ. Cảm ơn anh
đơn giản và đầy đủ
Ông vừa chạm đúng chỗ ngứa đấy =))). Nếu kiến trúc chỉ phục vụ Web thuần túy, Session + Cookie là vua. Nhưng khi có thêm Mobile App (Client không có trình duyệt chuẩn), việc ép mobile xài cookie đúng là cực hình. Lúc này, dùng JWT để đồng nhất giao tiếp cho cả Web và Mobile lại là sự đánh đổi hoàn toàn xứng đáng. Use-case của ông chính là một ngoại lệ hoàn hảo để chứng minh cho việc kiến trúc không có đúng sai tuyệt đối, chỉ có phù hợp với hoàn cảnh và bối cảnh nào thôi =)))😁
Bài viết khá hay và chi tiết. Nhưng mình có một thắc mắc nếu 'Monolith thì nên ưu tiên Session'. Trong trường hợp backend Monolith của mình phải phục vụ cả Web (React) và Mobile App (iOS/Android) thì sao? Quản lý cookie trên mobile khá phiền phức và khó chịu, lúc này dùng JWT chẳng phải tiện hơn Session nhiều sao??
Ông nhắc đến Keycloak là quá chuẩn rồi. Tool với framework bây giờ làm quá tốt, config vài dòng là xong, abstract kỹ quá nên nhiều anh em cứ cắm vào là chạy mà không rành luồng. Nhưng tới lúc trace bug mà không hiểu bản chất thì rớt nước mắt ngay. Rất vui vì bài viết có sự đồng điệu với ông 🤜🤛
Chính xác là không có gì tuyệt đối cả. Ý tưởng dùng jwks sinh ra cặp khóa cho từng microservice thực ra đã được áp dụng ở thằng keycloak. Có điều giờ nhiều ae dev chỉ dùng mà ko hiểu bản chất của nó. Cảm ơn chủ tus về 1 bài viết hữu ích
Cảm ơn b, mình đã sửa lại.