thì cũng đơn giản mà

Viết khá tốt, bố cục khoa học, nhiều đoạn code ví dụ giúp hiểu rõ ràng. Cám ơn bạn!

Hay quá . cảm ơn anh đã cho em thêm kiến thức

Bình luận của mình sẽ chia thành 2 phần:

1. Bình luận về các bình luận khác

Ở bài có 2 bình luận, cách nhau 2 năm, nhưng đều khẳng định là tác giả có kiến thức hạn chế về security. Mình không làm về security, nhưng có am hiểu cơ bản về networks, và sau khi đọc bài trên, mình thấy các mẩu kiến thức đều rất dễ hiểu và hợp lý, không có chỗ nào "suy luận" quá dẫn đến "mindset lệch lạc". Rất mong 2 bạn đăng bình luận trước mình chia sẻ thêm vì sao tác giả lại thiếu kiến thức về security đến vậy. Rất có thể, vì mình đồng ý với bài viết của tác giả, nên mình cũng là người "có hiểu biết hạn chế", vì vậy mình rất mong muốn được học hỏi thêm. Tuy nhiên, mình có một nhận xét thế này. Là người làm IT, hẳn ai cũng mang sẵn tinh thần "không phần mềm nào là không có lỗi", hay "No system is safe" như có nhắc đến trong bài. Hãy giả sử rằng tác giả đúng là có kiến thức hạn chế về security, thì việc có nhiều kiến thức về security sẽ giúp bạn khẳng định HTTPS, hay bất kỳ một hệ thống nào đó là an toàn, không có lỗi? Các bạn phán xét về tác giả, nhưng rồi cũng không thể làm cho HTTPS bảo mật tuyệt đối. Vậy tại sao phán xét?

2. Mình có 1 câu hỏi: Trong hình thức tấn công Man in the Middle, khi user bị attacker chuyển hướng sang server của hắn nhằm chiếm được các thông tin cần thiết để giao tiếp với server thật (dưới tên người dùng). Sau bước này, để tiếp tục tấn công, attack nhất thiết phải giữ vị trí của mình ở giữa user và server thật (?). Vậy điều này có làm tăng thời gian nhận response nhìn chung của user không? Theo mình nghĩ là có, vì user buộc phải bị điều hướng sang server của attack trước. Vậy việc tăng độ trễ này trong thực tế có thể được phát hiện ra (bằng cảm nhận, bằng tool,...) không nhỉ?

Rất mong nhận được câu trả lời từ những bạn am hiểu security

Bạn đã từng làm dự án nào với Vaddin chưa vậy?

Amazing!

tuyệt vời ông mặt chời (ahihi)

Ơ mây zing gút chóp em

Vâng ạ

Thank bro

viết vội nên không check kịp ông ei :v

đầu tiên mình xin lỗi vì thiếu sót trong bài không có đường dẫn rõ ràng.

Đây là file httpd.conf, tùy vào OS mà bạn sử dụng (windows, mac, linux) mà đường dẫn của nó sẽ khác nhau nhé!

Cái này theo như mình test mấy demo trên kia thì có vẻ như MySql nó tùy từng trường hợp mà kill transaction nào. Đa số là kill transaction sau, tuy nhiên, có 1 case nó kill transaction trước đó là : Insert & update đồng thời (bảng chưa có data) Insert sau và Update trước. nhưng kết quả là transaction insert đc thực hiện

spam

spam

spam

đây là function core của Trait DetectsDeadlocks. Chỗ này chỉ là mình giải thích cách thức hoạt động reTry Transaction của Laravel thôi. Nó sẽ check xem exception phải là DeadLock thì mới reTry, còn nếu kp thì bắn ra exeption đó luôn.

sai chính tả hơi nhiều nghe

ồ, đúng rồi. cám ơn bạn nhé, mình sẽ sửa lại cho đúng ạ

bạn đang hỏi về ejectWithValue hử