🎥 Mình đã có khóa Next.js Super trả phí: duthanhduoc.com/courses/nextjs-super 📕 Đây là link github khóa học Next.js Free, các bạn không cần phải submit email nữa: github.com/duthanhduoc/nextjs-free
Mình dùng cơ bản như axios interceptor + swr là ổn rồi. Làm kiểu RT trong server component khá rối. Mình có thử làm như bạn, về cơ bản thì đc nhưng khá nhiều case cần cover. Nếu đã tách source BE rồi thì các trường hợp cần SEO thì đa số k cần token đâu nhỉ ( theo mình biết là v, nếu có case nào thì góp ý cho mình ) nên mình nghĩ call api ở client là đc. Còn cần call api cho SEO thì k cần verify token -> call api trực tiếp trong Server Component và render ra data. NextJS làm SSR + Server Action thì mình nghĩ dành cho source nextjs thôi k cần BE Còn tach sourec BE và FE riêng thì dùng kiểu MERN Stack là được, cùng lắm thêm Server Component thôi. Có gì mng góp ý thêm
cốt lõi là xử lý ở route handler -> lưu Token ở cookie, với http only, tránh được XSS - hơn nhau ở cái http only, cái mà next client không bao giờ xử lý đc khi lưu ở các nơi truyền thống như local storage hoặc cookie không có http only
thế trường hợp bên client máy để cho ngủ, kiểu ng dùng đi đâu đó chơi, máy tự sleep nên client dừng chạy, tức là cái useEffect cũng dừng chạy luôn. Trong khoảng thời gian đó mà access token expire, rồi tới khi user mở máy lên lại ko gọi đc refresh api thì sao ạ?
@@cosmic12333 bạn phải check thêm trường hợp AT expire nhưng RT vẫn còn , thì lúc này cũng gửi request đến backend , thực tế refresh token api chỉ cần gửi RF ko cần gửi AT , lúc này backend sẽ cần destroy cả cặp AT và RT rồi tạo 1 cặp mới và return về cho FE
@@kno.99 RT đã lấy từ lúc login và sẽ refresh cùng AT liên tục , nếu bạn vẫn trong lifetime thì nó vẫn nằm trong storage đó thôi . Còn khi quá lâu đến nổi RT expire thì lúc đó hết phiên đăng nhập r bắt buộc phải login lại thôi
@@kid_katsu Mình đang nói về vấn đề SSR ở nextjs, RT còn hạn được lưu ở cookie nhưng chỉ được gửi đến 1 endpoint nhất định, AT thì hết hạn, khi user vào page /home thì làm sao server get được AT mới trong khi không có RT? Nếu luôn luôn gửi RT để server có thể nhận được thì lại tăng rủi ro bảo mật do RT được gửi liên tục, nên có giải pháp nào cho trường hợp này không hay cần phải đổi cách khác nhỉ?
Anh ơi mình set cookie của AT và RT ở server thì ko cần phải cái router handler kia phải ko ạ. Mới cả mình xử lý cái expires của 2 cái đấy kiểu gì vậy ạ. Em xem 2 bài trước mà ko hiểu lắm. Mong anh giải đáp
ví dụ em làm thế này có được ko ạ. Em sẽ xét thời gian sống của cái cookie chứa access token lớn hơn thời gian sống của access token thì vì vậy khi mà access token hết hạn thì sẽ call api /refreshToken thì sẽ tạo đc một cookie mới với thời gian sống lại nhiều hơn cái access token mới
Đừng để hết hạn rồi mới call API em nhé, khó xử lý lắm. Tốt nhất thì gần hết hạn là refresh token. Còn server mà set cookie rồi thì ở client không cần lưu vào local storage thôi chứ vẫn phải nên dùng route handler lưu cookie cho next.js. Để next server biết đã login hay chưa
ở server thì em có thể lấy thông qua cookie mà user request lên. Còn client thì em nên lưu access token vào local storage nữa để lấy nhé. Chi tiết cách quản lý ntn anh có hướng dẫn kỹ trong khóa Next.js có phí đó em
Mình nên lưu thông tin user từ api gọi access_token ở cookie, quản lý cùng tương tự với access token, refresh token luôn cho tiện, đỡ mất công gọi lại nhiều không bạn?
anh cho em hỏi chút, khi login thành công thì server sẽ trả về refeshtoken và accesstoken, sau đó các request sau sẽ check nếu accesstoken hết hạn thì tự động gửi refeshtoken đã lưu khi login thành công lên server để server trả về accesstoken mới và refeshtoken thì cái refeshtoken server trả về này với cái refeshtoken ban đầu lúc login là 1 chứ anh nhỉ, và khi refeshtoken hết hạn thì cho về trang login luôn
là 2 em nhé, khi refresh token thì cái refresh token trả về là 1 refresh token mới có thời gian hết hạn trùng refresh token cũ. Đọc bài này của anh đi duthanhduoc.com/blog/p3-giai-ngo-authentication-jwt
@@duocdev liệu ở cái interceptors config axios ở phần instance.interceptors.request, em bắt hết lỗi hết hạn accesstoken và refreshToken dựa vào cái exp > Date.now() / 1000 được không anh nhỉ, không cần xử lý lỗi backend trả về ở instance.interceptors.response được không anh?
@@duocdev e mới test rồi sao nó chỉ hoạt động trên postman mà lại không hoạt đột trên client nhỉ hay e thiếu bước nào trên client, ở client e chưa xử lý gì về token cả
🎥 Mình đã có khóa Next.js Super trả phí: duthanhduoc.com/courses/nextjs-super
📕 Đây là link github khóa học Next.js Free, các bạn không cần phải submit email nữa: github.com/duthanhduoc/nextjs-free
Mình dùng cơ bản như axios interceptor + swr là ổn rồi.
Làm kiểu RT trong server component khá rối. Mình có thử làm như bạn, về cơ bản thì đc nhưng khá nhiều case cần cover.
Nếu đã tách source BE rồi thì các trường hợp cần SEO thì đa số k cần token đâu nhỉ ( theo mình biết là v, nếu có case nào thì góp ý cho mình ) nên mình nghĩ call api ở client là đc.
Còn cần call api cho SEO thì k cần verify token -> call api trực tiếp trong Server Component và render ra data.
NextJS làm SSR + Server Action thì mình nghĩ dành cho source nextjs thôi k cần BE
Còn tach sourec BE và FE riêng thì dùng kiểu MERN Stack là được, cùng lắm thêm Server Component thôi.
Có gì mng góp ý thêm
cốt lõi là xử lý ở route handler -> lưu Token ở cookie, với http only, tránh được XSS - hơn nhau ở cái http only, cái mà next client không bao giờ xử lý đc khi lưu ở các nơi truyền thống như local storage hoặc cookie không có http only
Xin cảm ơn anh đã chia sẽ những kiến thức này.
thế trường hợp bên client máy để cho ngủ, kiểu ng dùng đi đâu đó chơi, máy tự sleep nên client dừng chạy, tức là cái useEffect cũng dừng chạy luôn. Trong khoảng thời gian đó mà access token expire, rồi tới khi user mở máy lên lại ko gọi đc refresh api thì sao ạ?
khi đóng trình duyệt và access token expire thì access token cũng bị mất trong cookie nữa mình đang gặp case này chưa biết làm sao
@@cosmic12333 bạn phải check thêm trường hợp AT expire nhưng RT vẫn còn , thì lúc này cũng gửi request đến backend , thực tế refresh token api chỉ cần gửi RF ko cần gửi AT , lúc này backend sẽ cần destroy cả cặp AT và RT rồi tạo 1 cặp mới và return về cho FE
@@kid_katsuvậy câu hỏi đặt ra là khi nào nextjs nhận được RT khi người dùng vào trang lại để lấy AT mới?
Nếu luôn luôn gửi RT thì không phải cách hay
@@kno.99 RT đã lấy từ lúc login và sẽ refresh cùng AT liên tục , nếu bạn vẫn trong lifetime thì nó vẫn nằm trong storage đó thôi . Còn khi quá lâu đến nổi RT expire thì lúc đó hết phiên đăng nhập r bắt buộc phải login lại thôi
@@kid_katsu Mình đang nói về vấn đề SSR ở nextjs, RT còn hạn được lưu ở cookie nhưng chỉ được gửi đến 1 endpoint nhất định, AT thì hết hạn, khi user vào page /home thì làm sao server get được AT mới trong khi không có RT?
Nếu luôn luôn gửi RT để server có thể nhận được thì lại tăng rủi ro bảo mật do RT được gửi liên tục, nên có giải pháp nào cho trường hợp này không hay cần phải đổi cách khác nhỉ?
Anh ơi mình set cookie của AT và RT ở server thì ko cần phải cái router handler kia phải ko ạ. Mới cả mình xử lý cái expires của 2 cái đấy kiểu gì vậy ạ. Em xem 2 bài trước mà ko hiểu lắm. Mong anh giải đáp
ví dụ em làm thế này có được ko ạ. Em sẽ xét thời gian sống của cái cookie chứa access token lớn hơn thời gian sống của access token thì vì vậy khi mà access token hết hạn thì sẽ call api /refreshToken thì sẽ tạo đc một cookie mới với thời gian sống lại nhiều hơn cái access token mới
Đừng để hết hạn rồi mới call API em nhé, khó xử lý lắm. Tốt nhất thì gần hết hạn là refresh token. Còn server mà set cookie rồi thì ở client không cần lưu vào local storage thôi chứ vẫn phải nên dùng route handler lưu cookie cho next.js. Để next server biết đã login hay chưa
Anh ơi cho em hỏi, sau khi f5 thì làm sao mình lấy được expiresAt của cookie anh nhỉ?
ở server thì em có thể lấy thông qua cookie mà user request lên. Còn client thì em nên lưu access token vào local storage nữa để lấy nhé.
Chi tiết cách quản lý ntn anh có hướng dẫn kỹ trong khóa Next.js có phí đó em
@@duocdev Dạ em cảm ơn anh
Mình nên lưu thông tin user từ api gọi access_token ở cookie, quản lý cùng tương tự với access token, refresh token luôn cho tiện, đỡ mất công gọi lại nhiều không bạn?
User thì lưu vào global state đi bạn.
anh cho em hỏi chút, khi login thành công thì server sẽ trả về refeshtoken và accesstoken, sau đó các request sau sẽ check nếu accesstoken hết hạn thì tự động gửi refeshtoken đã lưu khi login thành công lên server để server trả về accesstoken mới và refeshtoken thì cái refeshtoken server trả về này với cái refeshtoken ban đầu lúc login là 1 chứ anh nhỉ, và khi refeshtoken hết hạn thì cho về trang login luôn
là 2 em nhé, khi refresh token thì cái refresh token trả về là 1 refresh token mới có thời gian hết hạn trùng refresh token cũ. Đọc bài này của anh đi
duthanhduoc.com/blog/p3-giai-ngo-authentication-jwt
@@duocdev liệu ở cái interceptors config axios ở phần instance.interceptors.request, em bắt hết lỗi hết hạn accesstoken và refreshToken dựa vào cái exp > Date.now() / 1000 được không anh nhỉ, không cần xử lý lỗi backend trả về ở instance.interceptors.response được không anh?
Ví dụ trên res của server mình res.cookie cả accessToken và refreshToken luôn để không phải xử lý dưới client nữa thì có hợp lý không anh
Được, đó là 1 trong 2 cách anh có nói trong khoá này đó em. Như vậy thì client quá khoẻ rồi
@@duocdev e mới test rồi sao nó chỉ hoạt động trên postman mà lại không hoạt đột trên client nhỉ hay e thiếu bước nào trên client, ở client e chưa xử lý gì về token cả
Sử dụng thuộc tính credential bên fetch api thì nó mới gửi cookie theo request
@@duocdev em cảm ơn anh nhé để e test lại