Sorrry cả nhà giọng mình hơi ề à hơi ngáo vì lúc đó hơi mệt :(. Có một vài điều cần lưu ý: - Regex replace base64url thiếu “global”, đúng là /\+/g, /\//g (thay bằng _ chứ không phải -) và /\=/g. Trong video mình bị nhầm. - Các vấn đề liên quan tới bảo mật token như: độ mạnh của secret key, thời hạn sống của token, blacklist, nên lưu token vào đâu cho bảo mật, v.v mình nói ở video sau nhé. - Khi sử dụng session để authentication thì gọi là "session-based authentication", còn token là "token-based authentication" nhé. ❓Tại sao "token-based authentication" với JWT hiện tại lại tỏ ra vượt trội và ưu thế hơn so vơi "session" trong các ứng dụng hiện đại ngày nay? - Đúng là cơ chế thì vẫn là luồng xác thực tương tự như session đó. Server tạo ra JWT trả về client, client lưu trữ và gửi lên cùng các request... Tuy nhiên, mấu chốt nó nằm ở việc JWT nó là stateless authentication. Đích đến vẫn là check DB, chắc chắn rồi. Nhưng nó là stateless về về mặt kiến trúc hệ thống trông như sau: [Client] -> [Web server] -> [Database] Khi dùng JWT thì [Web server] không lưu dữ liệu nữa (sessions thì được lưu ở đây), nên JWT nó là stateless authentication. Khi đó dữ liệu được lưu trong chính payload của JWT, thường lưu userID để xác định user (JWT gọi là "sub" - subject). Vậy stateless ở khúc [Web server] có lợi gì? Hãy tưởng tượng hệ thống của bạn không phải chỉ có 1 máy chủ, mà có từ 2 máy chủ trở lên, phía trước là Load balancer (cân bằng tải), nhiệm vụ chia tải cho các [Web server] phía sau. Khi đó, mỗi request của client có thể vào các máy chủ khác nhau. Giả sử login request vào máy chủ A và tạo session trên đó, request sau lại vào máy chủ B thì sẽ không có session nên sẽ lỗi Unauthorized. Giải pháp khi đó là cần sync sessions giữa các [Web server], hoặc lưu session ra DB/hoặc một nơi chung nào đó để các [Web server] cùng trỏ tới => phức tạp hơn, khó khăn khi scale hơn. Nếu dùng stateless authentication như JWT thì không gặp phải vấn đề trên nữa. Các request có thể mang JWT tới bất cứ [Web server] nào, chỉ cần có secret key là có thể xác thực được token. Ngoài ra, JWT không lo đụng chính sách CORS của trình duyệt khi authentication như với cookie (trong case sử dụng session). Nó cũng bảo mật hơn vì xác thực bằng secret key, phải có secret key mới có thể xác thực. ✅Tóm váy lại: Tại sao "token-based authentication", cụ thể là JWT lại tỏ ra vượt trội hơn? 👉 Stateless, dễ dàng mở rộng; phù hợp với kiến trúc phân tán (không cần sync session); bảo mật; cross-domain/origin (không dính CORS khi authentication); tùy biến cao (payload mang data).
@fesn69986 ай бұрын
Rất hi vọng a sớm giải thích thêm về vấn đề lưu trữ token, blacklist và đặc biệt là refresh token ạ!
@cunanh21123 ай бұрын
A giải thích cuốn thế ạ. Mong a chia sẻ thêm nhiều về auth
@vuankhanh6 ай бұрын
Trước giờ toàn dùng thư viện nên cũng không để ý bên trong nó tư duy như thế nào, nay xem clip của anh Sơn nên hiểu hơn.
@global_citizen6 ай бұрын
Really appreciate anh. Những kiến thức a chia sẻ luôn luôn bài bản, chi tiết, rõ ràng và nó thực sự giúp ít rất nhiều trong con đường sự nghiệp của e ạ.
@F8VNOfficial6 ай бұрын
Cảm ơn em nhiều nha. Chúc em gặt hái nhiều thành quả.
@iamnguyenhoanganh6 ай бұрын
nhiều khóa học trên mạng thì em vẫn phải công nhận là anh sơn idol nói dễ hiểu và muốn nghe nhất ^^😊
@F8VNOfficial6 ай бұрын
Cảm ơn em nhiều nha
@funnyanimal19003 ай бұрын
video hay quá, đã xem hết 3 video trong series này mà thực sự bổ ích cho 1 người làm FE như e, mong anh ra tiếp các phần sau của series này.
@phamducphutrong6 ай бұрын
Việc tự học rất quan trọng nhưng có 1 ông thầy siêu vip pro như a Sơn thì vẫn là 1 sự may mắn. Có những cái mà a không nói thì cho tự học cả đời cũng chả biết đến sự tồn tại của nó :))
@F8VNOfficial6 ай бұрын
Cảm ơn e đã em nhiều nha. Mà anh ko cao siêu vậy đâu ý. Những cái này bình thường có thể một số anh em ko thích tìm hiểu thôi, chứ ngồi vọc thì một lúc cũng biết em nè
@vanthietIT6 ай бұрын
😂😂😂😂
@TranTu-qu7eo6 ай бұрын
Video rất hay và bổ ích ạ, a có thể làm thêm về flow của access token và refresh token bên phần frontend được không ạ
@F8VNOfficial6 ай бұрын
Để anh sắp xếp nhé
@thangnguyen-je6kp4 ай бұрын
anh làm một khoá về bảo mật web và chống lại các cuộc tấn công web được không anh
@ht19783 ай бұрын
Quá hay a ơi, mong a ra video tiếp theo ngay bây giờ ạ
@nguyentaik26 ай бұрын
Xịn quá a ơi mong a làm tiếp về những cái liên quan tới jwt ạ
@thailehoangbao67125 ай бұрын
Khi nào mới có video làm tiếp dự án tiktok ui vậy anh? Em chỉ xem tới phần sidebar thì không tìm thấy video phần tiếp theo
@aphat21535 ай бұрын
hay quá! có thời gian làm thêm quả refresh token luôn cho trọn bộ a :))
@NguyenXuanQuyK17QN4 ай бұрын
anh không ra thêm video về phần này nữa ạ? Như SSO hay nhiều thứ khác ấy ạ?
@vancongang30925 ай бұрын
Anh thật là người có tâm. Cảm ơn anh nhìu ❤
@mystic8376 ай бұрын
Hay sếp ơi. Đang viết lại hệ thống BE thì xem đc video này😊😊😊
@グエンコン-w1u3 ай бұрын
Vẫn chưa có khoá học mới ạ anh. em hóng các khoá mới của anh quá.
@dainghia12994 ай бұрын
Bao giờ có khóa nextjs vậy anh. Hóng quá
@nhatdinh36605 ай бұрын
Hi anh Sơn, em theo dõi anh qua các bài nodejs từ 2021, lúc đó em chưa tốt nghiệp. Khoảng thời gian đó em đi làm ở công ty viễn thông F về laravel. 2023 em phải đi NVQS nên đành gác lại công việc. Dạo gần đây em có hỏi thăm các bạn học chung và xem các trang tuyển dụng về vị trí laravel thì thấy thị trường ảm đạm quá nên em tiếp tục học thêm về nodejs. Anh có thể ra một chuỗi video làm một dự án thực tế về nodejs được không ạ, em cảm ơn anh nhiều🎉❤
@F8VNOfficial5 ай бұрын
Cảm ơn em đã ủng hộ F8. Hiện tại anh đang khá bận việc khác nên chưa thể ra chuỗi video sớm được em ạ. Em tìm TrungQuanDev xem, anh thấy bạn ấy có một chuỗi về Node Express hay đó em ơi.
@ThuanNguyen-hb2zy5 ай бұрын
Khi nào khóa JavaScripts Pro ra mắt thế a Sơn ơi, e mong ngóng từng ngày
@longnguyen90104 ай бұрын
hóng anh Sơn làm thêm về vấn đề lưu token ở đâu
@HoaLy-ox9ue3 ай бұрын
Hóng video refresh token, bảo mật token tiếp theo.
@phapluu54396 ай бұрын
a làm thêm về refreshToken đi a, dễ hiểu quá a ạ :)))
@NguyenDinhNamz6 ай бұрын
video rất hay và bổ ích, hy vọng anh sẽ ra thêm nhiều video như này
@F8VNOfficial6 ай бұрын
Okie em nha
@sonnguyendang72475 ай бұрын
Hay quá đi mất. Anh cho em hỏi làm sao anh biết những quy trình bài bản thế này ngoài việc đọc thật kỹ tài liệu chính thống của bên cung cấp công nghệ ạ? Em tuy rất thích ứng dụng nhưng việc đọc thật kỹ tài liệu hướng dẫn từ các bên cung cấp vẫn là thứ mà em chưa thể tận hưởng được. Chính vì thế em rất thích các video hướng dẫn và giải thích cụ thể như kênh của anh ấy ạ.
@F8VNOfficial5 ай бұрын
Có nhiều bài viết em ơi, ví dụ khi em tìm cách sử dụng JWT thì em hãy tìm thêm với từ khóa "... without library" (không sử dụng thư viện) chẳng hạn. Ngoài ra, search thêm hình ảnh "... workflow" để tìm hiểu luồng thông qua hình ảnh.
@hunggledinh14766 ай бұрын
Mong anh ra nhanh về vấn đề bảo mật token ở phía client đó ạ
@NguyenDuy-wq3zh5 ай бұрын
anh ơi khóa JS Pro sắp ra chưa ạ chứ em sắp chuyển nghề đến nơi rồi
@zhangvincent-vt2bj2 ай бұрын
a sơn cho hỏi dạo này các video pro sao nó tải chậm vậy , đang học lúc nào cũng bị gián đoạn
@HelloEveryOne-i1g2 ай бұрын
ai muốn sếp làm video về refresh token cho mình xin 1 like
@ThanhLuan-eg7du5 ай бұрын
Cho em hỏi là khi nào mình ra khoá NextJS vậy ạ
@chienvuduy28365 ай бұрын
Anh ơi cho em hỏi với ạ, em muốn export cơ sở dữ liệu trong mongodb, em tìm trên mạng thì thấy hướng dẫn bằng command mongodump, nhưng em cài mongodb 6.0 thì k thấy có mongodump, anh có thể hướng dẫn em cách export dữ liệu được k ạ
@thisistoan6 ай бұрын
Anh cho em hỏi 2 câu hỏi mong anh cho e xin ý kiến ạ. Nếu câu hỏi em có sai sót mong anh bỏ qua😁 Em cảm ơn nhiều ạ ^^ 1) Em dùng kiểu session để lưu token vào database, thì mình có thể giải quyết vấn đề scale ngang, nhưng sẽ dẫn đến vấn đề tốc độ xử lý chậm vì phải xuống db check mỗi lần đăng nhập(hay vào một private route), với nhiều user thì làm nặng db. Em nghĩ như thế có đúng không anh? 2) Em mới tìm hiểu về jwt chưa có kiến thức nhiều, vì jwt là stateless thì giả sử trong trường hợp server một đăng xuất một người dùng nào đó thì làm sao ạ? Giả sử mình lưu jwt ở cookie rồi dùng res.clearCookie ở server thì ổn không anh? Giả sử mình lưu thêm refresh token(stateful) rồi hạ thời gian valid của accesstoken xuống, rồi xoá refresh token ở server thì cũng không thể nào làm logout ngay lập tức được đúng không anh? Không biết mình có cách khắc phục nào không ạ?
@F8VNOfficial6 ай бұрын
Hi em, 1. Việc em dùng JWT để authentication lợi hơn so với việc lưu session ở DB ở điểm là JWT nó tối ưu hiệu năng hơn, trường hợp token không hợp lệ thì nó check ở middleware và không cần chọc vào DB, token hợp lệ nó mới chọc vào DB thôi; còn session lưu DB thì dù đúng/sai vẫn cần chọc vào DB để check. 2. Nếu theo lý thuyết JWT và xài theo stateless thì server không lưu trạng thái của user nên server không đăng xuất được user đâu. Kể cả em có xoá token ở client thì chỉ đăng xuất ở trình duyệt đó; nếu token bị lộ thì nó vẫn xài được cho tới khi tới exp; vì JWT ký theo cách đó em chỉ có cách tới tương lai để nó hết hạn thôi. Đúng như em nói, em để exp access token thấp và xài refresh token (stateful) thì em xoá refresh token đi sau đó ngồi chờ access token hết hạn thì user mới đăng xuất. Vì vậy, để xử lý triệt để hơn thì đầu tiên tạo blacklist cho access token trên server (lại thành stateful), viết thêm API logout và push access token vào blacklist (có thể lưu vào Redis với exp bằng thời gian còn lại của access token), ở bước verify thì check cả xem access token có trong blacklist hay không. Khi server muốn đăng xuất user nào thì có thể xoá refresh token đồng thời bắn websocket* về cho client gọi logout để đưa access token vào blacklist. Việc này gọi là thu hồi token (revoke), vì JWT mình không làm cho nó hết hạn được (ngoài ngồi chờ). Một số người họ chỉ xoá token ở client đi thôi. Làm vậy token bị lộ vẫn xài được cho tới khi hết hạn. Nên với hệ thống yêu cầu bảo mật hơn thì em có thể áp dụng cách trên nhé. Nói chung còn tuỳ vào từng yêu cầu bảo mật của mỗi hệ thống, nếu em có yêu cầu cụ thể thì nói cụ thể hơn anh em bàn tiếp nhé. *Xài websocket chỉ có ý nghĩa khi user đang mở web trên trình duyệt thôi, nếu đang offline hoặc lỗi connect websocket thì không được. Nên em có thể check xem user có còn refresh token hay không, khi truy cập trở lại mà access token còn hạn nhưng refresh token không còn thì có thể xử lý cho user đăng xuất nhé.
@thisistoan6 ай бұрын
@@F8VNOfficial ohh em cảm ơn anh nhiều ạ☺️☺️ em hiểu hơn rồi, anh trả lời tận tình quá em cảm ơn rất nhiều 😊🙏🙏
@tuananhhoang8565 ай бұрын
chao a va moi nguoi . cho e hoi: ví dụ nếu res.render('home',{userData}) co cach nao de header o partials cung nhan duoc userData khong a . e muon kiem tra neu nguoi dung dang nhap thi se hien thi logout
@okenoc5 ай бұрын
em chào anh sơn ạ, anh ơi cho em hỏi là khoá React Js của bên f8 mình chưa hoàn thiện ạ
@vncoolestguy3 ай бұрын
Hóng video mới của seriea này.
@khoang156Ай бұрын
Mình thấy jwt có hàm .sign để tạo token mà bạn sao mình phải tạo token thủ công như này vậy ? Bảo mật hơn hả bạn ?
@thinhtran210528 күн бұрын
làm thủ công để hiểu bản chất mà bạn
@anhtuanpham22706 ай бұрын
anh làm thêm refresh token dựa vào code video được không ạ
@F8VNOfficial6 ай бұрын
Okie em nha
@nguyenhuutri83895 ай бұрын
Mong anh làm về Browser Caching
@nhathao695 ай бұрын
Hóng SSO anh ơi và mirco server la gì nữa anh ơi
@F8VNOfficial5 ай бұрын
Rảnh anh sẽ làm em nha
@newhorizon72156 ай бұрын
Em có 1 câu hỏi là khi mình sign và verify thì em dùng khóa bất đối xứng. Thì anh nghỉ mình nên generate nó trong code hay mình tạo rồi gắn trong .env ạ
@F8VNOfficial6 ай бұрын
Config thì nên đưa ra env em nhé. Không cần phải là khoá bất đối xứng, mà config nói chung cho dự án cũng nên đưa ra env. Bản thân một dự án có nhiều môi trường khi phát triển: dev, staging, UAT, production. Đưa ra env giúp dễ dàng cấu hình khác nhau giữa các môi trường, và cũng bảo mật hơn khi có thể ignore các file env mà không đẩy lên Git em nhé.
@tuandanh70486 ай бұрын
ra video phần đăng nhập bằng Facebook, Github .... đi anh ôi
@thinhminh95696 ай бұрын
Em chào anh, em thắc mắc là sao khi anh thay thế/bỏ các kí tự đặc biệt rồi khi anh giải mã ra thì nó vẫn giải mã được ạ? Ví dụ trong bài anh encodedHeader ra "abc=" sau khi anh bỏ dấu '=' đi thì còn "abc". Vậy sao khi giải mã ra nó vẫn ra đúng cái object ban đầu anh nhỉ? (Em xin lỗi nếu câu hỏi của em hơi ngớ ngẫn hoặc em bị miss phần nào đó)
@F8VNOfficial6 ай бұрын
À vì đó là base64url nha em, tức là để hợp lệ việc lưu base64 vào cookie hoặc truyền nó qua URL param thì người ta cho phép chuyển đổi như vậy nha em, mục đích là để an toàn cho URL và cookie và vẫn là base64 hợp lệ.
@F8VNOfficial6 ай бұрын
Cách chuyển sang base64url: - Chuyển + thành - - Chuyển / thành _ - Xóa bỏ dấu = đây em nhé. Đừng thay thế theo cách khác, như thế nó sẽ không hợp lệ nữa.
@thinhminh95696 ай бұрын
@@F8VNOfficial Dạ vâng em cảm ơn anh ạ
@lh49553 ай бұрын
Ra seri Vue 3 đi F8
@nguyenanh-vt4jv4 ай бұрын
anh ơi anh ra clip về SSO đi ạ
@BangNguyen-hd6sk6 ай бұрын
Hôm nay a giống e, đều ngủ sớm :))
@F8VNOfficial6 ай бұрын
2-3h sáng sớm đi ngủ là ngủ sớm ý hả :)))
@DuyKhoa-yd5tf6 ай бұрын
Lưu token trực tiếp vào DB rồi so sánh với request dc k v a
@F8VNOfficial6 ай бұрын
Được nha em, nhưng làm vậy thì không cần dùng JWT nữa. Vì cách làm như em nói thì lưu token trong DB, nên không cần lưu dữ liệu trong token như JWT nữa. Tùy vào từng bài toán thì mình lựa chọn cách xài cho phù hợp thôi em ạ. Như JWT thì nó có thể dùng xác thực tính hợp lệ thôi (không cần phải xác thực người dùng, tình huống đó thậm chí không cần query vào DB). Còn tình huống lưu token vào DB thì bắt buộc phải query để xác thực và thiết kế DB chỗ đó cũng phức tạp hơn JWT (nó đẩy data vào payload rồi nên server hay DB không phải lưu), dù tình huống không thực sự cần làm vậy => tăng tải server hơn.
@iamnguyenhoanganh6 ай бұрын
xong khoá này rồi, anh cho em luôn 1 video về SSO được không ạ =))
@F8VNOfficial5 ай бұрын
Okie em rảnh anh làm thêm nha
@thuytruongluu36696 ай бұрын
Bạn cho hỏi: mình tạo một webserver độc lập, khi login thì sẽ chạy sang một server khác để kiểm tra, nếu đúng thì sẽ trả lại một token. Ví dụ: mình viết 1 web cho login bằng google, đương nhiên login bằng google thì sẽ được hướng dẫn cách thực hiện và có thư viện nhưng ở đây website cho login cũng là tự viết, chỉ biết là trả lại một token. Vậy mình làm sao biết token đấy là chính xác? Tất nhiên khi gọi login thì vẫn truyền theo các biến được quy định riêng. Tôi có đọc 1 tài liệu trên trang Microsoft, họ dạy cách sau khi giải mã token được payload thì sẽ so sánh các biến trong payload với các biến truyền vào lúc gọi login. Cách này thì vẫn lưu session thôi nhưng được cái người dùng sẽ chỉ nhớ 1 mật khẩu cho các trang web khác nhau. Trong mỗi csdl của 1 trang web vẫn có bảng user để phục vụ phân quyền. Tôi thấy cách này hợp lý do các trang web ko phải đều phát triển từ đầu và do nhiều nhà phát triển khác nhau.
@F8VNOfficial5 ай бұрын
Chào bạn, khi bạn có nhiều web server và sử dụng một web server để cấp phát token thì server đó gọi là Authorization server, con này chỉ để cấp phát token (cả trường hợp refresh token) thôi. Còn ở các web server khác để verify được token thì bạn sẽ share JWT_SECRET key ở các server đó nữa, nhưng làm vậy thì rủi ro lộ key sẽ cao hơn, và khi lộ attacker có thể tự generate token hợp lệ. Cách xử lý trong thực tế là thay vì dùng khóa đối xứng (một khóa vừa cấp phát vừa xác thực token) thì bạn dùng khóa bất đối xứng, ví dụ RSA. Tại Auth server bạn lưu Private key để cấp phát token thôi, và share Public key tới các server cần xác thực. Public key chỉ có thể xác thực được token mà không tạo được token mới bạn nhé. Một cách nữa là thay vì share public key như trên, thì sau khi Auth server cấp phát token, đứng từ bên web server khác bạn dùng token đó gọi sang Auth server để xác thực. Sau khi xác thực thành công, thì từ web server đó vẫn cần query vào DB để lấy ra thông tin user tương ứng bạn nha. Có thể các web server đều dùng chung một bảng users trong DB, hoặc cũng có thể sau khi xác thực thì call API sang Auth server để lấy thông tin user, hoặc cũng có thể mỗi trang có một DB users riêng và sync users data từ Auth server, hoặc cũng có thể sau khi xác thực bạn lại tự đăng ký một user với trong DB riêng của mỗi trang web, ánh xạ 1-1 giữa UserID từ Auth server với UserID của DB riêng của trang web. Nói chung nó tùy vào từng trường hợp cụ thể mà ta có cách xử lý khác nhau bạn ạ.
@thuytruongluu36695 ай бұрын
@@F8VNOfficial ok, xin cám ơn. Tôi nghĩ cách thực tế vẫn là check token.
@F8VNOfficial5 ай бұрын
@@thuytruongluu3669 Nếu cùng một hệ thống do ta tự xây dựng thì việc share public key cho các web server tự check token là một giải pháp hiệu quả và an toàn bạn nhé.
@thuytruongluu36695 ай бұрын
@@F8VNOfficial vâng, nhưng như tôi đã nói, do nhiều bên xây dựng, thời gian phát triển cũng ko giống nhau. Ở đây các hệ thống sau chỉ thừa hưởng chức năng nhập và quản lý người dùng của hệ thống trước (mục đích để người dùng đỡ phải dùng nhiều tài khoản) nên giải pháp thực tế là check token là hợp lý. Khi đăng nhập lần đầu sẽ tạo luôn người dùng để phục vụ phân quyền riêng cho từng hệ thống.
@nguyenthientu25235 ай бұрын
ở đoạn cuối lấy data chổ atob(payload) em bị dính cái InvalidCharacterError: Invalid character thì fix làm sao anh
@F8VNOfficial5 ай бұрын
Em đọc lại comment ghim của anh để sửa lại hàm base64url cho đúng nha em.
@nguyenthientu25235 ай бұрын
@@F8VNOfficial cảm ơn anh
@ucanhly11664 ай бұрын
Hay quá anh ơi
@animeedits99364 ай бұрын
làm khóa học vuejs anh ơi
@uchuynhnguyen97595 ай бұрын
tại sao token chèn "Bearer" xong đẩy về BE lại tách bỏ nó đi ạ
@F8VNOfficial5 ай бұрын
Nó là tiêu chuẩn authentication, ví dụ với xác thực cơ bản (Basic Auth) thì sẽ gửi tiêu đề với Authorization: Basic , với token thì nó là Authorization: Bearer , tức nó là tuân theo tiêu chuẩn để phân biệt các hình thức Authorization. Nếu em không gửi kèm Bearer cũng được thôi, nhưng gửi như vậy thì không cụ thể là em đang dùng chuẩn nào. Em có thể tìm hiểu thêm qua từ khóa "Http Header Authorization" nhé.
@nhathao692 ай бұрын
Rã đông đi anh ơi...
@thanhduongphan3156 ай бұрын
Video rất hữu ích ạ
@quanghuytran73366 ай бұрын
Hay quá anh ơi!
@nvtentertainment40986 ай бұрын
ĐỢI MÃI MỚI THẤY ANH LAM JWT
@khaile76916 ай бұрын
video sao sẵn nói về blacklist sử dụng redis đi a
@F8VNOfficial6 ай бұрын
Blacklist đơn giản là "danh sách đen", các tokens trong danh sách này dù còn hạn nhưng cũng được coi là không hợp lệ. Còn lưu ra redis nó chỉ là một lựa chọn thôi em ạ (cho nhanh, và có thể đặt expires), còn mình vẫn lưu ra nơi khác như file, db, v.v tùy từng bài toán nha em.
@khaile76916 ай бұрын
@@F8VNOfficial tại sao lại cần đưa nó vào blacklist khi vẫn còn thời hạn v anh? để revoke nó khi cần đúng không anh?
@tuankiet.17016 ай бұрын
Dạ anh cho em hỏi, JWT thì frontend có cần học k ạ
@F8VNOfficial6 ай бұрын
Anh nghĩ đã là web developer thì sớm muộn cũng phải học em ạ. Ban đầu có thể với FE chỉ cần biết cách nhận, lưu trữ và hiểu về bảo mật token là được. Có thời gian cũng nên tìm hiểu xem nó hoạt động thế nào, tại sao nó lại bảo mật nha em.
@nguyenthinh37896 ай бұрын
Cảm ơn a ^^
@hoathai64536 ай бұрын
lại phải khen 🥰
@ThuanNguyen-uo3zt5 ай бұрын
vẫn mãi đợi JS pro
@viett27535 ай бұрын
anh làm về redis với elasticsearch đi anh:D
@F8VNOfficial5 ай бұрын
Cụ thể hơn thì bài toán của em là gì em nhỉ
@viett27535 ай бұрын
@@F8VNOfficial em muốn tìm hiểu về cơ chế với cách triển khai hệ thống caching để tối ưu thời gian gọi data ấy anh hoặc anh làm về docker để chạy services cũng hay ạ
@dungvu-fm8uq4 ай бұрын
anh ơi, bên F8 còn ra khóa JS Pro nữa không ạ?
@ienMeo-vj7rp4 ай бұрын
Có nhé bạn, có thông báo chuẩn bị sắp ra mắt rồi (trong khoá html/css pro mới thấy thông báo này)
@dungvu-fm8uq4 ай бұрын
@@ienMeo-vj7rp thông báo là JavaScript Pro (dự kiến Pre-Order cuối năm 2023) nhưng giờ qua được nửa năm 2024 rồi vẫn chưa thấy gì nên mình mới hỏi lại
@ienMeo-vj7rp4 ай бұрын
@@dungvu-fm8uq do ổng bận cộng thêm quả anh em mong chờ nên làm quả khoá java pro chất lượng hơn so với ban đầu (bạn xem live hôm trước sẽ thấy ổng nói câu này) . khoá pro thông báo sẽ lên lịch pre-order vào tháng 6 rồi. (Nhưng chắc chỉ đc 50% quá trình thôi vì ổng sơn cũng có nói khoá vẫn chưa hoàn thiện toàn bộ)
@HaChritian4 ай бұрын
@@ienMeo-vj7rp mình nhắn tin hỏi admin thì bạn ấy nói là chưa có kế hoạch gì cả, đợi thông báo chính thức từ anh Sơn ý (Vì lần này đợi xong 80-90% mới cho pre order cơ).
@ienMeo-vj7rp4 ай бұрын
@@HaChritian À do mình nhầm comment của anh ấy, tưởng ổng là người của F8 ai ngờ là hội viên, bây giờ chỉ biết ngồi chờ vậy. Xem anh tháng này đưa ra thông báo gì.
@tranvansi63022 ай бұрын
mn cho em hỏi anh Sơn xài font gì cho vs code thế ạ
@khoang156Ай бұрын
Fira code retina
@tranminhcuong66934 ай бұрын
mk thấy sesionID của cookie và jwtSecket của jwt có khác gì nhau đâu nhỉ. đều lưu bí mật ở đâu đó. và khi backend nhận request từ api thì đều cần tới 2 thằng bí mật kia để so sánh => xác thực. thế thì jwt có lợi gì hơn so với cookie vậy mọi người. ai đó đọc đc giải thích hộ mk với ạ. mk cảm ơn
@F8VNOfficial4 ай бұрын
Bạn xem đoạn đầu chưa. JWT nó là stateless authentication, session là stateful authentication.
@nvtmjfan6 ай бұрын
Tại sao cần Bearer vậy bạn.
@F8VNOfficial6 ай бұрын
Nó là chuẩn authentication bạn ơi. Ví dụ như có Basic Auth là loại xác thực cơ bản, thì xác thực với token nó là Bearer bạn nhé
@nvtmjfan6 ай бұрын
Ko có bearer có sao ko?
@SơnNguyễnThế-x5h6 ай бұрын
Bao giờ ra Js pro thế anh em đợi gần 2 năm ròi😢
@F8VNOfficial6 ай бұрын
Sắp rồi em ơi, tháng sau nha em ơi
@SơnNguyễnThế-x5h6 ай бұрын
Hóng quá ạ
@ThanhVo-tg9dn5 ай бұрын
anh cho e hỏi nếu header và payload bị lộ thì sao ạ
@F8VNOfficial5 ай бұрын
Thông tin công khai mà em. Lộ cũng không sao, em đừng đưa thông tin nhạy cảm vào đó là được. Có signature thì token đâu có fake được, trừ phi em để lộ secret thôi.
@ThanhVo-tg9dn5 ай бұрын
@@F8VNOfficial dạ anh ơi nếu trong payload mình để username và password thì khi lộ payload ra thì sẽ bị mã hóa ngược trợ lại đk ạ
@ThanhVo-tg9dn5 ай бұрын
và anh cho em hỏi là, JWT là để duy trì đăng nhập vậy có trường hợp nào mà user đã đăng nhập mà payload và header bị thay đổi dẫn đến ko thể tạo đc token mới để gian hạn không ạ, em cám ơn ạ
@nguyenhuutri83895 ай бұрын
@@ThanhVo-tg9dn JWT là sau khi xác thực (tức là đã đăng nhập) mới có token mà, sao lại bỏ password vào payload nữa, là sao?
@ThanhVo-tg9dn5 ай бұрын
@@nguyenhuutri8389 đr bạn sau khi login thành công mới có token. Nhưng bên trong payload để useẻname và pass vẫn đc chứ