Cách xử lý nhiều khối CAPTCHA trong các tác nhân trình duyệt AI

TL;DR

• Nhiều widget CAPTCHA trên cùng một trang yêu cầu một bản đồ giữa form mong muốn, phiên bản widget hiện tại và lần thử giải CAPTCHA.
• Một ID container DOM, ID widget nhà cung cấp và ID nhiệm vụ giải CAPTCHA xác định các thứ khác nhau và không nên thay thế cho nhau.
• Việc phát hiện loại CAPTCHA không xác định được form mà AI được phép gửi.
• Chỉ sử dụng giải CAPTCHA cho thử thách được chọn và hỗ trợ trong quy trình được phép; để nguyên các widget không liên quan.
• Kiểm tra lại mối liên hệ giữa form và widget sau khi có công việc bất đồng bộ, và xác minh kết quả ứng dụng mong muốn riêng biệt với việc giao token.

AI agent nên xử lý nhiều widget CAPTCHA như thế nào?

Một trình duyệt AI nên chọn form mong muốn trước, xác định widget CAPTCHA hiện tại của nó, và duy trì mối liên hệ này trong quá trình giải và kiểm tra ứng dụng.

Xét một cổng hỗ trợ do mình sở hữu với hai form trên cùng trang: một form yêu cầu hỗ trợ và một form phản hồi sản phẩm tùy chọn. Một đại diện QA được ủy quyền đang kiểm thử form yêu cầu hỗ trợ. Hoàn thành CAPTCHA phản hồi sẽ không đáp ứng nhiệm vụ, dù cả hai form đều sử dụng cùng nhà cung cấp và trông giống nhau.

Một giải CAPTCHA như CapSolver nên được sử dụng sau khi agent xác định được thử thách được hỗ trợ mà form mong muốn yêu cầu. Giải CAPTCHA cung cấp câu trả lời cho nhiệm vụ CAPTCHA được chọn; tích hợp ứng dụng chịu trách nhiệm định tuyến câu trả lời đúng cách.

Đây là hướng dẫn thiết kế quy trình và kiểm thử cho các trang mà nhóm của bạn sở hữu hoặc được ủy quyền kiểm thử. Nó mô tả các bản ghi, ranh giới giai đoạn và các kiểm tra cần thiết cho nhiều widget. Nó không tuyên bố cung cấp một SDK tích hợp đã kiểm thử cho các trang bất kỳ.

Những gì cần có trước khi xây dựng quy trình?

Một quy trình đáng tin cậy cần có phạm vi nhiệm vụ rõ ràng, bản đồ form-widget do mình sở hữu, và cách kiểm tra kết quả xác minh của ứng dụng.

Bắt đầu với một trang kiểm thử chứa các biến thể bố cục thực tế mà ứng dụng của bạn hỗ trợ. Ghi lại form mong muốn và thao tác được phép. Trình duyệt AI không nên suy luận rằng mọi nút gửi hiển thị đều thuộc nhiệm vụ của nó.

Chủ trang nên công khai các định danh form ổn định và giữ lại các trình giữ widget được tạo bởi tích hợp công khai của nhà cung cấp. Đối với reCAPTCHA, các trình giữ này là một phần của chu kỳ phía client. Chúng khác biệt với vai trò chung của dịch vụ trong việc kiểm tra tương tác tự động.

Bạn cũng cần một nhiệm vụ giải CAPTCHA được hỗ trợ, thông tin xác thực được lưu trữ bên ngoài nội dung trang, chính sách chờ có giới hạn, và một kết quả phía backend mà hệ thống kiểm thử QA có thể quan sát. Nếu ứng dụng của bạn sử dụng định dạng CAPTCHA mà đường giải được chọn không hỗ trợ, hãy dừng ở ranh giới đó thay vì đoán nhiệm vụ thay thế.

Ưu tiên cơ sở kiểm thử do chủ trang kiểm soát cho logic form thông thường. Ở nơi kiểm thử được phép đánh giá cụ thể một đường giải thực tế, hãy ghi chú riêng cho kiểm thử đó để kết quả CAPTCHA mô phỏng không bị nhầm lẫn với xác minh dịch vụ toàn bộ.

Giai đoạn 1: Ánh xạ form mong muốn với widget hiện tại

Giai đoạn đầu tiên biến hành động được yêu cầu của agent thành một mối liên hệ rõ ràng giữa form và widget.

Đầu vào là thao tác được phép, ví dụ như gửi một yêu cầu hỗ trợ tổng hợp trên cổng thử nghiệm. Thao tác xác định form hỗ trợ thông qua định danh ổn định của ứng dụng và lấy tham chiếu widget được duy trì bởi thành phần đó. Đầu ra là tham chiếu form cộng với phiên bản widget hiện tại, không chỉ đơn giản là "một CAPTCHA tồn tại".

Hướng dẫn hiển thị reCAPTCHA v2 của Google cho thấy việc hiển thị rõ ràng và nhiều widget. Việc hiển thị trả về ID widget; các phương thức như getResponse và reset chấp nhận ID widget, và bỏ qua nó sẽ sử dụng widget đầu tiên theo mặc định. Mặc định này có thể sai cho trang mà thao tác được mong muốn thuộc về form khác.

Hướng dẫn hiển thị client-side của Cloudflare cũng mô tả việc hiển thị widget rõ ràng và quản lý chu kỳ. Sử dụng API của nhà cung cấp phù hợp và trình giữ được giữ lại thay vì chuyển giao giả định phương pháp giữa các nhà cung cấp.

Nếu hơn một widget ánh xạ đến form, hoặc bản ánh xạ bị thiếu, giai đoạn này nên thất bại với thông báo chẩn đoán có thể hành động. Thứ tự DOM không phải là bằng chứng đủ để xác định quyền sở hữu. Lưu lại tham chiếu form, phiên bản trang và kết quả ánh xạ để kiểm tra; không lưu giá trị token trong bản ghi chẩn đoán.

Giai đoạn 2: Giữ các định danh khác nhau riêng biệt

Giai đoạn thứ hai gán mỗi định danh một ý nghĩa duy nhất để công việc bất đồng bộ không thể nhầm lẫn một thành phần trang với một nhiệm vụ giải CAPTCHA từ xa.

Định danh	Điều gì nó đại diện	Điều gì nó không nên thay thế
Tham chiếu form	Thao tác ứng dụng do mình sở hữu	ID nhiệm vụ nhà cung cấp
ID container DOM	Thành phần trang chứa widget	Trình giữ widget của nhà cung cấp
ID widget nhà cung cấp	Một phiên bản widget được hiển thị	Mã trang CAPTCHA
Mã trang	Cấu hình tích hợp nhà cung cấp	Danh tính duy nhất của lần thử form
ID nhiệm vụ giải	Một yêu cầu giải từ xa, khi được trả về	Thành phần trình duyệt hoặc tham chiếu form
Tham chiếu lần thực thi ứng dụng	Một lần thực thi thao tác mong muốn	Mọi lần thử lại sau trên cùng trang

Các nhãn này tạo thành một bản ghi ứng dụng đề xuất, không phải là lược đồ phản hồi nhà cung cấp. Giữ nguyên giá trị và kiểu của mỗi trình giữ thay vì chuẩn hóa mọi định danh thành chuỗi thay thế.

Hai widget có thể chia sẻ cấu hình nhưng vẫn thuộc về các form khác nhau. Do đó, chọn dựa trên mã trang duy nhất là không đủ khi trang do mình sở hữu cố ý tái sử dụng cấu hình đó. Ứng dụng cần mối liên hệ form mà nó đã thiết lập ở giai đoạn trước.

Gắn một phiên bản trang hoặc thành phần với bản ghi. Một hộp thoại có thể đóng và mở lại với phiên bản widget mới trong khi giữ nguyên tiêu đề hiển thị. Phiên bản cho phép các giai đoạn sau phát hiện rằng form trông quen thuộc không còn là phiên bản bắt đầu thử giải.

Giai đoạn 3: Chọn thông tin giải CAPTCHA cho widget đó

Giai đoạn thứ ba chuyển đổi mối liên hệ widget được chọn thành thông tin giải CAPTCHA được hỗ trợ trong khi duy trì kết nối với form mong muốn.

Tham khảo SDK Core của CapSolver phân biệt một số thao tác: detect(page) trả về loại CAPTCHA, get_captcha_info(page) trả về bản ghi thông tin CAPTCHA, và solve(info) trả về giải pháp. Phạm vi chế độ token được tài liệu bao gồm reCAPTCHA v2, reCAPTCHA v3 và Turnstile; không bao gồm việc nhấp vào lưới hình ảnh hoặc kéo thanh trượt.

Tham khảo cũng mô tả dữ liệu meta điền tự động như container_id, callback và binded_button_id. Xem xét những điều này như bằng chứng để đối chiếu với bản ánh xạ form do mình sở hữu. Một loại được phát hiện duy nhất không phải là số lượng phiên bản widget, và mục đầu tiên trong danh sách không phải là bằng chứng rằng nó thuộc nhiệm vụ của agent.

Kiểm tra thông tin có sẵn trên trang của bạn, bao gồm khung và hành vi hiển thị. Nếu bộ phát hiện không cung cấp đủ bằng chứng để chọn một widget mong muốn, dừng lại để sửa đổi tích hợp. Không mở rộng nhiệm vụ một cách im lặng đến tất cả các thử thách trên trang.

Đầu ra của giai đoạn này là một bản ghi thông tin được chọn cộng với bản ánh xạ ứng dụng giải thích lý do tại sao nó được chọn. Ranh giới thất bại là sự mơ hồ hoặc không hỗ trợ. Bằng chứng hữu ích bao gồm loại nhà cung cấp được chọn và quyết định ánh xạ, với bí mật và token giải pháp bị loại bỏ.

Nhận mã khuyến mãi CapSolver của bạn

Tăng ngân sách tự động hóa của bạn ngay lập tức!
Sử dụng mã khuyến mãi CAP26 khi nạp tiền vào tài khoản CapSolver để nhận thêm 5% khuyến mãi cho mỗi lần nạp tiền — không giới hạn.
Nhận mã ngay trong Bảng điều khiển CapSolver

Giai đoạn 4: Định tuyến kết quả về lần thực thi form ban đầu

Giai đoạn thứ tư chấp nhận kết quả giải CAPTCHA chỉ khi mối liên hệ form và widget được chọn vẫn còn hiệu lực.

Trước khi yêu cầu giải pháp, đánh dấu lần thử là đang chờ trên thông tin CAPTCHA được chọn. Khi công việc bất đồng bộ trả về, kiểm tra lại phiên bản trang và mối liên hệ widget. Nếu hộp thoại hỗ trợ đã đóng hoặc CAPTCHA của nó được làm mới, kết quả gốc không nên được gán lại cho form phản hồi.

CapSolver tài liệu solve_on_page như một quy trình cấp trang trả về kết quả bao gồm thông tin, giải pháp, trạng thái điền và lỗi. Các tùy chọn được liệt kê không bao gồm bộ chọn widget. Không mô tả phương pháp này là thao tác cấp form trừ khi tích hợp được xác minh của bạn thiết lập phạm vi cần thiết. Giai đoạn solve(info) thủ công trả về giải pháp; việc giao kết quả riêng lẻ không xác định rằng form đúng đã được điền.

Trong ứng dụng do mình sở hữu, định tuyến câu trả lời thông qua tích hợp thành phần đã sở hữu widget. Giữ bước ứng dụng cụ thể này tách biệt khỏi phát hiện nhà cung cấp. Biến "token mới nhất" toàn cục khiến việc giải thích form nào thuộc về kết quả trở nên khó khăn và có thể che giấu sai sót giữa các form.

Đầu ra của giai đoạn này là trạng thái: được giao cho thành phần hiện tại mong muốn, không còn cần thiết, hoặc bị từ chối vì mối liên hệ thay đổi. Ghi lại trạng thái nào xảy ra trước khi chuyển sang gửi. Lỗi giải CAPTCHA nên để nguyên widget phản hồi không liên quan.

Giai đoạn 5: Xác minh việc gửi mong muốn và lưu giữ bằng chứng

Giai đoạn cuối xác minh yêu cầu hỗ trợ thực tế và lưu giữ đủ bối cảnh để phân biệt các lỗi giải CAPTCHA, định tuyến và ứng dụng.

Hướng dẫn xác minh phản hồi phía máy chủ của Google yêu cầu xác minh token phản hồi và nêu rõ rằng token chỉ sử dụng một lần và hết hạn sau hai phút. Những quy tắc này không nên nhầm lẫn với khoảng thời gian truy xuất kết quả riêng của giải CAPTCHA. Ứng dụng do mình sở hữu phải thực hiện xác minh phía backend đặc trưng cho nhà cung cấp.

Sau đó, hệ thống kiểm thử QA nên kiểm tra tín hiệu hoàn thành thực tế của ứng dụng. Đối với cổng hỗ trợ, đó có thể là tham chiếu yêu cầu kiểm thử được trả về bởi backend do mình sở hữu. Một widget xanh hoặc trường phản hồi được điền đầy không thể xác định rằng yêu cầu hỗ trợ đúng đã được chấp nhận.

Lưu trữ một kết quả ngắn gọn bao gồm tham chiếu trường hợp kiểm thử, tham chiếu form, phiên bản widget, trạng thái giải CAPTCHA, trạng thái xác minh backend và kết quả thao tác mong muốn. Đây là các trường ứng dụng đề xuất. Tránh lưu trữ token giải pháp thô, nội dung tin nhắn hỗ trợ thực tế hoặc thông tin xác thực trong nhật ký thông thường.

Khi kiểm thử thất bại, giữ lại giai đoạn cuối cùng thành công. "Thiếu ánh xạ widget", "giải CAPTCHA trả về lỗi" và "ứng dụng từ chối gửi" yêu cầu các sửa chữa khác nhau. Lịch sử giai đoạn này làm cho điều tra hữu ích hơn so với một lỗi CAPTCHA không phân biệt.

Các trường hợp đa widget nào bạn nên kiểm thử?

Ma trận kiểm thử hữu ích thay đổi thứ tự widget và chu kỳ trong khi giữ nguyên thao tác form mong muốn.

Trường hợp kiểm thử trang do mình sở hữu	Hành vi quy trình mong muốn
Widget phản hồi xuất hiện trước widget hỗ trợ	Trình duyệt vẫn chọn widget của form hỗ trợ
Cả hai form chia sẻ một mã trang	Mối liên hệ form xác định lựa chọn
Hộp thoại hỗ trợ đóng trong khi giải	Kết quả được ghi nhận là không còn cần thiết
Widget hỗ trợ được làm mới trong khi giải	Kết quả cũ không được gán cho phiên bản thay thế
Widget không liên quan báo lỗi	Trình duyệt không thay đổi thao tác mong muốn
Form mong muốn không có ánh xạ widget duy nhất	Quy trình dừng trước khi yêu cầu giải CAPTCHA
Backend từ chối phản hồi đã gửi	Kiểm thử báo cáo lỗi xác minh, không phải thành công

Chạy ma trận với các fixture được kiểm soát trước, sau đó kiểm thử riêng biệt tích hợp thực tế được phép. Kiểm thử fixture xác lập hành vi định tuyến cục bộ; chúng không chứng minh rằng dịch vụ giải CAPTCHA bên ngoài hoặc dịch vụ xác minh nhà cung cấp hoạt động.

Vấn đề này khác với việc khởi chạy nhiều nhiệm vụ giải CAPTCHA độc lập cùng lúc. Hướng dẫn hiện tại về xử lý nhiều thách thức reCAPTCHA đồng thời đề cập đến xử lý nhiệm vụ đồng thời. Trên trang có nhiều widget, yêu cầu khó hơn là duy trì mối quan hệ giữa một hành động được mong muốn và widget cụ thể của nó.

Xây dựng quy trình theo thứ tự đó: chọn form, giữ mối liên hệ widget, chọn thông tin giải CAPTCHA được hỗ trợ, định tuyến kết quả và xác minh kết quả ứng dụng. Thêm CapSolver ở giai đoạn giải CAPTCHA một khi các kiểm tra quyền sở hữu rõ ràng và có thể kiểm thử đã được thực hiện.

FAQ

Câu hỏi: Việc phát hiện reCAPTCHA có cho biết cho agent form nào cần gửi không?

Việc phát hiện không xác định form mong muốn. Trình duyệt cần phạm vi nhiệm vụ của ứng dụng và mối liên hệ form-widget rõ ràng trước khi yêu cầu giải pháp hoặc gửi bất kỳ thứ gì.

Câu hỏi: Hai widget trên cùng một trang có thể chia sẻ một mã trang không?

Trang có thể tái sử dụng cấu hình tích hợp giữa các widget, do đó mã trang không nên được coi là định danh duy nhất cho lần thử form. Sử dụng phiên bản widget và bản ánh xạ form do mình sở hữu cùng nhau.

Câu hỏi: Tôi có thể chọn bản ghi thông tin CAPTCHA đầu tiên không?

Chọn bản ghi đầu tiên chỉ nếu bản ánh xạ trang do mình sở hữu xác nhận rằng đó là widget mong muốn. Vị trí trong danh sách không xác định quyền sở hữu, và thay đổi trang có thể thay đổi thành phần nào xuất hiện đầu tiên.

Câu hỏi: Trình duyệt AI có nên giải tất cả CAPTCHA mà nó phát hiện không?

Trình duyệt chỉ nên giải thử thách được hỗ trợ yêu cầu bởi thao tác được phép. Các widget không liên quan vẫn nằm ngoài nhiệm vụ đó, dù chúng có hiển thị trên cùng trang.

Câu hỏi: Điều gì sẽ xảy ra khi trang thay đổi trong khi giải?

Quy trình nên kiểm tra lại mối liên hệ trang và widget trước khi sử dụng kết quả. Nếu thành phần gốc bị thay thế hoặc lần thử kết thúc, ghi lại kết quả là không cần thiết và dừng lần thử đó thay vì định tuyến nó đến nơi khác.