midnight_sun
Senior Member
e thì nghĩ ko nên để client push vào socket, và giả sử khi gửi comment, sẽ call API lên gateway -> auth -> push vào message queue -> consumer rút ra xử lý -> push sang socket để emit event về client
thảo luận Triển khai microservice cho backend springboot
- Người tạo chủ đề Hero Kun
- Ngày bắt đầu
joonkim
Member
Đang hiểu là mọi request của bác đều phải qua gateway, và ws cũng phải đi qua nó. Nên chắc ổn thôi.
bế đi ứng dụng khác á, nghe tách module tái sử dụng thì cao nhưng vụ bế đi này thấy khó đấyvì kiểu gì cx sẽ bị cross domain, ko tách đc hoàn toàn business ra đâu
Đang hiểu là bác ấy bế cái service đó sang con application khác. Kiểu build module rồi include vào project ấy.
Làm sao để jwt bị chôm
- đọc request chôm
- vào máy đó lấy
- xss
midnight_sun
Senior Member
thì e đang nói cái đấy đấy :v ko đơn giản chỉ là tách riêng r sử dụng lúc nào cx đc ý, nó sẽ bị cross domain
Hero Kun
Senior Member
bac dang lam du an gi day :3Đang hiểu là mọi request của bác đều phải qua gateway, và ws cũng phải đi qua nó. Nên chắc ổn thôi.
Đang hiểu là bác ấy bế cái service đó sang con application khác. Kiểu build module rồi include vào project ấy.
Làm sao để jwt bị chôm
Không đơn giản để chôm đc jwt, chưa kể ko có key thì ko thể sửa đc content bên trong của jwt. => dữ liệu không sửa được. Và time to live của jwt có giới hạn(ae nên set nó ngắn thôi), sau thời gian đó phải lấy token khác. Nên nhìn thì risky, tuy nhiên lấy đc khá khoai đấy.
- đọc request chôm
- vào máy đó lấy
- xss
Le1tuan
Senior Member
sach gi the bacMình chưa làm cái này xem sách thấy họ gợi ý thế thôi
Hero Kun
Senior Member
Em cảm ơn bác, em cũng đang tìm hiểu keycloak thấy nó khá hay. em có một thắc mắc về khi người dùng đăng kí tài khoản mới.
E viết một cái api tạo tài khoản mới(springboot) và khi thực thi cái api tạo tài khoản(springboot) đó thì sẽ gọi cái api tạo tài khoản của keycloak bác nhỉ.
mr.ken6996
Đã tốn tiền
keycloak không dành cho tay ngang đâu, nó còn trong giai đoạn phát triển, tầm dev cứng hiểu biết sẽ làm dễ thở hơn, còn thích thì cứ làm biết thêm nhiều thứ, tài liệu của keycloak thuộc dạng khó hiểu chỉ có ai có hiểu biết trước mảng security đó thì mới hiểu nó nói gì
ngoài ra tài liệu có thể out of date và nó là dạng framework muốn tích hợp nó thì phải có thể tự custom, nhắm làm nổi thì hẵng apply không thì chọn thằng khác, apply xong không biết xử lý thì sau này phê pha đó
mình từng làm với keycloak từ thủa sơ khai, docs còn sai, stackoverflow còn ko có ai hỏi về nó, cá nhân mình đánh giá nó quá triển vọng, vì mình làm từ thời chả có ai hỏi gì giờ thấy bắt đầu rộ nó lên thấy rất vui
ngoài ra tài liệu có thể out of date và nó là dạng framework muốn tích hợp nó thì phải có thể tự custom, nhắm làm nổi thì hẵng apply không thì chọn thằng khác, apply xong không biết xử lý thì sau này phê pha đó
mình từng làm với keycloak từ thủa sơ khai, docs còn sai, stackoverflow còn ko có ai hỏi về nó, cá nhân mình đánh giá nó quá triển vọng, vì mình làm từ thời chả có ai hỏi gì giờ thấy bắt đầu rộ nó lên thấy rất vui
onitake92
Đã tốn tiền
Đúng r thím, hồi làm cty trước a architecture phân ra cái cấu trúc mình thấy khá hay. Chia ra 2 cục: user vs identity, cục user chuyên quản lý user details, cục identity thì chuyên về role và giao tiếp với keycloak. Nên full flow sẽ là từ client -> user service -> identity service -> keycloak
onitake92
Đã tốn tiền
Đúng r nè thím
giờ tới cái UI thì keycloak nó cũng cho mớ tutorial trên mạng bị out of date 
Kinggodmonkey
Member
Dùng 1 con service để authen. Sau đó dùng Jwt .
Vào con service nào xác minh JWt hợp lệ là xong, chả cần call vào db hay con servies authen làm gì nữa
Hero Kun
Senior Member
Em cảm ơn bác, bác cho em hỏi ngoài chút. những cái service nào cần liên quan đến người dùng thì trong mỗi service mình nên tạo table chứa id của user bác nhỉ.Đúng r thím, hồi làm cty trước a architecture phân ra cái cấu trúc mình thấy khá hay. Chia ra 2 cục: user vs identity, cục user chuyên quản lý user details, cục identity thì chuyên về role và giao tiếp với keycloak. Nên full flow sẽ là từ client -> user service -> identity service -> keycloak
Hero Kun
Senior Member
ý bác là decoder cái jwt rồi tìm ra thằng đó là ai (id hoặc username) để chổ khác dùng hả bác.
Kinggodmonkey
Member
Đúng rồi. Xác minh jwt đó là thật , từ đó trích ra user id của thằng đó. Xác minh được đúng user và token hợp lệ thì cho phép nó truy xuất resource
Nếu thích thì thêm role vào luôn cũng được
TrungNgaoNgo
Senior Member
spring microservices in action
gaconkute
Senior Member
well. sorry, không hẳn. Ví dụ này đi : Tôi có 1 user A trong DB, khi A gọi service này sẽ gen ra XYZ là token với invalid time = 7 ngày của anh ý. Bây giờ anh muốn khóa tài khoản của ổng thì sao, Khi token XYZ qua service của anh, anh có decode rồi check trong DB không, nếu không thì no hopeĐang hiểu là mọi request của bác đều phải qua gateway, và ws cũng phải đi qua nó. Nên chắc ổn thôi.
Đang hiểu là bác ấy bế cái service đó sang con application khác. Kiểu build module rồi include vào project ấy.
Làm sao để jwt bị chôm
Không đơn giản để chôm đc jwt, chưa kể ko có key thì ko thể sửa đc content bên trong của jwt. => dữ liệu không sửa được. Và time to live của jwt có giới hạn(ae nên set nó ngắn thôi), sau thời gian đó phải lấy token khác. Nên nhìn thì risky, tuy nhiên lấy đc khá khoai đấy.
- đọc request chôm
- vào máy đó lấy
- xss
joonkim
Member
Có 2 điểm ở chỗ này
- time to live của token nên set ngắn thôi. như t đã nói ở trên. ae cố set dài ra cũng được, nhưng không khuyến khích.
- việc kick user/xóa user khi token vẫn còn hạn mình có nhiều cách hack. Có thể làm device/session manager đoạn này chẳng hạn.
onitake92
Đã tốn tiền
Buộc phải vậy thôi, nó là cái điểm yếu chí tử database phân tán của microservice đó. Nên lúc design module phải hạn chế tối đa đc cái này, mình nghĩ có kinh nghiệm nhiều mới ok, mình chưa đủ trình
onitake92
Đã tốn tiền
Mình nhiều chuyện xíu, thường thì access token tầm 5' sau 5' phải dùng refresh token refresh lại, hình như chỗ này refresh token cũng bị refresh lun (này k chắc, chờ cao nhân chửi), giả sử trong 5' đó mà thím logout hoặc k xài nữa và bằng cách nào đó system nó biết đc thím k xài nữa mà bỏ đi chơi, thì cái cần revoke là refresh token chứ k phải access token đó
gaconkute
Senior Member
thank 2 fens, thực ra chỗ này nếu OK thì tạo 1 con redis key = ID user, value = token để lưu jwt, mỗi lần check thì check có trong redis không đã nếu làm thủ công nhỉ.Mình nhiều chuyện xíu, thường thì access token tầm 5' sau 5' phải dùng refresh token refresh lại, hình như chỗ này refresh token cũng bị refresh lun (này k chắc, chờ cao nhân chửi), giả sử trong 5' đó mà thím logout hoặc k xài nữa và bằng cách nào đó system nó biết đc thím k xài nữa mà bỏ đi chơi, thì cái cần revoke là refresh token chứ k phải access token đó
Chủ đề tương tự
