thắc mắc [ReactJS + NodeJS] Refreshtoken bị lỗi khi 1 user gửi 2 yêu cầu cùng lúc

Thì đúng nhưng đó là khi làm server side rendering. Còn mình chỉ bàn trong case cụ thể này thì việc lưu token vào cookie nó vô nghĩa và insecure thôi. Vì token đã được gửi qua header rồi.
dùng cả cookie và storage mới là secure hơn
cookie thì vulnerable với CSRF
token lưu trong local storage thì vulnerable với XSS
Chủ thớt lưu AT trogn LS và lưu RT trong cookie thì ổn rồi có gì đâu mà insecure
 
Nhưng tại sao lại lưu access token và refresh token trong cookie ? Cái này cực kì insecure.

Thím nên tìm hiểu lại tác dụng của cookie và nên dùng nó trong trường hợp nào. Nói chung nếu thím đã send token ở header rồi thì k đặt trong cookie nữa. Ở client thì lưu trong localstorage.
AT e lưu trên localstorage khi nào request thì móc AT ra set vào header, còn RT e mới lưu trên cookie, e mới nhập môn trước cũng hơi thắc mắc vấn đề này google chỗ thì bảo localstorage chỗ thì bảo cookie nên sau e để nguyên ạ. Mong đc nghe các bác tranh luận nhiều hơn
 
Verify thì không đúng lắm, kiểm tra dsax hết hạn hay chưa thôi

via theNEXTvoz for iPhone
e search thì ở phía client ng ta thường có 2 solutions: 1 là dùng jwt.decode, 2 là jwt.verify.

Server thì đơn giản hơn chứ. Ko rõ bro gặp vấn đề gì.
Solution như trên ở client sẽ gặp tình huống khi mà request body ở dạng consumable (stream). Ngoài ra có khả năng loop inf nếu như luồng refresh token lại trigger một luồng refresh token khác.
bác có thể cho e xin 1 vài keyword được k ạ, e search hướng giải quyết ở phía server mà chưa ra

Xử lý tuần tự ở trên server, lấy RT và AT lần lượt, không bất đồng bộ là đc.
bác giải thích thêm được k ạ, theo e hiểu thì khi request A và B gửi tới server mà AT expired thì server sẽ response lỗi lúc đó client sẽ gửi 2 request refreshtoken kèm theo RT hiện tại, khi request refreshtoken A được xử lí xong, RT hiện tại sẽ bị xoá và trả về AT và RT mới cho client thì lúc này th request refreshtoken B được server xử lí với RT đã bị xoá trước đó, verify thành công nhưng tìm trong database của user k có RT đó -> xđ user đó bị hack -> xoá hết RT trong database -> lỗi.
 
dùng cả cookie và storage mới là secure hơn
cookie thì vulnerable với CSRF
token lưu trong local storage thì vulnerable với XSS
Chủ thớt lưu AT trogn LS và lưu RT trong cookie thì ổn rồi có gì đâu mà insecure
Hmm, mình đọc k kĩ tưởng chủ thớt lưu cả AT lẫn RT trên cookie.
Tuy nhiên mình nghĩ XSS attack klq gì lắm trong chuyện này, cả cookies lẫn local storage đều vulnerable thôi (dù local storage có hơi rủi ro hơn).

Tuy thế, vì đặc thù của cookie là sẽ được transmit theo mỗi request, nên k phù hợp với các data có tính chất long-lived như RT, theo mình nếu phải dùng cả 2 thì nên làm ngược lại, AT trên cookie và RT ở local storage.

Trong trường hợp này chủ thớt đã gửi AT qua header luôn thì chẳng cần lưu trong cookie làm gì nữa, cứ dùng local storage cho cả hai.
 
Hmm, mình đọc k kĩ tưởng chủ thớt lưu cả AT lẫn RT trên cookie.
Tuy nhiên mình nghĩ XSS attack klq gì lắm trong chuyện này, cả cookies lẫn local storage đều vulnerable thôi (dù local storage có hơi rủi ro hơn).

Tuy thế, vì đặc thù của cookie là sẽ được transmit theo mỗi request, nên k phù hợp với các data có tính chất long-lived như RT, theo mình nếu phải dùng cả 2 thì nên làm ngược lại, AT trên cookie và RT ở local storage.

Trong trường hợp này chủ thớt đã gửi AT qua header luôn thì chẳng cần lưu trong cookie làm gì nữa, cứ dùng local storage cho cả hai.
E thấy nhiều tài liệu lưu RT ở cookie với flag httpOnly + secure. Còn để tránh việc tự động append cookie thì cho cái flag credentials = false. Hình như với thằng axios thì flag này chỉ có hiệu lực tới những request đến cross-site, trong trường hợp same-site thì e nghĩ tự động append cũng không sao :)
 
Back
Top