Giải reCAPTCHA với getToken: Một Yêu Cầu, Không Cần Kiểm Tra

TL;DR

• Endpoint getToken của CapSolver có thể trả về kết quả reCAPTCHA được hỗ trợ trong phản hồi cho một yêu cầu.
• Gửi clientKey và đối tượng nhiệm vụ được hỗ trợ đến https://api.capsolver.com/getToken.
• Chọn loại nhiệm vụ cho biến thể reCAPTCHA của bạn và cung cấp các thông tin tương ứng như trang, khóa trang công khai và ngữ cảnh cần thiết.
• Đọc solution.gRecaptchaResponse sau khi kiểm tra kết quả API; việc trao đổi HTTP thành công là chưa đủ.
• Một token được trả về vẫn cần xác minh bình thường của ứng dụng sở hữu. Một yêu cầu không đồng nghĩa với việc hoàn thành tức thì hoặc đảm bảo được chấp nhận.
• Yêu cầu cURL dưới đây đã được kiểm tra với một bộ giả lập HTTP cục bộ. Một giải pháp thực tế chưa được thực hiện.

Một tích hợp giải pháp CAPTCHA truyền thống tạo một nhiệm vụ và sau đó yêu cầu kết quả của nó. Nếu bạn tích hợp một nhiệm vụ reCAPTCHA được hỗ trợ và muốn phản hồi trực tiếp, endpoint getToken của CapSolver cung cấp một mẫu yêu cầu khác được tài liệu hóa.

Sự khác biệt thực tế nằm ở phía client: gửi nhiệm vụ và chờ kết quả trong phản hồi HTTP đó. Bạn không cần viết một vòng lặp kiểm tra getTaskResult cho luồng này. Hướng dẫn này sẽ đi qua các trường nhiệm vụ, tệp JSON và lệnh cURL, token được trả về, và các kiểm tra cần thiết trước khi ứng dụng của bạn có thể chấp nhận nó.

getToken API là gì?

getToken API là một điểm cuối trả về kết quả trực tiếp cho các loại nhiệm vụ reCAPTCHA được liệt kê trong tài liệu của nó. Một điểm cuối API là địa chỉ cho một thao tác API cụ thể; việc sử dụng đường dẫn đúng sẽ chọn mẫu yêu cầu này.

Tài liệu getToken chính thức liệt kê các biến thể reCAPTCHA v2 và v3 được hỗ trợ, bao gồm các tùy chọn doanh nghiệp và proxy tương ứng. Không nên suy ra rằng endpoint này hỗ trợ AWS WAF, Turnstile hoặc nhận dạng hình ảnh từ tên chung chung của nó.

Phương pháp thay đổi cách lấy kết quả, không thay đổi ý nghĩa của các tham số thách thức. Một khóa trang công khai sai hoặc loại nhiệm vụ không khớp vẫn sẽ sai khi gửi qua endpoint trực tiếp. Xác minh gia đình CAPTCHA trước, sau đó chọn biến thể nhiệm vụ được tài liệu hóa.

Một số gia đình nhiệm vụ createTask đã trả về kết quả trực tiếp. So sánh không có nghĩa là mọi cuộc gọi createTask đều yêu cầu kiểm tra vòng lặp.

Bước 1: Xác định nhiệm vụ reCAPTCHA và khóa

Xác định tích hợp reCAPTCHA thực tế trên trang của bạn trước khi xây dựng yêu cầu. Ví dụ dưới đây sử dụng ReCaptchaV3TaskProxyLess, do đó các trường của nó phải mô tả tích hợp v3.

Giữ ba vai trò khóa tách biệt. API CapSolver cấp quyền cho yêu cầu giải quyết. Khóa trang công khai reCAPTCHA xác định tích hợp trang. Mật khẩu xác minh của chủ trang thuộc về máy chủ ứng dụng; nó không phải là clientKey hoặc websiteKey trong yêu cầu này.

Đối với v3, kiểm tra hành động được kỳ vọng cũng như khóa công khai. Tài liệu nhiệm vụ reCAPTCHA v3 giải thích các trường nhiệm vụ, bao gồm pageAction. Hành động mẫu submit dưới đây là một chỗ trống cho hành động mà biểu mẫu của bạn thực sự sử dụng.

Tài liệu reCAPTCHA v3 của Google mô tả đánh giá dựa trên hành động. Một token cho hành động khác nên không được coi là kết quả thành công của biểu mẫu mong muốn. Giữ hành động trong yêu cầu và hành động được kỳ vọng của backend đồng bộ.

Nếu trang sử dụng v2 hoặc Enterprise, hãy chọn loại nhiệm vụ và trường được tài liệu hóa thay vì chỉ thay đổi tiêu đề tích hợp. Tránh sao chép hành động v3 vào nhiệm vụ khác mà không kiểm tra yêu cầu của nó.

Bước 2: Lưu tệp JSON được tài liệu hóa

Lưu tệp JSON sau dưới tên request.json. Bao bọc của nó tuân theo tài liệu getToken, và các trường nhiệm vụ tuân theo hướng dẫn v3. Đây là các giá trị mẫu; thay thế chúng bằng cài đặt của bạn để kiểm tra thực tế.

{
  "clientKey": "YOUR_API_KEY",
  "task": {
    "type": "ReCaptchaV3TaskProxyLess",
    "websiteURL": "https://your-owned-test.example/form",
    "websiteKey": "YOUR_PUBLIC_SITE_KEY",
    "pageAction": "submit"
  }
}

Thay thế mọi mẫu trước khi liên hệ với endpoint sống. Tên miền ví dụ cố ý xác định một trang kiểm tra sở hữu và không phải là mục tiêu CAPTCHA hoạt động. Khóa công khai và hành động phải đến từ tích hợp được cấu hình trên trang đó.

Tệp JSON giúp dễ kiểm tra dữ liệu đầu vào mà không cần lệnh shell dài. Một khi chứa một chứng chỉ thực tế, hãy giới hạn quyền truy cập vào tệp đó và giữ nó ngoài kiểm soát nguồn. Sử dụng phương pháp quản lý bí mật phù hợp khi di chuyển yêu cầu này vào ứng dụng.

Tên nhiệm vụ không cần proxy mô tả biến thể nhiệm vụ của nhà cung cấp. Nó không loại bỏ nhu cầu ngữ cảnh trang chính xác, cũng không ngụ ý rằng mọi cấu hình thách thức sử dụng cùng các tham số. Sử dụng tài liệu nhiệm vụ làm tham chiếu trường.

Bước 3: Gửi một yêu cầu với cURL

Chạy lệnh này từ thư mục chứa request.json. Các cờ và dữ liệu đính kèm đã được kiểm tra với bộ giả lập HTTP cục bộ, nhưng endpoint sống vẫn yêu cầu chứng chỉ giải quyết và tham số trang sở hữu của bạn:

curl --silent --show-error --connect-timeout 10 --max-time 90 \
  --json @request.json \
  https://api.capsolver.com/getToken

Lệnh sử dụng tùy chọn yêu cầu JSON của cURL để gửi tệp làm nội dung. Tài liệu cURL JSON chính thức giải thích tùy chọn và các tiêu đề yêu cầu của nó. Sử dụng phiên bản cURL hỗ trợ --json.

Các giá trị thời gian kết nối và tổng thời gian là lựa chọn cục bộ cho ví dụ này. Chúng không phải là cam kết dịch vụ của nhà cung cấp. Endpoint có thể giữ yêu cầu trong khi giải quyết nhiệm vụ, do đó phản hồi trực tiếp không đồng nghĩa với phản hồi tức thì.

Kiểm tra cả kết quả HTTP và nội dung JSON. Lệnh này hiển thị nội dung phản hồi và lỗi giao thức; nó không phải là trình xử lý lỗi ứng dụng hoàn chỉnh. cURL có thể hoàn thành giao dịch HTTP ngay cả khi JSON trả về mô tả lỗi của nhà cung cấp. Ứng dụng nên nhánh dựa trên các trường trả về thay vì tìm chuỗi token trong đầu ra terminal.

Không thêm vòng lặp kiểm tra vào lệnh này như bước tiếp theo mặc định. Luồng được chọn được thiết kế đặc biệt để trả về kết quả trực tiếp. Nếu ứng dụng của bạn cần theo dõi nhiệm vụ với việc lấy kết quả riêng, hãy chọn và triển khai luồng createTask được tài liệu hóa từ đầu.

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

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 — không giới hạn.
Nhận mã ngay trong Bảng điều khiển CapSolver

Bước 4: Đọc phản hồi token trực tiếp

Đọc solution.gRecaptchaResponse chỉ sau khi xác nhận rằng kết quả báo cáo thành công và sẵn sàng. Hình dạng phản hồi sau là minh họa; giá trị token là mẫu, không phải token được trả về từ giải pháp thực tế.

{
  "errorId": 0,
  "status": "ready",
  "solution": {
    "gRecaptchaResponse": "ILLUSTRATIVE_TOKEN_VALUE"
  }
}

Các giá trị quan trọng là chỉ số lỗi, trạng thái sẵn sàng và trường kết quả không trống. Không coi một đối tượng phản hồi, ID nhiệm vụ hoặc trạng thái HTTP thành công là thay thế cho token sử dụng được. Các trường tùy chọn cũng có thể xuất hiện; chỉ giữ lại những trường cần thiết cho tích hợp của bạn.

Trong trường hợp lỗi của nhà cung cấp, kiểm tra mã lỗi và mô tả được mô tả bởi tham chiếu lỗi API. Giữ đủ thông tin để phân biệt giữa tham số sai và vấn đề tài khoản hoặc lỗi truyền tải, đồng thời loại bỏ chứng chỉ và token khỏi nhật ký thông thường.

Một endpoint trực tiếp đơn giản hóa máy trạng thái client, nhưng kết nối vẫn là một phần của thao tác. Nếu client hết thời gian hoặc mất phản hồi, kết quả có thể không chắc chắn. Yêu cầu có thể đã đến nhà cung cấp trước khi lỗi cục bộ xảy ra. Không mô tả việc gửi lại ngay lập tức là tiếp tục nhiệm vụ đầu tiên trừ khi API mô tả rõ ràng hành vi đó.

Bước 5: Xác minh token trong ứng dụng sở hữu của bạn

Một token được trả về phải vượt qua xác minh bình thường của ứng dụng trước khi thao tác được coi là thành công. Kết quả giải quyết và chấp nhận của ứng dụng là hai sự kiện riêng biệt.

Tài liệu xác minh phía máy chủ của Google nêu rõ rằng các token phản hồi hết hạn sau hai phút và chỉ có thể được xác minh một lần. Nhận token gần thao tác được dự định và tránh kiểm tra cùng token nhiều lần qua điểm cuối xác minh.

Đối với luồng xác minh tiêu chuẩn, bí mật của chủ trang vẫn ở phía máy chủ. Kiểm tra các thuộc tính phản hồi liên quan đến tích hợp của bạn, bao gồm tên miền được kỳ vọng và, đối với v3, hành động và chính sách điểm số. Ứng dụng doanh nghiệp nên sử dụng tích hợp xác minh hoặc đánh giá tương ứng thay vì giả định rằng ví dụ tiêu chuẩn bao gồm mọi biến thể.

Xem xét một biểu mẫu sở hữu với hành động submit. Một bài kiểm tra hữu ích trước tiên xác minh rằng nhiệm vụ được yêu cầu mô tả hành động đó, sau đó gửi token trả về qua đường dẫn máy chủ bình thường của biểu mẫu, và cuối cùng xác nhận rằng thao tác kiểm tra được chấp nhận. Một chuỗi token in trong terminal chỉ chứng minh rằng một chuỗi đã được nhận.

Đối với việc diễn giải điểm số, xem hướng dẫn điểm số reCAPTCHA v3. Việc chuyển đổi endpoint lấy kết quả không thiết lập điểm số cụ thể hoặc loại bỏ quy tắc chấp nhận của máy chủ.

Khi nào nên sử dụng getToken thay vì kiểm tra vòng lặp?

Sử dụng getToken khi biến thể nhiệm vụ được hỗ trợ và client có thể giữ yêu cầu mở trong khi chờ kết quả. Điều này phù hợp với tích hợp trực tiếp nhỏ trong đó bước ứng dụng tiếp theo ngay lập tức tiêu thụ token trả về.

Sử dụng API createTask và luồng kết quả được tài liệu hóa khi ứng dụng của bạn cụ thể cần tạo nhiệm vụ và lấy kết quả riêng biệt. Ví dụ, một công nhân lưu trữ ID nhiệm vụ giữa các bước có thể được tổ chức quanh mô hình này.

Chọn dựa trên chu kỳ sống của client thay vì giả định một endpoint nào đó luôn nhanh hơn. Yêu cầu trực tiếp loại bỏ mã kiểm tra vòng lặp của client, nhưng điều đó không chứng minh độ trễ giải quyết thấp hơn. Một công nhân nền cũng có thể cần các kiểm soát mà một cuộc gọi HTTP đồng bộ không cung cấp.

Không chuyển đổi gia đình CAPTCHA chỉ để phù hợp với endpoint được ưa chuộng. Trang xác định loại thách thức. Nếu gia đình không được liệt kê cho getToken, hãy tuân theo API được tài liệu hóa cho gia đình đó.

Thử nghiệm của ví dụ xác định điều gì?

Lệnh cURL đã được thực hiện với bộ giả lập HTTP cục bộ với chỉ endpoint được thay thế. Bộ giả lập kiểm tra đường dẫn POST, loại nội dung JSON và dữ liệu được phân tích, sau đó trả về phản hồi sẵn sàng được cung cấp. Điều này xác minh lệnh dựa trên tệp và xử lý phản hồi trực tiếp.

Không có khóa giải quyết thực tế, nhiệm vụ trả phí hoặc biểu mẫu được bảo vệ bởi reCAPTCHA nào được sử dụng. Token giả lập không hợp lệ cho bất kỳ ứng dụng nào. Một tích hợp thực tế vẫn cần khóa trang thực tế, hành động, chứng chỉ giải quyết và kết quả xác minh của ứng dụng sở hữu.

Trước khi mở rộng vượt quá một bài kiểm tra duy nhất, ghi lại biến thể nhiệm vụ và trường nào hoạt động với trang sở hữu. Nếu bài kiểm tra thất bại, xác định xem thất bại xảy ra trong giai đoạn gửi nhiệm vụ, lấy kết quả, xác minh token hay thao tác ứng dụng cuối cùng. Những phân biệt này cung cấp điểm bắt đầu cụ thể mà không cần thêm vòng lặp kiểm tra.

Try CapSolver với một nhiệm vụ reCAPTCHA được hỗ trợ để hoàn thành bước xác minh thực tế. Giữ cùng các trường yêu cầu và kiểm tra chấp nhận khi di chuyển yêu cầu đã được chứng minh từ cURL vào ứng dụng của bạn.

Câu hỏi thường gặp

Câu hỏi: getToken có yêu cầu getTaskResult không?

Luồng trực tiếp được mô tả ở đây trả về kết quả trong phản hồi getToken, do đó client không cần kiểm tra getTaskResult. Việc theo dõi nhiệm vụ với việc lấy kết quả riêng thuộc về tích hợp createTask tương ứng.

Câu hỏi: getToken có thể giải mọi loại CAPTCHA không?

Chỉ sử dụng các loại nhiệm vụ được liệt kê trong tài liệu của nó. Các biến thể reCAPTCHA được tài liệu hóa không ngụ ý hỗ trợ cho các gia đình không liên quan như AWS WAF hoặc nhận dạng hình ảnh.

Câu hỏi: getToken nhanh hơn createTask không?

Hướng dẫn này không thiết lập lợi thế độ trễ. Sự khác biệt thiết kế quan sát được là client chờ kết quả trực tiếp thay vì triển khai vòng lặp lấy kết quả riêng.

Câu hỏi: websiteKey có phải là bí mật xác minh riêng không?

Không. Đó là khóa trang công khai cho tích hợp trang. Bí mật xác minh của trang vẫn ở phía máy chủ, trong khi clientKey là chứng chỉ dịch vụ giải quyết.

Câu hỏi: Tại sao token được trả về có thể thất bại trong xác minh?

Kiểm tra thời hạn, việc sử dụng trước, ngữ cảnh trang được kỳ vọng, hành động và phản hồi xác minh của ứng dụng. Việc nhận token từ nhà giải quyết không đảm bảo ứng dụng sẽ chấp nhận nó.

Câu hỏi: Token mẫu được tạo từ giải pháp thực tế không?

Không. Phản hồi được hiển thị là minh họa, và lệnh đã được kiểm tra với bộ giả lập HTTP cục bộ. Hoàn thành bài kiểm tra thực tế riêng với chứng chỉ giải quyết của bạn và ứng dụng sở hữu.