Tôi đã chấp nhận một câu trả lời, nhưng thật đáng buồn, tôi tin rằng chúng tôi bị mắc kẹt với kịch bản tồi tệ nhất ban đầu của chúng tôi: CAPTCHA mọi người trong các nỗ lực mua hàng tào lao . Giải thích ngắn gọn: bộ nhớ đệm / trang trại làm cho không thể theo dõi lượt truy cập và bất kỳ cách giải quyết nào (gửi đèn hiệu web không được lưu trong bộ nhớ cache, viết vào bảng thống nhất, v.v.) làm chậm trang web tệ hơn các bot. Có khả năng một số phần cứng đắt tiền của Cisco hoặc tương tự có thể giúp ở mức cao, nhưng thật khó để biện minh cho chi phí nếu CAPTCHA của mọi người là một lựa chọn thay thế. Tôi sẽ cố gắng giải thích đầy đủ hơn sau này, cũng như dọn dẹp phần này cho những người tìm kiếm trong tương lai (mặc dù những người khác được chào đón để thử, vì đó là wiki cộng đồng).

Tình hình

Đây là về doanh số bán hàng tào lao trên woot.com. Tôi là chủ tịch của Woot Workshop, công ty con của Woot chuyên thiết kế, viết các mô tả sản phẩm, podcast, bài đăng trên blog và kiểm duyệt các diễn đàn. Tôi làm việc với CSS / HTML và tôi chỉ quen với các công nghệ khác. Tôi làm việc chặt chẽ với các nhà phát triển và đã nói chuyện qua tất cả các câu trả lời ở đây (và nhiều ý tưởng khác mà chúng tôi đã có).

Khả năng sử dụng là một phần lớn trong công việc của tôi, và làm cho trang web thú vị và vui vẻ là hầu hết các phần còn lại của nó. Đó là nơi mà ba mục tiêu dưới đây xuất phát. CAPTCHA gây hại cho khả năng sử dụng và bot đánh cắp niềm vui và sự phấn khích từ doanh số tào lao của chúng tôi.

Bots đang đóng sầm trang đầu của chúng tôi hàng chục lần một lần quét màn hình thứ hai (và / hoặc quét RSS của chúng tôi) để bán Random Crap. Khoảnh khắc họ thấy điều đó, nó kích hoạt giai đoạn thứ hai của chương trình đăng nhập, nhấp vào Tôi muốn Một, điền vào biểu mẫu và mua crap.

Đánh giá

lc : Trên stackoverflow và các trang web khác sử dụng phương pháp này, hầu như họ luôn giao dịch với người dùng được xác thực (đã đăng nhập), vì nhiệm vụ đang được thực hiện đòi hỏi điều đó.

Trên Woot, người dùng ẩn danh (không đăng nhập) có thể xem trang chủ của chúng tôi. Nói cách khác, các bot đập có thể không được xác thực (và về cơ bản là không thể theo dõi được ngoại trừ theo địa chỉ IP).

Vì vậy, chúng tôi quay lại quét IP, điều mà a) khá vô dụng trong thời đại mạng đám mây và thây ma và b) bắt quá nhiều người vô tội với số lượng doanh nghiệp đến từ một địa chỉ IP (không đề cập đến các vấn đề với ISP IP không tĩnh và hiệu suất tiềm năng để cố gắng theo dõi điều này).

Ồ, và có người gọi chúng tôi sẽ là kịch bản tồi tệ nhất có thể. Chúng tôi có thể gọi họ không?

BradC : Các phương pháp của Ned Batchelder trông khá tuyệt, nhưng chúng được thiết kế khá chắc chắn để đánh bại các bot được xây dựng cho một mạng lưới các trang web. Vấn đề của chúng tôi là bot được xây dựng đặc biệt để đánh bại trang web của chúng tôi. Một số phương pháp này có thể có thể hoạt động trong một thời gian ngắn cho đến khi các nhà viết kịch bản phát triển các bot của họ để bỏ qua honeypot, quét màn hình cho các tên nhãn gần đó thay vì id mẫu và sử dụng điều khiển trình duyệt có khả năng javascript.

lc một lần nữa : "Trừ khi, tất nhiên, sự cường điệu là một phần của kế hoạch tiếp thị của bạn." Vâng, nó chắc chắn là. Sự ngạc nhiên khi món đồ xuất hiện, cũng như sự phấn khích nếu bạn xoay sở để có được một thứ có lẽ nhiều hoặc quan trọng hơn những thứ nhảm nhí mà bạn thực sự nhận được. Bất cứ điều gì loại bỏ người đến trước / người đến trước đều gây bất lợi cho sự hồi hộp của 'chiến thắng' tào lao.

novatrust : Và tôi, cho một, chào mừng các lớp phủ bot mới của chúng tôi. Chúng tôi thực sự cung cấp RSSfeed để cho phép các ứng dụng bên thứ 3 quét trang web của chúng tôi để biết thông tin sản phẩm, nhưng không đi trước HTML của trang web chính. Nếu tôi giải thích đúng, giải pháp của bạn sẽ giúp mục tiêu 2 (vấn đề về hiệu suất) bằng cách hy sinh hoàn toàn mục tiêu 1, và chỉ từ bỏ thực tế là các bot sẽ mua hầu hết các crap. Tôi đã bình chọn phản hồi của bạn, bởi vì sự bi quan đoạn cuối của bạn cảm thấy chính xác với tôi. Dường như không có viên đạn bạc nào ở đây.

Phần còn lại của các câu trả lời thường dựa vào theo dõi IP, một lần nữa, dường như cả hai đều vô dụng (với botnet / zombie / mạng đám mây) và bất lợi (bắt nhiều người vô tội đến từ các điểm đến cùng IP).

Bất kỳ cách tiếp cận / ý tưởng khác? Các nhà phát triển của tôi tiếp tục nói "hãy làm CAPTCHA" nhưng tôi hy vọng sẽ có ít phương pháp xâm nhập hơn đối với tất cả những người thực sự muốn một số thứ nhảm nhí của chúng tôi.

Câu hỏi gốc

Giả sử bạn đang bán thứ gì đó rẻ có giá trị nhận thức rất cao và bạn có số lượng rất hạn chế. Không ai biết chính xác khi nào bạn sẽ bán mặt hàng này. Và hơn một triệu người thường xuyên ghé qua để xem bạn đang bán gì.

Bạn kết thúc với các kịch bản và bot cố gắng lập trình [a] tìm ra khi bạn bán mặt hàng nói trên và [b] đảm bảo rằng họ là một trong những người đầu tiên mua nó. Điều này hút vì hai lý do:

1. Trang web của bạn bị đánh sập bởi những người không phải con người, làm chậm mọi thứ cho mọi người.
2. Các nhà viết kịch bản kết thúc 'chiến thắng' sản phẩm, khiến các nhà chức trách cảm thấy bị lừa.

Một giải pháp có vẻ rõ ràng là tạo ra một số vòng để người dùng của bạn nhảy qua trước khi đặt hàng, nhưng có ít nhất ba vấn đề với điều này:

• Trải nghiệm người dùng thật tệ cho con người, vì họ phải giải mã CAPTCHA, chọn ra con mèo hoặc giải một bài toán.
• Nếu lợi ích nhận thức đủ cao và đám đông đủ lớn, một số nhóm sẽ tìm đường đi xung quanh bất kỳ tinh chỉnh nào, dẫn đến một cuộc chạy đua vũ trang. . .)
• Ngay cả khi các nhà viết kịch bản không thể 'giải quyết' tinh chỉnh của bạn, điều đó cũng không ngăn họ đóng sầm trang trước của bạn, và sau đó phát ra âm thanh báo động cho người viết kịch bản để điền vào đơn đặt hàng, theo cách thủ công. Nếu họ có được lợi thế từ việc giải quyết [a], họ có thể vẫn sẽ giành được [b] vì họ sẽ là người đầu tiên tiếp cận trang đặt hàng. Ngoài ra, 1. vẫn xảy ra, gây ra lỗi máy chủ và giảm hiệu suất cho mọi người.

Một giải pháp khác là theo dõi các IP đánh quá thường xuyên, chặn chúng khỏi tường lửa hoặc ngăn không cho chúng ra lệnh. Điều này có thể giải quyết 2. và ngăn chặn [b] nhưng hiệu năng đạt được khi quét IP là rất lớn và có thể sẽ gây ra nhiều vấn đề như 1. hơn là các kịch bản lệnh tự gây ra. Ngoài ra, khả năng kết nối mạng đám mây và zombie spambot khiến việc kiểm tra IP khá vô dụng.

Một ý tưởng thứ ba, buộc hình thức đơn hàng được tải trong một thời gian (giả sử, nửa giây) sẽ có khả năng làm chậm tiến trình của các đơn hàng nhanh chóng, nhưng một lần nữa, các nhà viết kịch bản vẫn sẽ là người đầu tiên, ở bất kỳ tốc độ nào không gây bất lợi cho người dùng thực tế.

Bàn thắng

1. Bán các mặt hàng cho người không có kịch bản.
2. Giữ cho trang web chạy ở tốc độ không bị chậm bởi bot.
3. Đừng làm phiền người dùng 'bình thường' với bất kỳ nhiệm vụ nào cần hoàn thành để chứng minh họ là con người.

Làm thế nào về việc triển khai một cái gì đó giống như SO làm với CAPTCHA?

Nếu bạn đang sử dụng trang web bình thường, có lẽ bạn sẽ không bao giờ nhìn thấy một trang web. Nếu bạn tình cờ tải lại cùng một trang quá thường xuyên, hãy đăng các bình luận liên tiếp quá nhanh hoặc một cái gì đó gây ra báo động, hãy làm cho họ chứng minh họ là con người. Trong trường hợp của bạn, đây có thể sẽ là tải lại liên tục của cùng một trang, theo dõi mọi liên kết trên một trang một cách nhanh chóng hoặc điền vào một mẫu đơn đặt hàng quá nhanh để trở thành con người.

Nếu họ thất bại trong việc kiểm tra x lần liên tiếp (giả sử 2 hoặc 3), hãy cho IP đó thời gian chờ hoặc biện pháp khác. Sau đó, vào cuối thời gian chờ, đổ chúng trở lại kiểm tra một lần nữa.

Vì bạn đã đăng ký người dùng truy cập trang web, nên bạn chỉ có IP để tiếp tục. Bạn có thể phát hành phiên cho mỗi trình duyệt và theo dõi theo cách đó nếu bạn muốn. Và, tất nhiên, hãy kiểm tra con người nếu có quá nhiều phiên được tạo lại liên tiếp (trong trường hợp bot tiếp tục xóa cookie).

Khi bắt được quá nhiều người vô tội, bạn có thể từ chối trách nhiệm trên trang kiểm tra con người: "Trang này cũng có thể xuất hiện nếu có quá nhiều người dùng ẩn danh đang xem trang web của chúng tôi từ cùng một vị trí. Chúng tôi khuyến khích bạn đăng ký hoặc đăng nhập để tránh điều này." (Điều chỉnh từ ngữ phù hợp.)

Ngoài ra, tỷ lệ cược mà người X đang tải cùng một trang cùng lúc từ một IP là bao nhiêu? Nếu chúng cao, có thể bạn cần một cơ chế kích hoạt khác cho báo động bot của mình.

Chỉnh sửa: Một tùy chọn khác là nếu họ thất bại quá nhiều lần và bạn tự tin về nhu cầu của sản phẩm, để chặn họ và khiến họ đích thân GỌI bạn để xóa khối.

Có người gọi có vẻ như là một biện pháp asinine, nhưng nó chắc chắn rằng có một con người ở đâu đó đằng sau máy tính . Điều quan trọng là phải đặt khối duy nhất cho một điều kiện gần như không bao giờ xảy ra trừ khi đó là bot (ví dụ: không kiểm tra nhiều lần liên tiếp). Sau đó, nó CUNG CẤP sự tương tác của con người - để nhấc điện thoại lên.

Đáp lại lời bình luận về việc họ gọi cho tôi, rõ ràng là có sự đánh đổi ở đây. Bạn có đủ lo lắng về việc đảm bảo người dùng của bạn là con người để chấp nhận một vài cuộc gọi điện thoại khi họ bán? Nếu tôi quá quan tâm đến việc một sản phẩm đến tay người dùng, tôi sẽ phải đưa ra quyết định này, có lẽ phải hy sinh một chút (nhỏ) thời gian trong quá trình này.

Vì có vẻ như bạn quyết tâm không để bot chiếm thế thượng phong / đánh sập trang web của bạn, tôi tin rằng điện thoại có thể là một lựa chọn tốt. Vì tôi không kiếm được lợi nhuận từ sản phẩm của bạn, tôi không có hứng thú nhận các cuộc gọi này. Bạn đã chia sẻ một phần lợi nhuận đó, tuy nhiên, tôi có thể trở nên quan tâm. Vì đây là sản phẩm của bạn, bạn phải quyết định mức độ bạn quan tâm và thực hiện phù hợp.

Các cách khác để phát hành khối chỉ không hiệu quả: hết thời gian (nhưng họ sẽ lại đánh sập trang web của bạn sau đó, lặp lại), một thời gian dài (nếu đó thực sự là một con người đang cố gắng mua sản phẩm của bạn, họ sẽ bị SOL và bị phạt vì không kiểm tra), email (dễ dàng thực hiện bởi bot), fax (tương tự) hoặc thư email (mất quá nhiều thời gian).

Tất nhiên, thay vào đó, bạn có thể tăng thời gian chờ cho mỗi IP cho mỗi lần họ hết thời gian chờ. Chỉ cần chắc chắn rằng bạn không vô tình trừng phạt con người thật.

Bạn cần tìm ra một cách để làm cho các bot mua những thứ được định giá quá lớn: wingnut 12 mm: $ 20. Xem có bao nhiêu bot chụp lên trước khi các tác giả kịch bản quyết định bạn chơi chúng.

Sử dụng lợi nhuận để mua thêm máy chủ và trả tiền cho băng thông.

Giải pháp của tôi sẽ là làm cho màn hình trở nên vô dụng bằng cách đặt độ trễ khoảng 10 phút cho 'bot và tập lệnh.

Đây là cách tôi làm:

• Đăng nhập và xác định bất kỳ người lặp lại.

Bạn không cần phải đăng nhập mọi địa chỉ IP trên mỗi lần truy cập. Chỉ theo dõi một trong số 20 lượt truy cập hoặc hơn. Một người vi phạm nhiều lần sẽ vẫn xuất hiện trong một lần theo dõi ngẫu nhiên.

• Giữ một bộ nhớ cache của trang của bạn từ khoảng 10 phút trước đó.

• Khi một hitter / bot lặp lại truy cập vào trang web của bạn, hãy cung cấp cho họ trang lưu trữ cũ 10 phút.

Họ sẽ không biết ngay lập tức họ đang nhận được một trang web cũ. Họ sẽ có thể cạo nó và mọi thứ, nhưng họ sẽ không chiến thắng bất kỳ cuộc đua nào nữa, bởi vì "người thật" sẽ có thời gian bắt đầu 10 phút.

Những lợi ích:

• Không có rắc rối hoặc vấn đề cho người dùng (như CAPTCHA).
• Thực hiện đầy đủ về phía máy chủ. (không phụ thuộc vào Javascript / Flash)
• Phục vụ một trang cũ hơn, được lưu trong bộ nhớ cache sẽ có hiệu suất thấp hơn so với trang trực tiếp. Bạn thực sự có thể giảm tải cho máy chủ của bạn theo cách này!

Hạn chế

• Yêu cầu theo dõi một số địa chỉ IP
• Yêu cầu giữ và duy trì bộ nhớ cache của các trang cũ hơn.

Bạn nghĩ sao?

Hãy xem bài viết này của ned Batchelder tại đây . Bài viết của ông là về việc dừng spam, nhưng các kỹ thuật tương tự có thể dễ dàng áp dụng cho trang web của bạn.

Thay vì ngăn chặn các bot bằng cách mọi người tự nhận mình, chúng ta có thể ngăn chặn các bot bằng cách gây khó khăn cho chúng để tạo một bài đăng thành công hoặc bằng cách chúng vô tình tự nhận mình là bot. Điều này loại bỏ gánh nặng từ mọi người và để lại mẫu nhận xét không có các biện pháp chống thư rác có thể nhìn thấy.

Kỹ thuật này là cách tôi ngăn chặn spam trên trang web này. Nó hoạt động. Phương pháp được mô tả ở đây hoàn toàn không nhìn vào nội dung.

Một số ý tưởng khác:

• Tạo một cơ chế tự động thông báo chính thức (RSS feed? Twitter?) Mà mọi người có thể đăng ký khi sản phẩm của bạn được bán. Điều này làm giảm nhu cầu của mọi người để tạo ra các kịch bản.
• Thay đổi kỹ thuật obfuscation của bạn ngay trước khi một mặt hàng mới được bán. Vì vậy, ngay cả khi các nhà viết kịch bản có thể leo thang cuộc chạy đua vũ trang, họ vẫn luôn đi sau một ngày.

EDIT: Để hoàn toàn rõ ràng, bài viết của Ned ở trên mô tả các phương pháp để ngăn chặn việc MUA tự động các mặt hàng bằng cách ngăn BOT đi qua các biểu mẫu để gửi đơn đặt hàng. Các kỹ thuật của anh ta sẽ không hữu ích trong việc ngăn chặn các bot khỏi quét màn hình trang chủ để xác định khi nào một Bandoleer of Cà rốt được bán. Tôi không chắc chắn ngăn chặn điều đó là thực sự có thể.

Liên quan đến ý kiến ​​của bạn về hiệu quả của các chiến lược của Ned: Vâng, anh ấy thảo luận về honeypots, nhưng tôi không nghĩ đó là chiến lược mạnh nhất của anh ấy. Cuộc thảo luận của anh ấy về SPINNER là lý do ban đầu tôi đề cập đến bài viết của anh ấy. Xin lỗi tôi đã không làm rõ hơn trong bài viết gốc của mình:

Spinner là một trường ẩn được sử dụng cho một số thứ: nó băm cùng một số giá trị ngăn chặn giả mạo và phát lại, và được sử dụng để che khuất tên trường. Spinner là hàm băm MD5 của:

• Dấu thời gian,
• Địa chỉ IP của khách hàng,
• Id mục nhập của mục blog đang được nhận xét và
• Một bí mật.

Đây là cách bạn có thể thực hiện điều đó tại WOOT.com:

Thay đổi giá trị "bí mật" được sử dụng như một phần của hàm băm mỗi khi một mặt hàng mới được bán. Điều này có nghĩa là nếu ai đó sẽ thiết kế BOT để tự động mua các mặt hàng, nó sẽ chỉ hoạt động cho đến khi mặt hàng tiếp theo được bán !!

Ngay cả khi ai đó có thể nhanh chóng xây dựng lại bot của họ, tất cả những người dùng thực tế khác sẽ mua BOC và vấn đề của bạn đã được giải quyết!

Chiến lược khác mà ông thảo luận là thỉnh thoảng thay đổi kỹ thuật honeypot (một lần nữa, thay đổi nó khi một mặt hàng mới được bán):

• Sử dụng các lớp CSS (tất nhiên là ngẫu nhiên) để đặt các trường hoặc một phần tử có chứa để hiển thị: không có.
• Tô màu các trường giống nhau (hoặc rất giống với) nền của trang.
• Sử dụng định vị để di chuyển một trường ra khỏi khu vực hiển thị của trang.
• Tạo một phần tử quá nhỏ để hiển thị trường honeypot chứa.
• Để các trường hiển thị, nhưng sử dụng định vị để che chúng bằng một yếu tố che khuất.
• Sử dụng Javascript để thực hiện bất kỳ thay đổi nào trong số này, yêu cầu bot phải có công cụ Javascript đầy đủ.
• Để các honeypot hiển thị như các lĩnh vực khác, nhưng nói với mọi người không nhập bất cứ thứ gì vào chúng.

Tôi đoán ý tưởng tổng thể của tôi là THAY ĐỔI THIẾT KẾ MẪU khi mỗi mặt hàng mới được bán. Hoặc tại LEAST, thay đổi nó khi BOC mới được bán.

Đó là những gì, một vài lần / tháng?

Nếu bạn chấp nhận câu trả lời này, bạn sẽ cho tôi một cái đầu khi đến hạn tiếp theo? :)

Q: Làm thế nào bạn có thể ngăn các nhà viết kịch bản đóng sầm trang web của bạn hàng trăm lần một giây?
A: Bạn không. Không có cách nào để ngăn chặn hành vi này bởi các tác nhân bên ngoài.

Bạn có thể sử dụng một loạt công nghệ rộng lớn để phân tích các yêu cầu đến và cố gắng tìm cách xác định ai là ai và không phải là con người ... nhưng nó sẽ thất bại. Cuối cùng, nếu không ngay lập tức.

Giải pháp lâu dài duy nhất khả thi là thay đổi trò chơi để trang web không thân thiện với bot hoặc kém hấp dẫn hơn đối với các nhà viết kịch bản.

Làm thế nào để bạn làm điều đó? Vâng, đó là một câu hỏi khác nhau! ;-)

...

OK, một số tùy chọn đã được đưa ra (và bị từ chối) ở trên. Tôi không quen thuộc lắm với trang web của bạn, chỉ nhìn vào nó một lần, nhưng vì mọi người có thể đọc văn bản bằng hình ảnh và bot không thể dễ dàng làm điều này, hãy thay đổi thông báo thành hình ảnh. Không phải CAPTCHA , chỉ là hình ảnh -

• tạo hình ảnh (tất nhiên được lưu trữ) khi trang được yêu cầu
• giữ nguyên tên nguồn hình ảnh để không khiến trò chơi biến mất
• hầu hết thời gian hình ảnh sẽ có văn bản thông thường trong đó và được căn chỉnh để có vẻ là một phần của trang HTML nội tuyến
• khi trò chơi được 'bật', hình ảnh sẽ thay đổi thành văn bản thông báo
• văn bản thông báo cho thấy một url và / hoặc mã phải được nhập thủ công để có được giải thưởng. Mã CAPTCHA nếu bạn thích, nhưng điều đó có lẽ không cần thiết.
• để bảo mật bổ sung, mã có thể là mã thông báo một lần được tạo riêng cho yêu cầu / IP / tác nhân, để các yêu cầu lặp lại tạo ra các mã khác nhau. Hoặc bạn có thể tạo trước một loạt các mã ngẫu nhiên (bộ đệm một lần) nếu việc tạo theo yêu cầu quá thuế.

Chạy thử nghiệm thời gian của những người thực sự phản ứng với điều này và bỏ qua ('rất tiếc, đã xảy ra lỗi, xin lỗi! Vui lòng thử lại') phản hồi nhanh hơn (nói) một nửa thời gian này. Sự kiện này cũng sẽ kích hoạt một cảnh báo cho các nhà phát triển rằng ít nhất một bot đã tìm ra mã / trò chơi, vì vậy đã đến lúc thay đổi mã / trò chơi.

Tiếp tục thay đổi trò chơi định kỳ bằng mọi cách, ngay cả khi không có bot nào kích hoạt nó, chỉ để lãng phí thời gian của các nhà viết kịch bản. Cuối cùng, các nhà viết kịch bản sẽ mệt mỏi với trò chơi và đi đến nơi khác ... chúng tôi hy vọng ;-)

Một đề xuất cuối cùng: khi một yêu cầu cho trang chính của bạn xuất hiện, hãy đặt nó vào hàng đợi và trả lời các yêu cầu theo một quy trình riêng (bạn có thể phải hack / mở rộng máy chủ web để thực hiện việc này, nhưng rất có thể nó sẽ đáng giá). Nếu một yêu cầu khác từ cùng một IP / đại lý xuất hiện trong khi yêu cầu đầu tiên nằm trong hàng đợi, hãy bỏ qua nó. Điều này sẽ tự động giảm tải từ các bot.

EDIT: một tùy chọn khác, ngoài việc sử dụng hình ảnh, là sử dụng javascript để điền vào văn bản mua / không mua; bot hiếm khi giải thích javascript, vì vậy họ sẽ không nhìn thấy nó

Tôi không biết điều này khả thi đến mức nào: ... tấn công.

Chỉ ra những dữ liệu mà các bot đang quét. Cung cấp cho họ dữ liệu mà họ đang tìm kiếm khi bạn KHÔNG bán rác. Làm điều này theo cách không làm phiền hoặc gây nhầm lẫn cho người dùng. Khi các bot kích hoạt giai đoạn hai, chúng sẽ đăng nhập và điền vào biểu mẫu để mua 100 đô la phòng thay vì BOC. Tất nhiên, điều này giả định rằng các bot không đặc biệt mạnh mẽ.

Một ý tưởng khác là thực hiện giảm giá ngẫu nhiên trong suốt thời gian bán túi o crap. Ai sẽ mua một chiếc túi ngẫu nhiên với giá 150 đô la khi bạn R CLE RÀNG R that RÀNG rằng nó chỉ có giá trị 20 đô la? Không ai ngoài bot quá nhiệt tình. Nhưng sau đó 9 phút, nó là 35 đô la ... 17 phút sau đó là 9 đô la. Hay bất cứ cái gì.

Chắc chắn, các vị vua zombie sẽ có thể phản ứng. Vấn đề là làm cho những sai lầm của họ trở nên rất tốn kém đối với họ (và khiến họ phải trả tiền cho bạn để chiến đấu với họ).

Tất cả điều này giả định rằng bạn muốn chọc giận một số lãnh chúa bot, điều này có thể không được khuyến khích 100%.

Vì vậy, vấn đề thực sự có vẻ là: các bot muốn "cái túi" tào lao của chúng bởi vì nó có giá trị nhận thức cao ở mức giá thấp. Đôi khi bạn cung cấp mặt hàng này và các bot ẩn nấp, chờ xem liệu nó có sẵn không và sau đó họ mua mặt hàng đó.

Vì có vẻ như các chủ sở hữu bot đang kiếm được lợi nhuận (hoặc có khả năng tạo ra lợi nhuận), mẹo là làm cho điều này không có lợi cho họ bằng cách khuyến khích họ mua crap.

Đầu tiên, luôn luôn cung cấp "túi 'o crap".

Thứ hai, hãy chắc chắn rằng crap thường là tào lao.

Thứ ba, xoay crap thường xuyên.

Đơn giản, không?

Bạn sẽ cần một câu vĩnh viễn "tại sao đôi khi tào lao của chúng tôi?" liên kết bên cạnh lời đề nghị để giải thích cho con người những gì đang xảy ra.

Khi bot thấy rằng có tào lao và crap được mua tự động, người nhận sẽ vô cùng buồn bã rằng họ đã trả 10 đô la cho một cây tăm bị hỏng. Và sau đó là một túi rác rỗng. Và sau đó một số bụi bẩn từ dưới cùng của giày của bạn.

Nếu họ mua đủ thứ nhảm nhí này trong một khoảng thời gian tương đối ngắn (và bạn có những lời từ chối lớn ở khắp mọi nơi giải thích lý do tại sao bạn làm điều này), họ sẽ mất một "túi tiền" công bằng cho " túi 'o tào lao ". Ngay cả sự can thiệp của con người từ phía họ (kiểm tra để đảm bảo rằng crap không phải là tào lao) có thể thất bại nếu bạn xoay crap thường xuyên đủ. Heck, có thể các bot sẽ chú ý và không mua bất cứ thứ gì trong vòng quay quá ngắn, nhưng điều đó có nghĩa là con người sẽ mua những thứ không phải là tào lao.

Heck, khách hàng thường xuyên của bạn có thể thích thú đến mức bạn có thể biến điều này thành một chiến thắng tiếp thị khổng lồ. Bắt đầu đăng bao nhiêu cá chép "tào lao" đang được bán. Mọi người sẽ quay lại chỉ để xem các bot đã bị cắn khó như thế nào.

Cập nhật: Tôi hy vọng rằng bạn có thể nhận được một vài cuộc gọi lên phía trước với những người phàn nàn. Tôi không nghĩ bạn có thể ngăn chặn điều đó hoàn toàn. Tuy nhiên, nếu điều này giết chết các bot, bạn luôn có thể dừng nó và khởi động lại sau.

1. Bán các mặt hàng cho người không có kịch bản.

2. Giữ cho trang web chạy ở tốc độ không bị chậm bởi bot.

3. Đừng làm phiền người dùng 'bình thường' với bất kỳ nhiệm vụ nào cần hoàn thành để chứng minh họ là con người.

Có thể bạn không muốn nghe điều này, nhưng # 1 và # 3 là loại trừ lẫn nhau.

Chà, không ai biết bạn là bot cả. Không có cách lập trình nào để nói liệu có một người ở đầu kia của kết nối mà không yêu cầu người đó làm gì không. Ngăn chặn các tập lệnh / bot làm công cụ trên web là toàn bộ lý do CAPTCHA được phát minh. Nó không giống như đây là một số vấn đề mới mà chưa thấy nhiều nỗ lực dành cho nó. Nếu có một cách tốt hơn để làm điều đó, một cách không gây rắc rối cho người dùng thực sự mà CAPTCHA làm, mọi người sẽ sử dụng nó.

Tôi nghĩ rằng bạn cần phải đối mặt với thực tế rằng nếu bạn muốn loại bỏ bot khỏi trang đặt hàng của mình, CAPTCHA tốt là cách duy nhất để làm điều đó. Nếu nhu cầu về crap ngẫu nhiên của bạn đủ cao để mọi người sẵn sàng đi đến những chiều dài này để có được nó, thì những người dùng hợp pháp sẽ không bị CAPTCHA bỏ qua.

Phương pháp mà Woot sử dụng để chống lại vấn đề này là thay đổi trò chơi - theo nghĩa đen. Khi họ giới thiệu một mặt hàng cực kỳ mong muốn để bán, họ khiến người dùng chơi một trò chơi video để đặt hàng.

Không chỉ chiến đấu thành công với bot (họ có thể dễ dàng thực hiện các thay đổi nhỏ cho trò chơi để tránh người chơi tự động hoặc thậm chí cung cấp trò chơi mới cho mỗi lần bán) mà còn tạo ấn tượng cho người dùng "chiến thắng" vật phẩm mong muốn trong khi làm chậm quy trình đặt hàng.

Nó vẫn bán hết rất nhanh, nhưng tôi nghĩ rằng giải pháp đó là tốt - đánh giá lại vấn đề và thay đổi các tham số dẫn đến một chiến lược thành công trong đó các giải pháp kỹ thuật nghiêm ngặt đơn giản là không tồn tại.

Toàn bộ mô hình kinh doanh của bạn dựa trên "lần đầu tiên đến trước được phục vụ". Bạn không thể làm những gì các đài phát thanh đã làm (họ không còn biến người gọi đầu tiên thành người chiến thắng, họ biến người gọi thứ 5 hoặc 20 hoặc 13 trở thành người chiến thắng) - nó không phù hợp với tính năng chính của bạn.

Không, không có cách nào để làm điều này mà không thay đổi trải nghiệm đặt hàng cho người dùng thực.

Giả sử bạn thực hiện tất cả các chiến thuật này. Nếu tôi quyết định rằng điều này quan trọng, tôi sẽ đơn giản giúp 100 người cùng làm việc với mình, chúng tôi sẽ xây dựng phần mềm để hoạt động trên 100 máy tính riêng biệt của chúng tôi và truy cập trang web của bạn 20 lần một giây (5 giây giữa các lần truy cập cho mỗi người dùng / cookie / tài khoản / địa chỉ IP).

Bạn có hai giai đoạn:

1. Đang xem trang nhất
2. Đặt hàng

Bạn không thể đặt captcha chặn số 1 - điều đó sẽ làm mất khách hàng thực sự ("Cái gì? Tôi phải giải một captcha mỗi lần tôi muốn xem woot mới nhất?!?").

Vì vậy, nhóm nhỏ của tôi theo dõi, hẹn giờ với nhau để chúng tôi nhận được khoảng 20 kiểm tra mỗi giây và bất cứ ai nhìn thấy thay đổi trước tiên sẽ cảnh báo tất cả những người khác (sẽ tự động tải trang trước một lần nữa, theo liên kết đặt hàng và thực hiện giao dịch ( điều này cũng có thể xảy ra tự động, trừ khi bạn triển khai captcha và thay đổi nó cho mỗi wootoff / boc).

Bạn có thể đặt hình ảnh xác thực ở phía trước số 2 và trong khi bạn không thích làm điều đó, đó có thể là cách duy nhất để đảm bảo rằng ngay cả khi các bot xem trang trước, người dùng thực sự sẽ nhận được sản phẩm.

Nhưng ngay cả với captcha, nhóm 100 nhỏ của tôi vẫn có lợi thế đáng kể đầu tiên - và không có cách nào bạn có thể nói rằng chúng ta không phải là con người. Nếu bạn bắt đầu tính thời gian truy cập của chúng tôi, chúng tôi chỉ cần thêm một số jitter. Chúng ta có thể chọn ngẫu nhiên máy tính nào để làm mới để thứ tự truy cập thay đổi liên tục - nhưng trông vẫn đủ giống con người.

Đầu tiên, loại bỏ các bot đơn giản

Bạn cần có một tường lửa thích ứng sẽ theo dõi các yêu cầu và nếu ai đó đang làm điều ngu ngốc rõ ràng - làm mới hơn một lần một giây tại cùng một IP thì sử dụng các chiến thuật để làm chậm chúng (bỏ gói, gửi lại từ chối hoặc 500 lỗi, v.v. ).

Điều này sẽ làm giảm đáng kể lưu lượng truy cập của bạn và thay đổi các chiến thuật mà người dùng bot sử dụng.

Thứ hai, làm cho máy chủ nhanh chóng.

Bạn thực sự không muốn nghe điều này ... nhưng ...

Tôi nghĩ những gì bạn cần là một giải pháp hoàn toàn tùy chỉnh từ dưới lên.

Bạn không cần phải gây rối với ngăn xếp TCP / IP, nhưng bạn có thể cần phát triển một máy chủ tùy chỉnh rất, rất, rất nhanh, được xây dựng để tương quan các kết nối người dùng và phản ứng thích hợp với các cuộc tấn công khác nhau.

Apache, lighthttpd, v.v ... đều tuyệt vời vì linh hoạt, nhưng bạn điều hành một trang web có mục đích duy nhất và bạn thực sự cần có khả năng làm được nhiều hơn các máy chủ hiện tại có khả năng thực hiện (cả trong việc xử lý lưu lượng truy cập và chống lại các bot phù hợp ).

Bằng cách phục vụ một trang web tĩnh phần lớn (cập nhật cứ sau 30 giây hoặc lâu hơn) trên máy chủ tùy chỉnh, bạn không chỉ có thể xử lý gấp 10 lần số lượng yêu cầu và lưu lượng truy cập (vì máy chủ không làm gì khác ngoài nhận yêu cầu và đọc trang từ bộ nhớ vào bộ đệm TCP / IP) nhưng nó cũng sẽ cung cấp cho bạn quyền truy cập vào các số liệu có thể giúp bạn làm chậm các bot. Chẳng hạn, bằng cách tương quan các địa chỉ IP, bạn có thể chỉ cần chặn nhiều hơn một kết nối mỗi giây trên mỗi IP. Con người không thể đi nhanh hơn thế và thậm chí những người sử dụng cùng một địa chỉ IP NATed sẽ chỉ bị chặn thường xuyên. Bạn muốn thực hiện một khối chậm - để kết nối một mình trong một giây trước khi chính thức chấm dứt phiên. Điều này có thể cung cấp cho một tường lửa để cung cấp các khối dài hạn hơn cho những người phạm tội đặc biệt nghiêm trọng.

Nhưng thực tế là cho dù bạn có làm gì đi chăng nữa, không có cách nào để phân biệt con người với bot khi bot được con người tùy chỉnh xây dựng cho một mục đích duy nhất. Bot chỉ đơn thuần là một proxy cho con người.

Phần kết luận

Vào cuối ngày, bạn không thể phân biệt người và máy tính để xem trang nhất. Bạn có thể dừng bot ở bước đặt hàng, nhưng người dùng bot vẫn có lợi thế di chuyển đầu tiên và bạn vẫn có một tải trọng lớn để quản lý.

Bạn có thể thêm các khối cho các bot đơn giản, sẽ nâng thanh và ít người bận tâm hơn với nó. Điều đó có thể là đủ.

Nhưng không thay đổi mô hình cơ bản của bạn, bạn đã hết may mắn. Điều tốt nhất bạn có thể làm là chăm sóc các trường hợp đơn giản, làm cho máy chủ nhanh đến mức người dùng thường xuyên không chú ý và bán rất nhiều mặt hàng mà ngay cả khi bạn có vài triệu bot, như nhiều người dùng thông thường muốn họ sẽ có được chúng .

Bạn có thể xem xét việc thiết lập honeypot và đánh dấu tài khoản người dùng là người dùng bot, nhưng điều đó sẽ gây ra phản ứng dữ dội từ cộng đồng.

Mỗi khi tôi nghĩ về một "tốt, những gì về việc này ..." tôi luôn có thể chống lại nó bằng một chiến lược bot phù hợp.

Ngay cả khi bạn đặt trang trước thành hình ảnh xác thực để đến trang đặt hàng ("Nút đặt hàng của mặt hàng này có màu xanh lấp lánh, ở đâu đó trên trang này"), các bot sẽ chỉ cần mở tất cả các liên kết trên trang và sử dụng bất kỳ liên kết nào trên trang trở lại với một trang đặt hàng. Đó không phải là cách để giành chiến thắng này.

Làm cho máy chủ nhanh, đặt reCaptcha (người duy nhất tôi thấy không dễ bị lừa, nhưng có lẽ nó quá chậm cho ứng dụng của bạn) trên trang đặt hàng và nghĩ về cách thay đổi mô hình một chút người dùng thường xuyên có cơ hội tốt như người dùng bot.

-Adam

Disclaimer: Câu trả lời này hoàn toàn không liên quan đến lập trình. Tuy nhiên, nó cố gắng tấn công lý do cho các kịch bản ở nơi đầu tiên.

Một ý tưởng khác là nếu bạn thực sự có một số lượng hạn chế để bán, tại sao bạn không thay đổi nó từ một phương pháp đầu tiên đến trước được phục vụ? Trừ khi, tất nhiên, sự cường điệu là một phần của kế hoạch tiếp thị của bạn.

Có nhiều lựa chọn khác và tôi chắc chắn những người khác có thể nghĩ ra một số lựa chọn khác nhau:

• một hàng đợi đặt hàng (hệ thống đặt hàng trước) - Một số tập lệnh vẫn có thể kết thúc ở phía trước hàng đợi, nhưng có thể nhanh hơn khi chỉ nhập thông tin theo cách thủ công.

• một hệ thống xổ số (tất cả những người cố gắng đặt hàng đều được nhập vào hệ thống) - Bằng cách này, những người có tập lệnh có cơ hội giống như những người không có.

• một hàng đợi ưu tiên vội vàng - Nếu thực sự có giá trị nhận thức cao, mọi người có thể sẵn sàng trả nhiều tiền hơn. Thực hiện một hàng đợi đặt hàng, nhưng cho phép mọi người trả nhiều tiền hơn để được đặt cao hơn trong hàng đợi.

• đấu giá (tín dụng cho David Schmitt cho lần này, ý kiến ​​là của riêng tôi) - Mọi người vẫn có thể sử dụng các kịch bản để bắn tỉa vào phút cuối, nhưng không chỉ thay đổi cấu trúc giá, mọi người đang mong đợi được đấu tranh với những người khác . Bạn cũng có thể làm những điều để hạn chế số lượng giá thầu trong một khoảng thời gian nhất định, khiến mọi người gọi điện trước thời hạn cho mã ủy quyền, v.v.

Cho dù người Đức có an toàn đến mức nào khi liên lạc với họ, các đồng minh sẽ thường xuyên phá vỡ thông điệp của họ. Bất kể bạn cố gắng ngăn bot sử dụng trang web của mình như thế nào, chủ sở hữu bot sẽ tìm ra cách khắc phục nó. Tôi xin lỗi nếu điều đó làm cho bạn trở thành phát xít :-)

Tôi nghĩ rằng cần phải có một tư duy khác

• Đừng cố ngăn bot sử dụng trang của bạn
• Đừng tìm cách khắc phục ngay lập tức, hãy chơi trò chơi dài

Hãy suy nghĩ rằng việc khách hàng của trang web của bạn là người hay bot, cả hai đều chỉ là khách hàng trả tiền; nhưng người này có lợi thế không công bằng so với người kia. Một số người dùng không có nhiều đời sống xã hội (ẩn sĩ) có thể gây khó chịu cho những người dùng khác trên trang web của bạn như bot.

Ghi lại thời gian bạn xuất bản một ưu đãi và thời gian một tài khoản chọn mua nó.

Điều này cung cấp cho bạn một bản ghi về việc khách hàng mua đồ nhanh như thế nào.

Thay đổi thời gian trong ngày bạn xuất bản cung cấp.

Ví dụ: có một cửa sổ 3 giờ bắt đầu vào một số thời điểm tối nghĩa trong ngày (nửa đêm?) Chỉ các bot và ẩn sĩ sẽ liên tục làm mới một trang trong 3 giờ chỉ để nhận được một đơn đặt hàng trong vài giây. Không bao giờ thay đổi thời gian cơ sở, chỉ có kích thước của cửa sổ.

Theo thời gian một hình ảnh sẽ xuất hiện.

01: Bạn có thể xem tài khoản nào thường xuyên mua sản phẩm trong vòng vài giây sau khi chúng được phát hành. Đề nghị họ có thể là bot.

02: Bạn cũng có thể nhìn vào cửa sổ thời gian được sử dụng cho các ưu đãi, nếu cửa sổ là 1 giờ thì một số người mua sớm sẽ là con người. Một con người sẽ hiếm khi làm mới trong 4 giờ mặc dù. Nếu thời gian trôi qua khá nhất quán giữa xuất bản / mua bất kể thời lượng của cửa sổ thì đó là bot. Nếu thời gian xuất bản / mua là ngắn đối với các cửa sổ nhỏ và dài hơn đối với các cửa sổ lớn, thì đó là một ẩn số!

Bây giờ thay vì ngăn chặn bot sử dụng trang web của bạn, bạn có đủ thông tin để cho bạn biết tài khoản nào chắc chắn được sử dụng bởi bot và tài khoản nào có khả năng được sử dụng bởi các ẩn sĩ. Những gì bạn làm với thông tin đó là tùy thuộc vào bạn, nhưng bạn chắc chắn có thể sử dụng nó để làm cho trang web của bạn công bằng hơn với những người có cuộc sống.

Tôi nghĩ rằng việc cấm các tài khoản bot sẽ là vô nghĩa, nó sẽ giống như gọi điện cho Hitler và nói "Cảm ơn vì vị trí của những chiếc thuyền U của bạn!" Bằng cách nào đó bạn cần sử dụng thông tin theo cách mà chủ tài khoản không nhận ra. Hãy xem liệu tôi có thể mơ ước gì không .....

Xử lý các đơn đặt hàng trong một hàng đợi:

Khi khách hàng đặt hàng, họ ngay lập tức nhận được email xác nhận cho biết đơn hàng của họ được đặt trong hàng đợi và sẽ được thông báo khi đơn hàng được xử lý. Tôi trải nghiệm loại điều này với đơn đặt hàng / công văn trên Amazon và nó hoàn toàn không làm phiền tôi, tôi không phiền khi nhận được email sau đó cho tôi biết đơn hàng của tôi đã được gửi đi miễn là tôi nhận được email ngay lập tức Amazon biết tôi muốn cuốn sách. Trong trường hợp của bạn, nó sẽ là một email cho

1. Đơn hàng của bạn đã được đặt và đang xếp hàng.
2. Đơn hàng của bạn đã được xử lý.
3. Đơn đặt hàng của bạn đã được gửi đi.

Người dùng nghĩ rằng họ đang ở trong một hàng đợi công bằng. Xử lý hàng đợi của bạn cứ sau 1 giờ để người dùng bình thường cũng trải nghiệm một hàng đợi, để không khơi dậy sự nghi ngờ. Chỉ xử lý các đơn đặt hàng từ tài khoản bot và ẩn sĩ khi chúng đã được xếp hàng cho "thời gian đặt hàng trung bình của con người + x giờ". Hiệu quả giảm bot cho con người.

Tôi nói phơi bày thông tin về giá bằng API. Đây là giải pháp không trực quan nhưng nó hoạt động để giúp bạn kiểm soát tình hình. Thêm một số hạn chế cho API để làm cho nó ít chức năng hơn so với trang web.

Bạn có thể làm tương tự để đặt hàng. Bạn có thể thử nghiệm các thay đổi nhỏ đối với chức năng / hiệu suất API cho đến khi bạn có được hiệu quả mong muốn.

Có proxy và botnet để đánh bại kiểm tra IP. Có những kịch bản đọc captcha cực kỳ tốt. Thậm chí có những đội công nhân ở Ấn Độ đã đánh bại captcha với một mức giá nhỏ. Bất kỳ giải pháp nào bạn có thể đưa ra đều có thể bị đánh bại một cách hợp lý. Ngay cả các giải pháp của Ned Batchelder cũng có thể được thực hiện bằng cách sử dụng điều khiển WebBrowser hoặc trình duyệt mô phỏng khác kết hợp với danh sách botnet hoặc proxy.

Chúng tôi hiện đang sử dụng thế hệ cân bằng tải BigIP mới nhất từ ​​F5 để làm điều này. BigIP có các tính năng quản lý lưu lượng tiên tiến có thể xác định người dọn dẹp và bot dựa trên tần suất và mô hình sử dụng ngay cả trong số các nguồn phía sau một IP. Sau đó, nó có thể điều tiết chúng, cung cấp cho chúng nội dung thay thế hoặc chỉ cần gắn thẻ chúng với các tiêu đề hoặc cookie để bạn có thể xác định chúng trong mã ứng dụng của mình.

Đầu tiên, hãy để tôi tóm tắt lại những gì chúng ta cần làm ở đây. Tôi nhận ra tôi chỉ đang diễn giải câu hỏi ban đầu, nhưng điều quan trọng là chúng tôi giải quyết được 100% ngay lập tức, bởi vì có rất nhiều gợi ý tuyệt vời có được 2 hoặc 3 trên 4, nhưng như tôi sẽ chứng minh, bạn sẽ cần một cách tiếp cận nhiều mặt để đáp ứng tất cả các yêu cầu.

Yêu cầu 1: Loại bỏ 'bot slamming':

Việc 'đóng sầm' nhanh chóng trên trang nhất của bạn đang làm tổn hại đến hiệu suất trang web của bạn và là cốt lõi của vấn đề. 'Slamming' đến từ cả hai bot đơn IP và - được cho là - từ các botnet. Chúng tôi muốn thoát khỏi cả hai.

Yêu cầu 2: Đừng lộn xộn với trải nghiệm người dùng:

Chúng tôi có thể khắc phục tình trạng bot khá hiệu quả bằng cách thực hiện một quy trình xác minh khó chịu như gọi điện cho người điều khiển con người, giải quyết một loạt CAPTCHA hoặc tương tự, nhưng điều đó sẽ giống như buộc mọi hành khách máy bay vô tội phải nhảy qua các vòng an ninh điên rồ chỉ vì cơ hội mỏng manh bắt những kẻ ngu ngốc nhất của những kẻ khủng bố. Oh chờ đợi - chúng tôi thực sự làm điều đó. Nhưng hãy xem nếu chúng ta không thể làm điều đó trên woot.com.

Yêu cầu 3: Tránh 'chạy đua vũ trang':

Như bạn đã đề cập, bạn không muốn bị cuốn vào cuộc đua vũ trang. Vì vậy, bạn không thể sử dụng các chỉnh sửa đơn giản như các trường mẫu ẩn hoặc lộn xộn, các câu hỏi toán học, v.v., vì về cơ bản chúng là các biện pháp che khuất có thể được tự động hóa và phá vỡ một cách tầm thường.

Yêu cầu 4: Ngăn chặn các bot 'báo động':

Đây có thể là khó khăn nhất trong các yêu cầu của bạn. Ngay cả khi chúng tôi có thể thực hiện một thử thách xác minh con người hiệu quả, các bot vẫn có thể thăm dò trang trước của bạn và thông báo cho người viết kịch bản khi có đề nghị mới. Chúng tôi muốn làm cho những bot không khả thi là tốt. Đây là phiên bản mạnh hơn của yêu cầu đầu tiên, vì không chỉ các bot không thể đưa ra các yêu cầu bắn nhanh gây thiệt hại về hiệu suất - thậm chí chúng còn không thể đưa ra đủ các yêu cầu lặp đi lặp lại để gửi 'báo động' cho người viết kịch bản kịp thời để giành chiến thắng lời đề nghị.

Được rồi, vì vậy hãy se nếu chúng tôi có thể đáp ứng tất cả bốn yêu cầu. Đầu tiên, như tôi đã đề cập, không ai có thể đo lường được. Bạn sẽ phải kết hợp một vài thủ thuật để đạt được nó, và bạn sẽ phải nuốt hai điều khó chịu:

1. Một số lượng nhỏ người dùng sẽ được yêu cầu nhảy qua vòng
2. Một số ít người dùng sẽ không thể nhận được ưu đãi đặc biệt

Tôi nhận ra những điều này thật khó chịu, nhưng nếu chúng ta có thể làm cho số 'nhỏ' đủ nhỏ , tôi hy vọng bạn sẽ đồng ý những mặt tích cực vượt xa những tiêu cực.

Biện pháp đầu tiên: Điều chỉnh dựa trên người dùng:

Đây là một người không có trí tuệ, và tôi chắc chắn bạn đã làm điều đó rồi. Nếu người dùng đã đăng nhập và tiếp tục làm mới 600 lần một giây (hoặc một cái gì đó), bạn ngừng phản hồi và bảo anh ta làm mát nó. Trong thực tế, bạn có thể điều tiết các yêu cầu của anh ấy sớm hơn đáng kể, nhưng bạn có ý tưởng. Bằng cách này, một bot đăng nhập sẽ bị cấm / điều chỉnh ngay khi nó bắt đầu thăm dò trang web của bạn. Đây là phần dễ dàng. Các bot không được xác thực là vấn đề thực sự của chúng tôi, vì vậy với họ:

Biện pháp thứ hai: Một số hình thức điều chỉnh IP, theo đề xuất của gần như mọi người:

Không có vấn đề gì, bạn sẽ phải thực hiện một số điều chỉnh dựa trên IP để cản trở 'bot slamming'. Vì nó quan trọng dường như bạn cho phép không được thẩm định khách (không đăng nhập) để có được những khuyến mại đặc biệt, bạn chỉ có IP để đi bởi ban đầu, và mặc dù chúng không phải là hoàn hảo, họ làm việc với chương trình đơn IP. Botnet là một con thú khác, nhưng tôi sẽ quay lại với chúng. Hiện tại, chúng tôi sẽ thực hiện một số điều chỉnh đơn giản để đánh bại các bot đơn IP nhanh chóng.

Lượt truy cập hiệu năng là không đáng kể nếu bạn chạy kiểm tra IP trước tất cả các xử lý khác, sử dụng máy chủ proxy cho logic điều tiết và lưu trữ IP trong cấu trúc cây được tối ưu hóa tra cứu memcached.

Biện pháp thứ ba: Che giấu van tiết lưu bằng các phản hồi được lưu trong bộ nhớ cache:

Với các bot đơn IP được bắn nhanh, chúng ta vẫn phải xử lý các bot đơn IP chậm, tức là. các bot được tinh chỉnh đặc biệt để 'bay dưới radar' bằng cách đặt các yêu cầu cách xa nhau một chút so với các điều chỉnh tiết lưu.

Để ngay lập tức khiến các bot đơn IP chậm trở nên vô dụng, chỉ cần sử dụng chiến lược được đề xuất bởi abelenky: phục vụ các trang được lưu trong bộ nhớ cache 10 phút cho tất cả các IP đã được phát hiện trong 24 giờ qua (hoặc hơn). Bằng cách đó, mọi IP đều nhận được một 'cơ hội' mỗi ngày / giờ / tuần (tùy thuộc vào khoảng thời gian bạn chọn) và sẽ không có sự khó chịu rõ ràng nào đối với người dùng thực sự chỉ nhấn 'tải lại', ngoại trừ việc họ không thắng lời đề nghị.

Cái hay của biện pháp này là cũng là các 'bot báo động', miễn là chúng không bắt nguồn từ botnet.

(Tôi biết bạn có thể sẽ thích nó hơn nếu người dùng thực sự được phép làm mới nhiều lần, nhưng không có cách nào để nói với một người làm mới spam từ một bot yêu cầu spam mà không có CAPTCHA hoặc tương tự)

Biện pháp thứ tư: reCAPTCHA:

Bạn đã đúng khi CAPTCHA làm tổn thương trải nghiệm người dùng và nên tránh. Tuy nhiên, trong tình huống _one_, họ có thể là người bạn tốt nhất của bạn: Nếu bạn đã thiết kế một hệ thống rất hạn chế để ngăn chặn các bot, điều đó - vì tính hạn chế của nó - cũng bắt được một số điểm tích cực sai; sau đó, CAPTCHA phục vụ như là phương sách cuối cùng sẽ cho phép những người dùng thực sự bị bắt gặp trượt qua điều chỉnh của bạn (do đó tránh được các tình huống DoS gây phiền nhiễu).

Tất nhiên, điểm hấp dẫn là khi TẤT CẢ các bot bị mắc vào mạng của bạn, trong khi cực kỳ ít người dùng thực sự bị làm phiền bởi CAPTCHA.

Nếu bạn, khi phục vụ các trang được lưu trong bộ nhớ cache 10 phút, cũng cung cấp một thay thế, tùy chọn , được xác minh CAPTCHA, 'giới thiệu trang trước', thì những người thực sự muốn tiếp tục làm mới, vẫn có thể làm như vậy mà không cần lấy trang đã lưu trong bộ nhớ cache cũ , nhưng với chi phí phải giải CAPTCHA cho mỗi lần làm mới. Đó là một điều khó chịu, nhưng là một lựa chọn chỉ dành cho những người dùng khó tính, những người có xu hướng tha thứ nhiều hơn vì họ biết họ đang chơi game hệ thống để cải thiện cơ hội của họ và cơ hội được cải thiện không miễn phí.

Biện pháp thứ năm: Decoy crap:

Christopher Mahan có một ý tưởng mà tôi khá thích, nhưng tôi sẽ đặt một vòng xoáy khác vào nó. Mỗi khi bạn đang chuẩn bị một đề nghị mới, hãy chuẩn bị hai 'ưu đãi' khác, mà không ai có thể chọn, như một hạt dẻ 12 mm với giá 20 đô la. Khi phiếu mua hàng xuất hiện trên trang nhất, hãy đặt cả ba 'ưu đãi' trong cùng một bức tranh, với các số tương ứng với mỗi ưu đãi. Khi người dùng / bot thực sự tiếp tục đặt hàng, họ sẽ phải chọn (một nút radio) mà họ muốn, và vì hầu hết các bot sẽ chỉ đoán, trong hai trong ba trường hợp, các bot sẽ mua vô giá trị rác.

Đương nhiên, điều này không giải quyết được 'bot báo động' và có khả năng ai đó có thể xây dựng một bot có thể chọn đúng vật phẩm. Tuy nhiên, nguy cơ vô tình mua rác sẽ khiến các nhà viết kịch bản chuyển hoàn toàn từ các bot hoàn toàn tự động.

Biện pháp thứ sáu: Điều khiển Botnet:

[đã xóa]

Được rồi ............ Bây giờ tôi đã dành phần lớn thời gian buổi tối để suy nghĩ về điều này, thử các cách tiếp cận khác nhau .... sự chậm trễ toàn cầu .... mã thông báo dựa trên cookie .. phục vụ xếp hàng ... 'người lạ điều tiết' .... Và nó không hoạt động. Nó không. Tôi nhận ra lý do chính tại sao bạn chưa chấp nhận bất kỳ câu trả lời nào là vì không ai đã đề xuất một cách để ngăn chặn một cuộc tấn công net / botnet phân tán / zombie .... vì vậy tôi thực sự muốn phá vỡ nó. Tôi tin rằng tôi đã bẻ khóa sự cố botnet để xác thực trong một luồng khác , vì vậy tôi cũng có hy vọng cao cho vấn đề của bạn. Nhưng cách tiếp cận của tôi không chuyển sang điều này. Bạn chỉ có IP để đi qua và một mạng botnet đủ lớn sẽ không tự tiết lộ trong bất kỳ phân tích nào dựa trên địa chỉ IP.

Vì vậy, bạn có nó : biện pháp thứ sáu của tôi là vô ích. Không có gì. Zip. Trừ khi botnet nhỏ và / hoặc đủ nhanh để bị kẹt trong bộ điều tiết IP thông thường, tôi không thấy bất kỳ biện pháp hiệu quả nào đối với các botnet không liên quan đến xác minh rõ ràng của con người như CAPTHAs. Tôi xin lỗi, nhưng tôi nghĩ rằng kết hợp năm biện pháp trên là đặt cược tốt nhất của bạn. Và bạn có thể làm tốt chỉ với thủ thuật lưu trữ 10 phút của abelenky một mình.

Làm thế nào về việc giới thiệu một sự chậm trễ đòi hỏi sự tương tác của con người, như một loại "trò chơi CAPTCHA". Ví dụ, đó có thể là một trò chơi Flash nhỏ trong 30 giây họ phải nổ những quả bóng rô và tránh vỡ những quả bóng rắn (tránh các vấn đề mù màu!). Trò chơi sẽ được cung cấp một số hạt ngẫu nhiên và những gì trò chơi truyền trở lại máy chủ sẽ là tọa độ và dấu thời gian của các điểm được nhấp, cùng với hạt giống được sử dụng.

Trên máy chủ, bạn mô phỏng cơ chế trò chơi bằng cách sử dụng hạt giống đó để xem liệu các nhấp chuột có thực sự làm vỡ các quả bóng hay không. Nếu họ làm như vậy, họ không chỉ là con người mà còn mất 30 giây để xác thực chính họ. Cung cấp cho họ một id phiên.

Bạn để id phiên đó làm những gì nó thích, nhưng nếu thực hiện quá nhiều yêu cầu, chúng không thể tiếp tục mà không phát lại.

Có một vài giải pháp khác / tốt hơn đã được đăng, nhưng để hoàn thiện, tôi đoán rằng tôi đã đề cập đến điều này:

Nếu mối quan tâm chính của bạn là sự suy giảm hiệu suất và bạn đang nhìn vào búa thực sự , thì thực tế bạn đang đối phó với một cuộc tấn công DoS, và có lẽ bạn nên cố gắng xử lý nó cho phù hợp. Một cách tiếp cận phổ biến là chỉ cần thả các gói từ một IP trong tường lửa sau một số kết nối mỗi giây / phút / v.v. Ví dụ: tường lửa Linux tiêu chuẩn, iptables, có chức năng khớp hoạt động tiêu chuẩn 'hashlimit', có thể được sử dụng để tương quan các yêu cầu kết nối trên mỗi đơn vị thời gian với địa chỉ IP.

Mặc dù, câu hỏi này có lẽ sẽ phù hợp hơn với dẫn xuất SO tiếp theo được đề cập trên podcast SO cuối cùng, nó chưa được đưa ra, vì vậy tôi đoán rằng nó ổn để trả lời :)

EDIT:
Như được chỉ ra bởi novatrust, vẫn có các ISP thực sự KHÔNG gán IP cho khách hàng của họ, vì vậy, một khách hàng kịch bản của một ISP như vậy sẽ vô hiệu hóa tất cả các khách hàng khỏi ISP đó.

Viết proxy ngược trên máy chủ apache trước ứng dụng của bạn để thực hiện Tarpit (Bài viết Wikipedia) để trừng phạt các bot. Nó chỉ đơn giản là quản lý một danh sách các địa chỉ IP được kết nối trong vài giây qua. Bạn phát hiện một loạt các yêu cầu từ một địa chỉ IP duy nhất và sau đó trì hoãn theo cấp số nhân các yêu cầu đó trước khi trả lời.

Tất nhiên, nhiều người có thể đến từ cùng một địa chỉ IP nếu họ đang kết nối mạng NAT nhưng không chắc là con người sẽ bận tâm đến thời gian phản hồi của bạn từ 2mS đến 4mS (hoặc thậm chí 400mS) trong khi bot sẽ bị cản trở bởi sự chậm trễ tăng khá nhanh.

1. Cung cấp nguồn cấp dữ liệu RSS để họ không ăn hết băng thông của bạn.
2. Khi mua, hãy khiến mọi người chờ đợi một khoảng thời gian ngẫu nhiên lên tới 45 giây hoặc một cái gì đó, tùy thuộc vào chính xác những gì bạn đang tìm kiếm. Chính xác những hạn chế thời gian của bạn là gì?
3. Cho mọi người 1 phút để ghi tên của họ vào bản vẽ và sau đó chọn ngẫu nhiên mọi người. Tôi nghĩ rằng đây là cách công bằng nhất.
4. Giám sát các tài khoản (bao gồm một số lần trong phiên và lưu trữ nó?) Và thêm độ trễ vào các tài khoản có vẻ như dưới ngưỡng tốc độ của con người. Điều đó ít nhất sẽ làm cho các bot được lập trình để làm chậm và cạnh tranh với con người.

Trước hết, theo định nghĩa, không thể hỗ trợ các giao dịch không trạng thái, tức là thực sự ẩn danh, trong khi cũng có thể tách các bot khỏi người dùng hợp pháp.

Nếu chúng tôi có thể chấp nhận một tiền đề rằng chúng tôi có thể áp dụng một số chi phí cho khách truy cập woot hoàn toàn mới trên trang đầu tiên của anh ấy, tôi nghĩ rằng tôi có một giải pháp khả thi. Vì thiếu một cái tên hay hơn, tôi sẽ gọi một cách lỏng lẻo giải pháp này là "Chuyến thăm DMV."

Giả sử có một đại lý xe hơi cung cấp một chiếc xe mới khác nhau mỗi ngày và vào một số ngày, bạn có thể mua một chiếc xe thể thao kỳ lạ với giá 5 đô la mỗi chiếc (giới hạn 3), cộng với phí đích 5 đô la.

Điều thú vị là, đại lý yêu cầu bạn đến thăm đại lý và xuất trình giấy phép lái xe hợp lệ trước khi bạn được phép qua cửa để xem xe nào đang được bán. Hơn nữa, bạn phải nói bằng lái xe hợp lệ để mua hàng.

Vì vậy, người truy cập lần đầu (hãy gọi anh ta là Bob) đến đại lý xe hơi này bị từ chối nhập cảnh và được chuyển đến văn phòng DMV (nằm ở vị trí thuận tiện ngay bên cạnh) để lấy bằng lái xe.

Những khách truy cập khác có bằng lái xe hợp lệ được phép vào, sau khi xuất trình giấy phép lái xe của anh ta. Một người gây phiền toái cho bản thân bằng cách lảng vảng suốt ngày, làm phiền những người bán hàng, lấy tờ rơi và làm trống cà phê và bánh quy miễn phí cuối cùng sẽ bị từ chối.

Bây giờ, trở lại với Bob mà không có giấy phép - tất cả những gì anh phải làm là chịu đựng chuyến thăm DMV một lần. Sau đó, anh ta có thể ghé thăm đại lý và mua xe bất cứ lúc nào anh ta thích, trừ khi anh ta vô tình để quên ví ở nhà, hoặc giấy phép của anh ta bị phá hủy hoặc thu hồi.

Bằng lái xe trong thế giới này gần như không thể giả mạo.

Chuyến thăm DMV liên quan đến việc nhận mẫu đơn đầu tiên tại hàng đợi "Bắt đầu tại đây". Bob phải đưa ứng dụng đã hoàn thành vào cửa sổ số 1, nơi đầu tiên trong số nhiều công chức chắc chắn sẽ nhận đơn của anh ta, xử lý nó và nếu mọi thứ theo thứ tự, hãy đóng dấu ứng dụng cho cửa sổ và gửi anh ta đến cửa sổ tiếp theo. Và vì vậy, Bob đi từ cửa sổ này sang cửa sổ khác, chờ đợi từng bước trong ứng dụng của anh ta đi qua, cho đến khi cuối cùng anh ta đi đến cuối cùng và nhận được giấy phép lái xe.

Không có điểm nào trong việc cố gắng "đoản mạch" DMV. Nếu các biểu mẫu không được điền chính xác ba lần hoặc bất kỳ câu trả lời sai nào được đưa ra tại bất kỳ cửa sổ nào, ứng dụng sẽ bị xé ra và khách hàng không may mắn được gửi lại từ đầu.

Thật thú vị, bất kể văn phòng đầy đủ hay trống rỗng, sẽ mất khoảng thời gian như nhau để được phục vụ ở mỗi cửa sổ liên tiếp. Ngay cả khi bạn là người duy nhất xếp hàng, có vẻ như nhân viên thích khiến bạn đợi một phút sau vạch vàng trước khi thốt lên, "Tiếp theo!"

Tuy nhiên, mọi thứ không quá khủng khiếp ở DMV. Trong khi tất cả các chờ đợi và xử lý để có được giấy phép đang diễn ra, bạn có thể xem một quảng cáo thông tin rất thú vị và thông tin cho các đại lý xe hơi trong khi bạn đang ở trong sảnh DMV. Trên thực tế, hệ thống vô cực chỉ chạy đủ lâu để trang trải lượng thời gian bạn dành để nhận giấy phép.

Giải thích kỹ thuật hơn một chút:

Như tôi đã nói ở trên cùng, cần phải có một số trạng thái về mối quan hệ máy khách-máy chủ cho phép bạn tách con người khỏi bot. Bạn muốn làm điều đó theo cách không phạt quá nhiều khách truy cập ẩn danh (không xác thực).

Cách tiếp cận này có thể yêu cầu xử lý phía máy khách AJAX-y. Một khách truy cập hoàn toàn mới đến woot được tặng "Chào mừng người dùng mới!" trang đầy đủ văn bản và đồ họa mà (bằng cách điều chỉnh phía máy chủ phù hợp) sẽ mất vài giây để tải hoàn toàn. Trong khi điều này đang xảy ra (và khách truy cập có lẽ đang bận đọc (các) trang chào mừng), mã thông báo nhận dạng của anh ta đang dần được lắp ráp.

Giả sử, để thảo luận, mã thông báo (còn gọi là "bằng lái xe) bao gồm 20 khối. Để có được mỗi đoạn liên tiếp, mã phía máy khách phải gửi yêu cầu hợp lệ đến máy chủ. Máy chủ kết hợp độ trễ có chủ ý (giả sử 200 mili giây), trước khi gửi đoạn tiếp theo cùng với 'tem' cần thiết để thực hiện yêu cầu khối tiếp theo (nghĩa là tem cần đi từ một cửa sổ DMV sang cửa sổ tiếp theo). Tất cả đã nói, khoảng 4 giây phải trôi qua để hoàn thành chunk-thử thách-đáp ứng-chunk-thử thách-phản hồi -...- quá trình hoàn thành thách thức-phản ứng-chunk-thử thách-hoàn thành.

Khi kết thúc quá trình này, khách truy cập có mã thông báo cho phép anh ta đi đến trang mô tả sản phẩm và đến lượt mình, đi đến trang mua hàng. Mã thông báo là một ID duy nhất cho mỗi khách truy cập và có thể được sử dụng để điều tiết các hoạt động của anh ấy.

Về phía máy chủ, bạn chỉ chấp nhận lượt xem trang từ các máy khách có mã thông báo hợp lệ. Hoặc, nếu điều quan trọng là cuối cùng mọi người đều có thể xem trang, hãy đặt hình phạt thời gian cho các yêu cầu thiếu mã thông báo hợp lệ.

Bây giờ, để điều này tương đối lành tính với khách truy cập hợp pháp của con người, làm cho quá trình phát hành mã thông báo xảy ra tương đối không xâm phạm trong nền. Do đó, nhu cầu về trang chào mừng với bản sao và đồ họa giải trí được cố tình làm chậm lại một chút.

Cách tiếp cận này buộc các bot giảm tốc sử dụng mã thông báo hiện có hoặc mất thời gian thiết lập tối thiểu để nhận mã thông báo mới. Tất nhiên, điều này không giúp ích nhiều cho các cuộc tấn công tinh vi bằng cách sử dụng một mạng lưới khách truy cập giả.

Bạn hoàn toàn không thể ngăn chặn bot, ngay cả với hình ảnh xác thực. Tuy nhiên, bạn có thể làm cho nó khó khăn để viết và duy trì một bot và do đó giảm số lượng. Đặc biệt bằng cách buộc họ cập nhật bot hàng ngày, bạn sẽ khiến hầu hết mất hứng thú.

Dưới đây là một số ý tưởng để làm cho việc viết bot khó hơn:

• Yêu cầu chạy một chức năng javascript. Javascript làm cho việc viết bot trở nên khó khăn hơn nhiều. Có thể yêu cầu captcha nếu họ không chạy javascript để vẫn cho phép người dùng không phải là javascript thực tế (tối thiểu).

• Thời gian nhấn phím khi gõ vào biểu mẫu (một lần nữa qua javascript). Nếu nó không giống con người thì hãy từ chối nó. Thật đau đớn khi bắt chước cách gõ của con người trong bot.

• Viết mã của bạn để cập nhật ID trường hàng ngày với giá trị ngẫu nhiên mới. Điều này sẽ buộc họ phải cập nhật bot hàng ngày, đó là một nỗi đau.

• Viết mã của bạn để sắp xếp lại các lĩnh vực của bạn trên cơ sở hàng ngày (rõ ràng theo một cách nào đó không phải là ngẫu nhiên cho người dùng của bạn). Nếu họ đang dựa vào thứ tự hiện trường, điều này sẽ khiến họ tăng tốc và một lần nữa buộc bảo trì hàng ngày đối với mã bot của họ.

• Bạn có thể đi xa hơn và sử dụng nội dung Flash. Flash hoàn toàn là một nỗi đau để viết một bot chống lại.

Nói chung nếu bạn bắt đầu có suy nghĩ không ngăn cản họ, nhưng làm cho nó hiệu quả hơn với họ, bạn có thể có thể đạt được mục tiêu mà bạn đang tìm kiếm.

Chậm trễ 5 phút trên tất cả các thông báo sản phẩm cho người dùng chưa đăng ký. Người dùng thông thường sẽ không thực sự nhận thấy điều này và người dùng không thường xuyên sẽ được đăng ký bằng mọi cách.

Tôi không thấy gánh nặng lớn mà bạn yêu cầu khi kiểm tra IP đến. Ngược lại, tôi đã thực hiện một dự án cho một trong những khách hàng của mình để phân tích nhật ký truy cập HTTP cứ sau năm phút (có thể là thời gian thực, nhưng anh ta không muốn điều đó vì một số lý do mà tôi chưa bao giờ hiểu đầy đủ) và tạo quy tắc tường lửa để chặn kết nối từ bất kỳ địa chỉ IP nào tạo ra số lượng yêu cầu quá lớn trừ khi địa chỉ có thể được xác nhận là thuộc về một công cụ tìm kiếm hợp pháp (google, yahoo, v.v.).

Khách hàng này chạy một dịch vụ lưu trữ web và đang chạy ứng dụng này trên ba máy chủ xử lý tổng cộng 800-900 tên miền. Hoạt động cao điểm nằm trong phạm vi hàng nghìn lượt truy cập mỗi giây và chưa bao giờ có vấn đề về hiệu suất - tường lửa rất hiệu quả trong việc thả các gói từ các địa chỉ trong danh sách đen.

Và, vâng, công nghệ DDOS chắc chắn tồn tại sẽ đánh bại kế hoạch này, nhưng anh ta không thấy điều đó xảy ra trong thế giới thực. Ngược lại, anh ta nói rằng nó đã giảm tải rất nhiều cho các máy chủ của anh ta.

Cách tiếp cận của tôi sẽ là tập trung vào các giải pháp phi công nghệ (nếu không, bạn sẽ tham gia một cuộc chạy đua vũ trang, hoặc ít nhất là bạn sẽ dành rất nhiều thời gian và tiền bạc). Tôi tập trung vào các bộ phận thanh toán / giao hàng - bạn có thể tìm thấy bot bằng cách tìm nhiều lần giao hàng đến cùng một địa chỉ hoặc bằng nhiều khoản phí cho một phương thức thanh toán. Bạn thậm chí có thể thực hiện việc này trên các mục trong vài tuần, vì vậy nếu người dùng có một mục trước đó (bằng cách phản hồi thực sự rất nhanh), anh ta có thể được chỉ định một số "điểm chấp" trong khoảng thời gian này.

Điều này cũng sẽ có tác dụng phụ (có lợi, tôi nghĩ vậy, nhưng tôi có thể sai tiếp thị khôn ngoan cho trường hợp của bạn) có lẽ mở rộng vòng tròn của những người gặp may mắn và mua woot.

Hầu hết các giải pháp kỹ thuật thuần túy đã được cung cấp. Do đó tôi sẽ đề xuất một cái nhìn khác về vấn đề.

Theo tôi hiểu, các bot được thiết lập bởi những người thực sự đang cố gắng mua những chiếc túi bạn đang bán. Vấn đề là -

1. Những người khác, những người không vận hành bot, xứng đáng có cơ hội mua và bạn đang cung cấp một số lượng túi hạn chế.
2. Bạn muốn thu hút con người vào trang web của bạn và chỉ bán những chiếc túi.

Thay vì cố gắng tránh các bot, bạn có thể cho phép những người mua túi tiềm năng đăng ký email, hoặc thậm chí cập nhật SMS, để được thông báo khi việc bán hàng sẽ diễn ra. Bạn thậm chí có thể cung cấp cho họ một hoặc hai phút bắt đầu (một URL đặc biệt nơi bán bắt đầu, được tạo ngẫu nhiên và được gửi cùng với thư / SMS).

Khi những người mua này đến mua họ trong trang web của bạn, bạn có thể hiển thị cho họ bất cứ điều gì bạn muốn trong các biểu ngữ bên cạnh hoặc bất cứ điều gì. Những người chạy bot sẽ thích đăng ký dịch vụ thông báo của bạn.

Người chạy bot vẫn có thể chạy bot theo thông báo của bạn để hoàn tất giao dịch mua nhanh hơn. Một số giải pháp cho điều đó có thể là mua bằng một cú nhấp chuột.

Nhân tiện, bạn đã đề cập đến người dùng của bạn chưa được đăng ký, nhưng có vẻ như những người mua những chiếc túi này không phải là người mua ngẫu nhiên, mà là những người mong chờ những doanh số này. Do đó, họ có thể sẵn sàng đăng ký để có lợi thế trong việc cố gắng "giành" một chiếc túi.

Về bản chất những gì tôi đề nghị là thử và xem xét vấn đề như một vấn đề xã hội, chứ không phải là vấn đề kỹ thuật.

Asaf

Tác nhân người dùng chặn thời gian thực hiện rất nhiều yêu cầu mỗi phút. Ví dụ: nếu bạn có ai đó yêu cầu một trang chính xác cứ sau 5 giây trong 10 phút, họ có thể không phải là người dùng ... Nhưng thật khó để làm điều này đúng.

Nếu họ kích hoạt cảnh báo, hãy chuyển hướng mọi yêu cầu đến một trang tĩnh với càng ít DB-IO càng tốt với một thông báo cho họ biết rằng họ sẽ được phép quay lại sau X phút.

Điều quan trọng là thêm rằng bạn có lẽ chỉ nên áp dụng điều này cho các yêu cầu cho các trang và bỏ qua tất cả các yêu cầu cho phương tiện (js, hình ảnh, v.v.).

Ngăn chặn DoS sẽ đánh bại mục tiêu số 2 của @ daveorms mà anh ta đã nêu ở trên, "Giữ cho trang web ở tốc độ không bị chậm bởi bot" nhưng sẽ không cần giải quyết # 1, "Bán vật phẩm cho người không có kịch bản"

Tôi chắc chắn rằng một người viết kịch bản có thể viết một cái gì đó để trượt băng dưới giới hạn quá mức vẫn sẽ nhanh hơn con người có thể thông qua các hình thức đặt hàng.

Được rồi, những kẻ gửi thư rác đang cạnh tranh những người thường xuyên để giành chiến thắng trong cuộc đấu giá "bog of crap"? Tại sao không làm cho phiên đấu giá tiếp theo là một "túi rác" theo nghĩa đen? Những kẻ gửi thư rác phải trả tiền tốt cho một túi đầy chó làm, và tất cả chúng ta đều cười nhạo họ.

Điều quan trọng ở đây là thay đổi hệ thống để loại bỏ tải khỏi máy chủ của bạn, ngăn bot không giành được túi rác mà KHÔNG cho các botl biết bạn đang chơi chúng hoặc chúng sẽ sửa đổi chiến lược của chúng. Tôi không nghĩ có bất kỳ cách nào để làm điều này mà không cần xử lý ở cuối.

Vì vậy, bạn ghi lại lượt truy cập trên trang chủ của bạn. Bất cứ khi nào ai đó truy cập vào trang mà kết nối được so sánh với lần truy cập cuối cùng của nó và nếu quá nhanh thì nó sẽ được gửi một phiên bản của trang mà không có lời đề nghị. Điều này có thể được thực hiện bằng một số loại cơ chế cân bằng tải gửi bot (các lần truy cập quá nhanh) đến một máy chủ chỉ phục vụ các phiên bản được lưu trong bộ nhớ cache của trang chủ của bạn; người thật được gửi đến máy chủ tốt. Điều này sẽ tải xuống máy chủ chính và khiến các bot nghĩ rằng chúng vẫn đang được phục vụ các trang một cách chính xác.

Thậm chí tốt hơn nếu lời đề nghị có thể bị từ chối theo một cách nào đó. Sau đó, bạn vẫn có thể thực hiện các ưu đãi trên máy chủ giả nhưng khi bot điền vào biểu mẫu "Xin lỗi, bạn không đủ nhanh" :) Sau đó, họ chắc chắn sẽ nghĩ rằng họ vẫn còn trong trò chơi.

Làm thế nào để bạn biết có những người viết kịch bản đặt hàng?

Mấu chốt của vấn đề của bạn là bạn không thể tách các tập lệnh ra khỏi những người dùng hợp pháp và do đó không thể chặn họ, vậy làm thế nào mà bạn biết có những người viết kịch bản?

Nếu bạn có cách trả lời câu hỏi này, thì bạn có một tập hợp các đặc điểm bạn có thể sử dụng để lọc các tập lệnh.

Hãy giải quyết vấn đề này - bạn có bot mua những thứ mà bạn muốn người thật mua, làm thế nào để tạo cơ hội thực sự rằng các bot sẽ mua những thứ mà bạn không muốn người thật mua.

Có một cơ hội ngẫu nhiên cho một số html không được hiển thị mà các bot cào sẽ nghĩ là tình huống thực, nhưng người thật sẽ không nhìn thấy (và đừng quên rằng người thật bao gồm cả người mù, vì vậy hãy xem xét cả trình đọc màn hình, v.v.) việc này đi qua để mua một cái gì đó đắt tiền (hoặc không thực hiện mua hàng thực sự, nhưng có được chi tiết thanh toán để bạn đưa vào danh sách cấm).

Ngay cả khi các bot chuyển sang 'cảnh báo người dùng' thay vì 'mua hàng', nếu bạn có thể nhận được đủ các báo động sai, bạn có thể làm cho nó đủ vô giá trị đối với mọi người (có thể không phải tất cả mọi người, nhưng giảm một phần lừa đảo là tốt hơn không có gì cả) không bận tâm.