Em cũng thử cách này rồi, cũng không cài đặt được

type-hint nghĩa là gì ad ?

Khi sử dụng unoconv thì báo lỗi như thế nào vậy bạn ?

Tks Anh zaiii 😜

thanks. e.

A nghĩ là làm ở đâu cũng được, miễn là e thấy vui 😁

bây giờ bạn đang làm việc tại Nhật hay Vn vậy!

bonus thêm: ở các phiên bản java mới hình như là từ java11 thì phải, interface đã có thêm access modifiers là default và static và có thể thêm body cho các phương thức sử dụng 2 access Modifiers này!

kiểu type bạn hiểu nôm na giống như cái table của sql vậy, nhưng nó cũng sẽ có nhiều cái khác với table của sql. bạn có thể đọc qua link này để hiểu hơn nhá: https://stackoverflow.com/questions/36649113/what-does-the-type-mean-in-elasticsearch

Cassandra không có where "or". Nên khi thiết kế hệ thống mà dùng database này thì các bạn nên chú ý.

@huytuchim789 phải đăng nhập mới thấy được full comments b ơi.

thanks bác

Bài viết hay quá, cảm ơn bạn nhiều, hy vọng bạn sẽ ra thêm nhiều bài viết hữu ích như vậy

đơn giản dễ hiểu

Domain Driven Desgin pattern cũng có ứng dụng kiến trúc lục giác này, code mà sử dụng DDD thì cực ngon

@xuanan2001 mình hiểu scenario của bạn. Nhưng bản chất nó là cuộc tấn công XSS thôi. Csrf bảo vệ được bạn vì form request từ domain khác không thể lấy csrf token từ cookie ra và submit lên được. Khi nó chạy từ chính domain của bạn thì nó không gọi là csrf attack vì script hoàn toàn truy cập được csrf token trong cookie. Việc lấy nó ra và gửi lên chỉ là một bước yêu cầu thôi. Từ cái tên thì bạn cũng thấy đây không phải là csrf attack rồi vì nó đến từ chính domain của bạn.

@xuanan2001 Mình túm lại nhé

• Việc bạn để JWT vào cookie chính xác là để hacker không lấy được nó ra. Nó là để bảo vệ bạn khi cuộc tấn công XSS đã xảy ra rồi, không phải là để bảo vệ bạn khỏi cuộc tấn công XSS. Khi bạn bị XSS thì tất nhiên hacker sẽ sử dụng được cookie của bạn rồi, nó là mục đích của XSS mà.
• CSRF không liên quan gì đến việc này, nó là để bảo vệ khi bạn bị CSRF attack, nếu bạn cảm thấy bạn không bị CSRF attack hoặc không quan tâm đến việc bị CSRF attack thì bạn bỏ qua nó cũng không ảnh hưởng gì đến mục đích của việc lưu JWT trong cookie.
• Việc bạn bị mất JWT lại là một lỗ hổng khác và nó có thể được khai thác bởi XSS chứ không phải chỉ là side-effect như bạn nghĩ. Như mình nói thì bạn có thể có những lớp bảo mật khác cho JWT và lưu nó trong httpOnly cookie là một trong số những lớp bảo mật đấy. Tùy security measure của bạn mà bạn lựa chọn những lớp bảo mật nào. Mình cũng ví dụ trường hợp nào bạn cần lớp bảo mật này rồi.

@phuongth Đây là thứ em muốn nói ạ: https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-perform-csrf

Nếu anh rảnh có thể xem qua và phân tích cách làm này ạ. Em thấy khá giống thứ em muốn nói.

@phuongth Anh đã đọc scenario của em chưa ạ? Anh có thể phân tích theo cái scenario trên đó ạ. Em nghĩ đến đây thì nó cũng lòng vòng và hơi dài rồi ạ.

Để làm rõ hơn việc chuyển từ tấn công XSS sang tấn công CSRF, em có thể ví dụ thế này:

Em lấy CSRF Token của anh trong localStorage về (Cookie mà không httpOnly thì cũng lấy được). Sau đó, XSS của em thực hiện một malicious HTTP POST có kèm CSRF Token này (Bởi vì nếu không có CSRF Token thì sẽ không make request được). Ở đây em không cần từ một domain khác, em vẫn có thể make request được. CSRF là chống khi em gửi request ở domain khác (social engineeering) thì cookie sẽ gửi kèm, nên nó gọi là "Cross-Site". Em đang thực hiện request "Cùng site" từ XSS, nhưng em vẫn cần CSRF Token để thực hiện request.

@phuongth Scenario trên không cần chuyển trang khác anh ạ. Em bảo "lấy về" là "lấy về script" ạ. Em xin lỗi vì làm anh hiểu nhầm. Và em không cần lấy nó ra ạ. Mong anh đọc lại câu trả lời của em.

Em có thể blacklist JWT nếu JWT của user bị compromised.

Em đồng ý cách của em không tốt. Em có thể expire các thứ như anh nói, ok ạ.

Quá hay, người chưa viết test bao giờ như em cảm thấy rất cuốn hút. Cho khả năng tạo ra sản phẩm chất lượng.