ủa đợt scan không thấy gì hết có config gì đặc biệt ở sqlmap không

hay lắm bác

Mình gặp 1 vài lần rồi, toang lắm... a nêu thử ra vài trường hợp được không ạ, e chưa thấy được trường hợp nào toang lắm ạ

bài viết hữu ích, thanks bạn nhiều

Bạn tạo series để tiện theo dõi nhé

Đi phỏng vấn người ta hỏi câu có thể sử dụng id là string được hay k và vì sao, mình nên trả lời ntn đây a?, e cảm ơn

upload gì, vào đâu bị lỗi b nhir?

Quá hay

Tks các bác, tính ra 1 câu hỏi mà e hút được cả đống chân kinh về luyện, hihi

Mình cũng đồng ý với bạn rằng tác giả nên điều chỉnh phần này, Docker sinh ra không phải để ảo hóa, không thay thế cho các giải pháp ảo hóa. Nó cung cấp tính năng đóng gói, cách ly, khả chuyển các dịch vụ, và nó chạy chung kernel với hệ điều hành chủ.

bài viết hữu ích, thanks bạn nhiều

@buivansaobg bạn hoàn toàn có thể. như tiêu đề là mình sẽ hướng đến PURE JAVASCRIPT

chị ơi chị có thêm bài viết về các scenario còn lại chưa ạ

@thangtd90 @huusu1996 cảm ơn 2 ae ạ, e thì thấy là theo restful thì cái ý nghĩa của url cũng là cái quan trọng, nếu function là login thì ý nghĩa của nó chỉ là để redirect về hệ thống với trạng thái là đăng nhập, cũng như là POST /users/ là để tạo hay PUT /users/1 là để sửa vậy.

Em nghĩ là dù tạo ra cái gì thì nó cũng chỉ là phụ cho việc redirect về hệ thống với trạng thái khác. Giống như tạo users thì mình có thể tạo thêm relate đến các bảng khác thì ý nghĩa chính nó phải thể hiện ra được ở url. Do đó e nghĩ về bản chất dùng GET ở đây vẫn hoàn toàn là hợp lý. Em nghĩ chỉ là do thói quen từ lúc chưa code api nên thường dev vẫn tư tưởng là dùng POST.

Giống như trong link của a về restful có đề cập đó ạ:

Use GET requests to retrieve resource representation/information only – and not to modify it in any way.

việc token tạo ra tại thời điểm nào có lẽ cũng ko quan trọng với việc login vì e thấy bản chất chỉ là login để nhận lại token hoặc để nhận lại SID (ví dụ thậm chí có thể token hoặc SID đó đã tạo ra tư trước trên server nhưng chưa cung cấp cho người dùng mà sau khi đăng nhập ms cung cấp). Tương tự với logout cũng vậy ạ, tên url của nó chỉ là thoát ra khỏi hệ thống thôi chứ ko có mention đến việc là bên trong phải xóa hay làm gì ạ. Em nghĩ là để như vậy thì nó cũng đảm bảo được tính trong suốt với người dùng ạ.

P/S:

Em cũng có tham khảo với wiki và họ có refer đến 1 document giới thiệu của họ ở đoạn đầu (https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) Đại tỉ họ nói rằng

REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.

Cá nhân e hiểu thì họ muốn nói đến việc rằng việc biểu diễn của REST là tường minh ở url và không cần bận tâm đến detail bên trong. Do đó e nghĩ mình hoàn toàn có thể dùng GET với cả 2 TH là login và logout ạ. Đó là quan điểm của em ạ.

Ổn áp đấy anh

@thangtd90 Vâng ạ. Em cảm ơn anh, em thấy các anh phân tích thành destroy và create hoặc store khá hay. Cũng như cách anh @1111 gom thành 2 cái get và post hay @bs90 gom thành get và anti-get, dù trên lí thuyết đúng là không đúng nhưng khá hợp lí, tùy vào lăng kính của mỗi người

@huusu1996 Uhm đúng rồi. Ở trên chỉ là cách diễn giải cho mọi người khi muốn viết dưới dạng Resful Controller thôi, chứ phần login/logout mọi người cũng không cần thiết cứ phải ép vào restful làm gì cả. Như Laravel thì có cái LoginController, với method đặt tên hẳn là login và logout, rồi dùng method POST cho cả 2 action này Cứ đơn giản như thế là dễ hiểu =))

Còn như viết theo kiểu restful như cái gem Devise của Rails thì ngày trước hồi mới tìm hiểu và training về Rails thì anh cũng từng được anh CTO hồi đó của công ty giải thích theo cách ở trên (dùng SessionController với action create và destroy, method lần lượt là POST và DELETE), nghe xong thì Eureka và nhớ cho đến ngày nay =))

@thangtd90 Đúng là bản chất là bản chất là đôi khi lại không là "bản chất" Em hỏi xem cách mọi người đang nhìn nhận vấn đề như nào thôi ạ. Thực tế thì em thấy thằng Auth của laravel nó vấn để action là login hay logout, quan trọng là khi nhìn vào ai cũng hiểu hàm này có action gì ? làm những công việc gì ?

window.url e hay viết như sau.

<label>Avatar</label>
<label for="avatar" class="btn btn-success">Upload</label>
<input id="avatar" style="visibility:hidden;" type="file" name="avatar">
<div id="preview"></div>

$('#avatar').on('change', function () {
        let img = `<img style="width: 120px; border-radius: 50%" src="' + URL.createObjectURL(event.target.files[0]) + '">`;
        $('#preview').html(img);
})

@1111 ông hạ bớt cái tôi của mình xuống mà tiếp thu thì mới tiến bộ được

Bản chất là chỉ có POST, GET hả?? Giáo trình PHP cơ bản hay gì? Người ta đã tạo ra từng chuẩn RESTful khác nhau để dành cho các công việc khác nhau, ông thì lại đi thụt lùi so với tiến bộ, cố gộp hết cmnl để chứng minh cái tôi bé như con kiến của ông, thế bây giờ tôi bảo ông về xóa hết cmn code project của ông đi, viết hết lại thành POST api cho thỏa mãn cái tôi của ông, ông có làm không? Nhận sai 1 câu khó thế cơ à?