Cách thêm giải CAPTCHA Gumloop vào quy trình web

TL;DR

• Giải CAPTCHA của Gumloop không phải là một kết nối native được xác minh; hãy sử dụng các nút HTTP và định tuyến được tài liệu của Gumloop cùng với dịch vụ phục hồi trình duyệt do tổ chức sở hữu.
• Giữ phát hiện thử thách và áp dụng token trong cùng một phiên trình duyệt được ủy quyền thay vì yêu cầu nút workflow tái tạo trạng thái trang.
• Định tuyến các trạng thái cụ thể như NO_CHALLENGE, RECOVERED, REVIEW, và STOP bằng quy tắc xác định, không phải quyết định của mô hình mở rộng.
• Giới hạn dịch vụ phục hồi chỉ với các adapter reCAPTCHA v2/v3 và Cloudflare Turnstile được tài liệu, một lần thử workflow theo mặc định, và xác minh ứng dụng rõ ràng.
• Gửi các loại không được hỗ trợ, phiên mất kết nối, thử thách lặp lại và xác thực không rõ ràng đến hàng đợi con người mà không tiếp tục hành động web.

Giới thiệu

Giải CAPTCHA của Gumloop hoạt động tốt nhất như một nhánh phục hồi được kiểm soát xung quanh một nhiệm vụ trình duyệt được ủy quyền, không phải là tích hợp native được giả định. Gumloop có thể phối hợp các đầu vào, cuộc gọi HTTP, định tuyến và đường dẫn lỗi, trong khi một công nhân trình duyệt bên ngoài duy trì phiên trang và áp dụng kết quả được xác minh. CapSolver có thể cung cấp lớp CAPTCHA được tài liệu bên trong công nhân đó. Sự phân tách này quan trọng vì kết quả API riêng lẻ không chứng minh rằng trang gốc đã tiến triển. Workflow phải kiểm tra trạng thái trình duyệt, thực thi ngân sách thử lại và dừng lại khi xác thực hoặc liên tục phiên không chắc chắn. Mẫu dưới đây dành cho tự động hóa hợp pháp, hợp lý, có trách nhiệm trên các hệ thống và dữ liệu bạn có thể truy cập.

Bắt đầu với Khoảng trống Tiền điều kiện

Không có kết nối native Gumloop–CapSolver nào được xác minh trong nghiên cứu cho hướng dẫn này. Do đó, giải CAPTCHA của Gumloop cần một tiền điều kiện rõ ràng: đội của bạn phải vận hành một dịch vụ HTTPS sở hữu phiên trình duyệt được ủy quyền và cung cấp một điểm cuối phục hồi hẹp. Đây không phải là API riêng của Gumloop, nút ẩn, hay tuyên bố rằng Gumloop tích hợp chính thức với CapSolver.

Biên giới tuân theo khả năng được tài liệu cho Gumloop. Nút Gọi API có thể gửi yêu cầu GET hoặc POST đến một điểm cuối HTTPS với tiêu đề và nội dung yêu cầu. Nút hợp đồng nút Đầu vào có thể nhận giá trị từ người dùng, webhook hoặc mặc định. Những khả năng này đủ để gọi một dịch vụ do tổ chức kiểm soát, nhưng chúng không tạo hoặc duy trì phiên trình duyệt riêng.

Những gì phải tồn tại trước khi xây dựng luồng

Chuẩn bị các thành phần này trước:

• một công nhân trình duyệt được ủy quyền sở hữu trang, cookie, lưu trữ, user agent và ngữ cảnh mạng;
• một điểm cuối phục hồi HTTPS được bảo vệ bởi xác thực dịch vụ;
• một khóa API CapSolver được lưu trữ chỉ trong quản lý bí mật của dịch vụ phục hồi;
• một danh sách cho phép các host và hành động được phép;
• một phản hồi có kiểu với các trạng thái kết thúc và không có thông tin xác thực thô;
• một đích kiểm tra thủ công cho các trường hợp không được hỗ trợ hoặc mơ hồ.

Nếu bất kỳ thành phần nào thiếu, hãy giữ giải pháp CAPTCHA của Gumloop ở trạng thái thiết kế hoặc kiểm tra. Không thay thế bằng nút Gumloop chưa được xác minh hoặc đặt khóa API sản xuất trong văn bản workflow thông thường.

Sử dụng Hợp đồng Luồng Năm Giai đoạn

Một thiết kế giải CAPTCHA Gumloop đáng tin cậy tách biệt giữa phối hợp và thực thi trình duyệt. Bảng Gumloop nên mô hình hóa đường đi quyết định; công nhân trình duyệt nên sở hữu phát hiện thử thách, gọi CapSolver, áp dụng kết quả và kiểm tra trang.

Giai đoạn 1: Nhận một sự kiện trình duyệt giới hạn

Luồng bắt đầu với một webhook hoặc đầu vào thủ công chứa một tham chiếu chạy mờ. Không gửi cookie, mật khẩu, HTML thô hoặc bản sao lưu lưu trữ trình duyệt. Một sự kiện tối thiểu có thể trông như sau:

{
  "run_id": "run_01JX...",
  "session_ref": "browser_session_7f2a",
  "approved_host": "portal.example",
  "approved_action": "submit_owned_test_form",
  "observed_state": "CHALLENGE_DETECTED",
  "challenge_type": "recaptcha_v2",
  "attempt": 0
}

Đầu vào là một tham chiếu đến một thực thi đã được phê duyệt. Đầu ra của giai đoạn này là một yêu cầu phục hồi hợp lệ hoặc STOP. Luồng dừng ngay lập tức nếu host, hành động hoặc tham chiếu phiên vắng mặt hoặc ngoài chính sách.

Giai đoạn 2: Gọi dịch vụ phục hồi

Cấu hình nút Gọi API để gửi yêu cầu POST đến một điểm cuối do tổ chức sở hữu như https://automation.example.net/v1/browser/recover. Sử dụng chứng chỉ được quản lý cho tiêu đề xác thực dịch vụ. Nội dung phải truyền các trường sự kiện giới hạn, không phải khóa API CapSolver.

{
  "run_id": "{{run_id}}",
  "session_ref": "{{session_ref}}",
  "approved_host": "{{approved_host}}",
  "approved_action": "{{approved_action}}",
  "challenge_type": "{{challenge_type}}",
  "attempt": "{{attempt}}",
  "max_attempts": 1
}

JSON này là hợp đồng HTTP chung cho dịch vụ của bạn. Nó không phải là xuất khẩu Gumloop và không phải là yêu cầu API CapSolver. Trước khi triển khai, xác nhận chính xác các biến thay thế và kiểm soát chứng chỉ có sẵn trong không gian làm việc Gumloop của bạn.

Giai đoạn 3: Trả về chỉ trạng thái vận hành

Dịch vụ nên trả về một phản hồi nhỏ mà Gumloop có thể định tuyến mà không cần xem giá trị giải pháp thô:

{
  "state": "RECOVERED",
  "run_id": "run_01JX...",
  "correlation_id": "recovery_91c8",
  "attempts_used": 1,
  "continuation_verified": true,
  "reason": "expected form step became visible"
}

Các phản hồi kết thúc hữu ích là NO_CHALLENGE, RECOVERED, REVIEW, và STOP. Một sự cố dịch vụ tạm thời có thể trả về RETRYABLE_ERROR, nhưng Gumloop nên tiêu thụ ngân sách thử lại một lần trước khi gọi lại. Không coi một trạng thái thiếu, nội dung không thể phân tích hoặc HTTP 200 với giá trị không xác định là thành công.

Giai đoạn 4: Định tuyến với điều kiện chính xác

Sử dụng chế độ chuẩn của Router Gumloop để khớp trạng thái chính xác. Giải quyết thử thách là một vấn đề kiểm soát xác định, do đó không cần diễn giải mô hình.

Bảng này xác định đầu ra của giải pháp CAPTCHA Gumloop, không phải trạng thái nhiệm vụ nội bộ của nhà cung cấp. Trạng thái nhà cung cấp phải được giải quyết bên trong dịch vụ phục hồi trước khi đầu ra kết thúc đến workflow.

Giai đoạn 5: Xử lý sự cố truyền tải riêng biệt

Bao bọc nút Gọi API với nhánh lỗi của Bộ chắn Lỗi của Gumloop. Kích hoạt truyền qua chỉ cho các trường đầu vào không bí mật cần thiết để điều tra một cuộc gọi thất bại. Đường dẫn lỗi nên tạo bản ghi kiểm tra hoặc gửi thông báo; nó không nên tự động kết nối lại với hành động trình duyệt.

Sự cố truyền tải, lỗi nhà cung cấp, từ chối ứng dụng và thử thách không được hỗ trợ yêu cầu bằng chứng khác nhau. Kết hợp cả bốn vào một nhánh thử lại khiến giải pháp CAPTCHA của Gumloop khó vận hành và có thể tạo lưu lượng lặp lại sau một sự cố kết thúc.

Triển khai Dịch vụ Phục hồi với Trường Chính thức của CapSolver

Dịch vụ phục hồi là nơi các trường chính thức của CapSolver thuộc về. Yêu cầu createTask chấp nhận clientKey và một đối tượng nhiệm vụ. Phản hồi getTaskResult sử dụng errorId, status và solution cho các nhiệm vụ bất đồng bộ. Trạng thái phản hồi chính thức cho biết kết quả processing có thể được truy vấn lại sau ba giây.

Ví dụ Python sau chỉ triển khai bộ thích hợp reCAPTCHA v2. Nó sử dụng các trường được tài liệu ReCaptchaV2TaskProxyLess, websiteURL và websiteKey từ định nghĩa nhiệm vụ reCAPTCHA v2. Các hàm phát hiện và áp dụng cụ thể trình duyệt là các mẫu do công nhân của bạn sở hữu; chúng không phải là phương thức API Gumloop hoặc CapSolver.

import os
import time
import requests

CAPSOLVER_KEY = os.environ["CAPSOLVER_API_KEY"]
CREATE_TASK = "https://api.capsolver.com/createTask"
GET_RESULT = "https://api.capsolver.com/getTaskResult"
APPROVED_HOSTS = {"portal.example"}


def solve_recaptcha_v2(website_url: str, website_key: str) -> dict:
    created = requests.post(
        CREATE_TASK,
        json={
            "clientKey": CAPSOLVER_KEY,
            "task": {
                "type": "ReCaptchaV2TaskProxyLess",
                "websiteURL": website_url,
                "websiteKey": website_key,
            },
        },
        timeout=15,
    ).json()

    if created.get("errorId") or not created.get("taskId"):
        return {"state": "REVIEW", "reason": "task creation failed"}

    for _ in range(4):
        time.sleep(3)
        result = requests.post(
            GET_RESULT,
            json={"clientKey": CAPSOLVER_KEY, "taskId": created["taskId"]},
            timeout=15,
        ).json()

        if result.get("errorId"):
            return {"state": "REVIEW", "reason": "provider returned an error"}
        if result.get("status") == "ready":
            return {"state": "SOLUTION_READY", "solution": result["solution"]}
        if result.get("status") != "processing":
            return {"state": "REVIEW", "reason": "unexpected task status"}

    return {"state": "STOP", "reason": "poll budget exhausted"}


def recover_authorized_session(event: dict, browser_store) -> dict:
    if event.get("approved_host") not in APPROVED_HOSTS:
        return {"state": "STOP", "reason": "host outside approved scope"}
    if event.get("attempt", 0) >= event.get("max_attempts", 1):
        return {"state": "STOP", "reason": "attempt budget exhausted"}

    page = browser_store.get(event["session_ref"])
    if page is None:
        return {"state": "REVIEW", "reason": "browser session unavailable"}

    info = detect_supported_challenge(page)  # your verified browser adapter
    if info is None:
        return {"state": "NO_CHALLENGE"}
    if info["type"] != "recaptcha_v2":
        return {"state": "REVIEW", "reason": "adapter not configured"}

    solved = solve_recaptcha_v2(info["website_url"], info["website_key"])
    if solved["state"] != "SOLUTION_READY":
        return solved

    apply_solution_in_same_session(page, solved["solution"])
    if not verify_expected_transition(page, event["approved_action"]):
        return {"state": "REVIEW", "reason": "application did not advance"}

    return {"state": "RECOVERED", "continuation_verified": True}

Đầu vào hàm là một sự kiện chạy được phê duyệt cộng với một tham chiếu phiên trình duyệt mờ. Đầu ra là trạng thái kết thúc cho Gumloop. Nó dừng lại khi host không được phê duyệt, ngân sách thử nghiệm hết, phiên trình duyệt không có sẵn, bộ thích hợp không được hỗ trợ, lỗi nhà cung cấp, trạng thái nhiệm vụ không mong đợi, ngân sách kiểm tra hết hoặc kiểm tra ứng dụng thất bại.

Không tái sử dụng đối tượng nhiệm vụ v2 cho các loại thử thách khác. Tạo các bộ thích hợp riêng từ hướng dẫn nhiệm vụ reCAPTCHA v3 chính thức và hướng dẫn nhiệm vụ Cloudflare Turnstile. Giữ các trường cần thiết, giải pháp trả về, logic ứng dụng trình duyệt và khẳng định kiểm tra của mỗi bộ thích hợp tách biệt.

Nhận Mã Thưởng CapSolver

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

Giữ Liên tục Trình duyệt Ngoài Bảng Vẽ

Liên tục phiên là ranh giới quyết định trong giải CAPTCHA của Gumloop. Một giải pháp có thể hợp lệ về mặt kỹ thuật nhưng vẫn thất bại khi trả về trang khác, bộ cookie, user agent, danh tính proxy, tuyến đường hoặc hành động được bảo vệ.

Luồng Gumloop nên truyền một session_ref mờ; nó không nên xây dựng lại trạng thái trình duyệt từ các trường sao chép. Công nhân phục hồi giải quyết tham chiếu đó, xác nhận URL hiện tại và thử thách, áp dụng kết quả trong cùng môi trường trình duyệt và kiểm tra một khẳng định ứng dụng cụ thể. Ví dụ bao gồm bước biểu mẫu trở nên hiển thị, tuyến QA được sở hữu hoàn thành hoặc phần tử trang công khai mong đợi xuất hiện.

Kiểm tra ứng dụng phải mạnh hơn "cuộc gọi HTTP thành công." Bài viết chẩn đoán n8n bên cạnh minh họa tại sao các nền tảng workflow cần kiểm tra sau phục hồi riêng. Trong Gumloop, mô phỏng kiểm tra đó như một phần của phản hồi công nhân và yêu cầu continuation_verified=true trước khi nhánh thành công có thể chạy.

Thiết lập Ngân sách Thử lại Không Thể Vòng lặp

Một luồng giải CAPTCHA Gumloop tốt có hai ngân sách: ngân sách kiểm tra nhà cung cấp bên trong dịch vụ phục hồi và ngân sách thử lại của workflow trong Gumloop. Chúng giải quyết các vấn đề khác nhau.

Ngân sách kiểm tra nhà cung cấp kiểm soát thời gian dịch vụ chờ đợi cho một nhiệm vụ vẫn đang xử lý. Ngân sách thử lại của workflow kiểm soát việc Gumloop có thể gọi lại dịch vụ phục hồi sau lỗi truyền tải tạm thời hay không. Chính sách bắt đầu hợp lý là một lần thử phục hồi workflow và một vòng lặp kiểm tra nhà cung cấp nhỏ, có thời gian. Điều chỉnh các giá trị này chỉ từ các tải công việc được ủy quyền quan sát.

Dừng mà không thử lại khi:

• host trang hoặc hành động mong đợi khác với sự kiện được phê duyệt;
• phiên trình duyệt không thể khôi phục;
• loại thử thách không thể phân loại hoặc không có bộ thích hợp được cấu hình;
• mục tiêu đạt đến biên giới đăng nhập, thanh toán, riêng tư, bị hạn chế hoặc dữ liệu nhạy cảm ngoài quyền ủy quyền;
• nhà cung cấp trả về lỗi kết thúc;
• cùng thử thách xuất hiện lại sau khi áp dụng kết quả;
• chuyển tiếp ứng dụng mong đợi không xảy ra;
• phản hồi dịch vụ trống, bị hỏng hoặc sử dụng trạng thái không xác định.

Luồng nên ghi lại lý do dừng, ID liên kết, số lần thử và định danh mục đích bị che. Nó không nên lưu trữ khóa API, cookie, giá trị giải pháp thô hoặc nội dung trang không cần thiết trong nhật ký thông thường.

Thêm Phản hồi Thủ công mà Không Cần Tạo Nút Dừng

Phản hồi của con người phụ thuộc vào bề mặt Gumloop bạn đang sử dụng. Đối với quy trình làm việc tiêu chuẩn, định tuyến REVIEW đến một thông báo, vé, bảng, hoặc hàng đợi thủ công khác, sau đó kết thúc hành động trình duyệt tự động. Không nên khẳng định rằng mọi quy trình làm việc đều có thể tạm dừng vô thời hạn trừ khi kế hoạch và cấu hình Gumloop của bạn chứng minh điều đó.

Gumloop ghi chú riêng về phê duyệt của con người cho các cuộc gọi công cụ của đại lý. Nếu hành động phục hồi được hiển thị cho một đại lý Gumloop như một công cụ được phê duyệt, bạn có thể yêu cầu phê duyệt trước khi gọi công cụ và để đại lý tiếp tục sau khi đưa ra quyết định. Đây là tùy chọn kiểm soát của đại lý, không phải bằng chứng về kết nối CapSolver và không phải là thay thế cho các kiểm tra cấp phép của dịch vụ phục hồi.

Một người vận hành xem xét bằng chứng giải CAPTCHA của Gumloop nên thấy được:

• máy chủ và hành động được phê duyệt;
• danh mục thử thách, không có giá trị giải pháp thô;
• trạng thái phiên trình duyệt;
• số lần thử đã sử dụng và còn lại;
• tuyên bố ứng dụng cuối cùng;
• lý do chính xác mà việc thực thi tự động dừng lại.

Phê duyệt nên cho phép một hành động được đặt tên, không mở rộng chạy sang máy chủ hoặc phạm vi dữ liệu mới.

Kiểm tra các nhánh thất bại trước khi sản xuất

Xác minh giải CAPTCHA của Gumloop với các bộ dữ liệu mẫu trên hệ thống bạn sở hữu hoặc được phép kiểm tra. Bộ kiểm thử nên bao gồm cả bảng canvas của Gumloop và công nhân trình duyệt.

1. Gửi một sự kiện NO_CHALLENGE hợp lệ và xác nhận quy trình làm việc tiếp tục mà không gọi điểm cuối phục hồi.
2. Gửi một bộ dữ liệu reCAPTCHA v2 được phê duyệt và xác nhận công nhân trình duyệt bảo tồn phiên và chỉ trả về RECOVERED sau khi tuyên bố ứng dụng được xác minh.
3. Trả về processing cho đến khi ngân sách kiểm tra nhà cung cấp hết hạn và xác nhận dịch vụ trả về STOP.
4. Mô phỏng thời gian chờ điểm cuối phục hồi và xác nhận Error Shield sử dụng đường dẫn xem xét thay vì đường dẫn thành công.
5. Trả về một trạng thái không xác định và xác nhận Router chọn nhánh bắt tất cả cuối cùng.
6. Xóa phiên trình duyệt và xác nhận luồng không tạo ra ngữ cảnh mới một cách im lặng.
7. Hiển thị một bộ dữ liệu reCAPTCHA v3 hoặc Turnstile trước khi bộ chuyển đổi được cấu hình và xác nhận kết quả là REVIEW.
8. Lặp lại thử thách sau khi ứng dụng và xác nhận quy trình làm việc không tiêu thụ vòng lặp thử lại không giới hạn.

Bằng chứng kiểm tra cuối cùng nên trả lời bốn câu hỏi: Quy trình được cấp phép chưa? Bộ chuyển đổi thử thách được ghi chú chưa? Phiên trình duyệt ban đầu tiếp tục không? Trạng thái ứng dụng mong muốn đã tiến triển chưa? Một câu trả lời "có" từ cuộc gọi API riêng lẻ là không đủ.

Kết luận

Giải CAPTCHA của Gumloop đáng tin cậy khi Gumloop vẫn là nhà điều phối và một dịch vụ trình duyệt được cấp phép sở hữu phục hồi nhạy cảm với phiên. Sử dụng hành vi được ghi chú của Input, Gọi API, Router và Error Shield; tiết lộ một hợp đồng HTTP nhỏ; giữ cho việc thử lại có giới hạn; xác minh chuyển tiếp trang ban đầu; và định tuyến sự không chắc chắn đến xem xét. Không nên khẳng định một kết nối native hoặc sao chép trạng thái trình duyệt vào quy trình. Đối với tự động hóa web được phê duyệt cần xử lý được ghi chú cho reCAPTCHA v2/v3 hoặc Cloudflare Turnstile phía sau các kiểm soát này, hãy đánh giá CapSolver như thành phần phục hồi bên trong ranh giới dịch vụ của bạn.

FAQ

Gumloop có tích hợp chính thức với CapSolver không?

Không có kết nối native Gumloop-CapSolver nào được xác minh cho hướng dẫn này. Việc triển khai sử dụng khả năng HTTP và định tuyến được ghi chú của Gumloop để gọi một dịch vụ phục hồi do tổ chức sở hữu, tích hợp CapSolver.

Tôi có thể gọi API CapSolver trực tiếp từ nút Gọi API của Gumloop không?

Nút Gọi API có thể gửi các yêu cầu POST, nhưng các cuộc gọi trực tiếp có thể tiết lộ thông tin xác thực nhà cung cấp và vẫn không lưu trữ hoặc tiếp tục phiên trình duyệt. Một dịch vụ phục hồi phía máy chủ hẹp là ranh giới vận hành an toàn hơn vì nó lưu trữ khóa, sở hữu phiên, áp dụng kết quả và chỉ trả về trạng thái đã xác minh.

Loại CAPTCHA nào mà quy trình nên hỗ trợ?

Đối với mẫu này, cấu hình các bộ chuyển đổi được ghi chú riêng biệt cho reCAPTCHA v2, reCAPTCHA v3 bao gồm Enterprise khi phù hợp, và Cloudflare Turnstile. Không nên tái sử dụng các trường giữa các loại nhiệm vụ hoặc xem loại không hỗ trợ là lỗi có thể thử lại.

Quy trình Gumloop nên cho phép bao nhiêu lần thử lại?

Bắt đầu với một lần thử lại quy trình. Giữ việc kiểm tra nhà cung cấp bên trong dịch vụ phục hồi với ngân sách thời gian và truy vấn riêng. Dừng lại khi thử thách lặp lại, liên tục phiên bị mất, nhà cung cấp trả về lỗi, hoặc kiểm tra ứng dụng thất bại.

Khi nào Gumloop nên gửi một quy trình đến xem xét của con người?

Sử dụng xem xét của con người khi cấp phép không rõ ràng, phiên trình duyệt bị thiếu, loại thử thách không được hỗ trợ, phản hồi bị hỏng, ngân sách thử đã hết, hoặc chuyển tiếp trang mong đợi không xảy ra. Xem xét không nên mở rộng máy chủ, hành động hoặc phạm vi dữ liệu được phê duyệt.