Danh sách kiểm tra API Turnstile Solver: Đầu vào, Token và Xác thực

TL;DR

• Đánh giá API giải quyết Turnstile dựa trên widget và hợp đồng kết quả chính xác mà quy trình được phép của bạn yêu cầu.
• Giữ khóa dịch vụ giải quyết, khóa trang web công khai Turnstile và mật khẩu xác minh của chủ trang web tách biệt; chúng phục vụ các hệ thống khác nhau.
• Kiểm tra đầu vào nhiệm vụ được tài liệu hóa và trường token trước khi đánh giá độ trễ hoặc giá cả.
• Một nhiệm vụ giải quyết sẵn sàng và kết quả thao tác ứng dụng được chấp nhận là hai kết quả khác nhau và cần bằng chứng riêng biệt.
• Sử dụng khóa kiểm tra xác định để kiểm tra hành vi ứng dụng, sau đó đánh giá giải quyết thực tế trong môi trường do bạn sở hữu với chứng thực phù hợp.
• Ghi lại các yêu cầu không hỗ trợ hoặc chưa xác minh một cách rõ ràng thay vì coi tuyên bố "được hỗ trợ bởi Cloudflare" chung chung là đủ.

API giải quyết Turnstile có thể trả về phản hồi thành công trong khi ứng dụng của bạn vẫn từ chối thao tác. Việc tích hợp có thể đã chọn widget sai, bỏ qua dữ liệu ứng dụng, đọc trường giải pháp sai hoặc gửi sau khi thao tác đã hết hạn. Một đánh giá hữu ích xác định những sự không khớp này trước khi nhóm cam kết duy trì tích hợp.

CapSolver tài liệu về hợp đồng nhiệm vụ Turnstile có thể làm ví dụ cụ thể cho việc xem xét này. Danh sách kiểm tra dưới đây tập trung vào đầu vào, kết quả, xác minh và bằng chứng có thể lặp lại cho các quy trình QA do bạn sở hữu. Nó không xếp hạng nhà cung cấp hoặc báo cáo tỷ lệ thành công đã đo lường. Mục đích của nó là giúp bạn quyết định xem giao diện giải quyết cụ thể có phù hợp với ứng dụng bạn thực sự vận hành hay không.

Đánh giá nhà giải quyết Turnstile nên xác lập điều gì?

Một đánh giá nhà giải quyết Turnstile nên xác lập tính tương thích với nhiệm vụ được yêu cầu, hợp đồng kết quả có thể sử dụng và bằng chứng rằng ứng dụng dự định có thể chấp nhận kết quả.

Bắt đầu từ ứng dụng do bạn sở hữu và thao tác đang được kiểm tra. Ghi lại trang mong đợi, cấu hình widget và điều kiện hoàn thành. Một bài kiểm tra biểu mẫu liên hệ có thể yêu cầu máy chủ chấp nhận việc gửi thử nghiệm và trả lại mã nhận dạng. Việc nhận được token sẽ là một mốc quan trọng sớm, không phải kết quả cuối cùng.

Giữ đánh giá kỹ thuật này hẹp hơn so với một bài kiểm tra mua sắm tổng thể. Hướng dẫn chọn API CAPTCHA đề cập đến các yếu tố tích hợp và vận hành rộng hơn. Ở đây, câu hỏi trung tâm là liệu hợp đồng đầu vào và đầu ra của nhiệm vụ Turnstile có khớp với ứng dụng cụ thể hay không.

Định nghĩa kiểm tra API cung cấp bối cảnh kiểm tra rộng hơn. Đối với nhà giải quyết, phản hồi HTTP chỉ là một phần của bối cảnh đó: bài kiểm tra cũng cần duy trì thao tác ứng dụng nào đã yêu cầu kết quả và điều gì sẽ khiến thao tác đó hoàn tất.

Kiểm tra 1: Xác định cơ chế đúng và vai trò khóa

Xác nhận rằng thao tác sử dụng thành phần Turnstile tích hợp và phân biệt từng khóa theo dịch vụ tiêu thụ nó.

Hướng dẫn thiết lập Turnstile của Cloudflare mô tả khóa trang web công khai và mật khẩu phía máy chủ riêng. Khóa trang web xác định tích hợp widget. Mật khẩu của chủ trang web thuộc bước xác minh phía máy chủ. Chứng thực dịch vụ giải quyết xác thực yêu cầu của bạn đến dịch vụ giải quyết riêng biệt.

Không đặt mật khẩu xác minh của chủ trang web vào nhiệm vụ giải quyết chỉ vì nhiệm vụ yêu cầu một khóa. Trong nhiệm vụ Turnstile của CapSolver được tài liệu hóa, websiteKey đề cập đến khóa trang web công khai, trong khi clientKey xác thực yêu cầu của CapSolver. Xem xét đích của mỗi trường trước khi xử lý chứng thực thực tế.

Cũng xác nhận rằng trang là tích hợp Turnstile thay vì trải nghiệm CAPTCHA khác của Cloudflare. Một tuyên bố bao quát không đủ để xác lập tương thích với mọi cơ chế mang tên nhà cung cấp giống nhau. Nếu cơ chế trang không chắc chắn, hãy giải quyết sự không chắc chắn trước khi tạo nhiệm vụ thử nghiệm có phí.

Bản ghi đánh giá của bạn nên nêu tên nhiệm vụ được hỗ trợ chính xác và liệt kê bằng chứng ứng dụng được sử dụng để chọn nó. Bản ghi này trở nên hữu ích khi thay đổi trang sau này khiến tích hợp giống nhau hoạt động khác đi.

Kiểm tra 2: Phù hợp với hợp đồng đầu vào được tài liệu hóa

Phù hợp mỗi đầu vào nhiệm vụ bắt buộc với nguồn đáng tin cậy trong trạng thái hiện tại của ứng dụng do bạn sở hữu.

Tài liệu nhiệm vụ Turnstile của CapSolver tài liệu AntiTurnstileTaskProxyLess, websiteURL và websiteKey. Dữ liệu tùy chọn bao gồm action và cdata nơi tích hợp cung cấp chúng. Những trường này nên đến từ bối cảnh ứng dụng liên quan, không phải từ các giá trị sao chép từ ví dụ không liên quan.

Xem xét dữ liệu tùy chọn như yêu cầu tương thích

Một trường tùy chọn trong lược đồ dịch vụ vẫn có thể quan trọng đối với ứng dụng cụ thể. Nếu ứng dụng của bạn sử dụng dữ liệu hành động, hãy bao gồm yêu cầu này trong đánh giá và xác minh bản đồ của giao diện được chọn. Không thay thế trường đặc trưng reCAPTCHA chỉ vì cả hai cơ chế đều sử dụng từ "action."

SDK và API JSON nền tảng có thể hiển thị tên hoặc cấu trúc khác nhau. Nếu đánh giá bao gồm SDK, hãy kiểm tra bản đồ trường được tài liệu hóa như một bước riêng biệt. Sự hiện diện của một từ điển "thêm" tùy ý không phải là bằng chứng rằng giá trị cụ thể sẽ đến đúng trường nhiệm vụ.

Tránh yêu cầu proxy và trình duyệt được tạo ra

Tài liệu nhiệm vụ Turnstile hiện tại của CapSolver xác định nhiệm vụ không cần proxy và nói rằng User-Agent do người gọi cung cấp sẽ bị bỏ qua cho nhiệm vụ này. Không thêm proxy hoặc tuyên bố kiểm soát trình duyệt giải quyết chỉ vì một nhiệm vụ CAPTCHA khác có các tham số tương tự.

Nếu một yêu cầu quan trọng đối với môi trường của bạn nhưng tài liệu nhiệm vụ không mô tả nó, hãy ghi chú là chưa giải quyết và nhận câu trả lời cụ thể trước khi dựa vào nó. Điều này hữu ích hơn việc giả định rằng tên trường quen thuộc ngụ ý hành vi tương đương giữa các họ nhiệm vụ.

Kiểm tra 3: Hiểu chu kỳ nhiệm vụ và kết quả

Hiểu cách dịch vụ xác định nhiệm vụ đang tiến hành và nơi token Turnstile hoàn tất được trả về.

API createTask định nghĩa bao bọc yêu cầu dịch vụ. Đối với nhiệm vụ bất đồng bộ, hãy lưu trữ mã nhiệm vụ được trả về cùng với thao tác ứng dụng tạo ra nó. API getTaskResult định nghĩa việc lấy kết quả và tách biệt xử lý với sự sẵn sàng và lỗi.

Đối với nhiệm vụ Turnstile được tài liệu hóa, giải pháp bao gồm trường token. Không giả định rằng mọi nhiệm vụ CAPTCHA sử dụng tên trường kiểu reCAPTCHA, hoặc rằng một phản hồi không trống là giải pháp có thể sử dụng. Bản đồ của bạn nên cụ thể đủ để kết quả không mong đợi tạo ra lỗi rõ ràng.

Đánh giá điều gì xảy ra khi người gọi mất kết nối, nhận lỗi dịch vụ hoặc dừng chờ. Một thời gian chờ cục bộ không nên được hiểu là bằng chứng rằng nhà cung cấp chưa bao giờ tạo nhiệm vụ. Tránh tạo công việc thay thế một cách mù quáng khi kết quả của yêu cầu đầu tiên chưa rõ.

Bài viết này cung cấp danh sách kiểm tra hợp đồng thay vì triển khai kiểm tra lặp lại mới. Sử dụng ví dụ nhiệm vụ chính thức làm điểm bắt đầu triển khai, sau đó kiểm tra khách hàng được chọn và chính sách lỗi trong môi trường của bạn. Không có cuộc gọi nhà cung cấp trực tiếp hoặc kết quả thời gian nào được tuyên bố ở đây.

Nhận mã thưởng 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ã thưởng CAP26 khi nạp tiền vào tài khoản CapSolver để nhận thêm 5% thưởng trên mỗi lần nạp — không giới hạn.
Nhận mã thưởng ngay bây giờ trong Bảng điều khiển CapSolver

Kiểm tra 4: Tách xác minh token khỏi giải quyết

Xác minh token thuộc về máy chủ ứng dụng và phải tách biệt khỏi phản hồi nhiệm vụ sẵn sàng của nhà giải quyết.

Tài liệu Siteverify của Cloudflare yêu cầu xác minh phía máy chủ. Nó mô tả token Turnstile là một lần sử dụng và có hiệu lực trong năm phút. Ứng dụng cũng cần kiểm tra bối cảnh trả về liên quan, chẳng hạn như tên miền mong đợi và hành động, theo tích hợp của nó.

Những thuộc tính này ảnh hưởng đến thiết kế đánh giá. Một token đã được sử dụng không thể phục vụ như một tài sản thành công tái sử dụng. Một hàng đợi ứng dụng dài cũng có thể khiến phản hồi không sử dụng được ngay cả khi giải quyết đã hoàn tất trước đó. Đo lường các bước riêng biệt để tránh nhầm lẫn giữa công việc ứng dụng chậm với xử lý của nhà cung cấp.

Sử dụng điều kiện chấp nhận thực tế của ứng dụng

Đối với bài kiểm tra biểu mẫu liên hệ do bạn sở hữu, coi việc máy chủ chấp nhận thao tác thử nghiệm mong muốn là kiểm tra cuối cùng. Một phản hồi thành công phía khách hàng là bằng chứng cho sự kiện phía khách hàng. Một phản hồi Siteverify thành công là bằng chứng xác minh. Biểu mẫu vẫn có thể thất bại một quy tắc ứng dụng riêng biệt sau đó.

Giữ bằng chứng chính xác. Nếu xác minh thành công nhưng dữ liệu biểu mẫu yêu cầu bị thiếu, báo cáo từ chối ứng dụng thay vì lỗi nhà giải quyết. Nếu nhiệm vụ chưa bao giờ trả về kết quả, báo cáo giai đoạn đó thay vì. Một cờ "thất bại" duy nhất khiến việc chọn sửa chữa đúng hoặc so sánh hai phiên bản tích hợp trở nên khó khăn.

Không gửi chứng thực nhà giải quyết, mật khẩu xác minh hoặc token hoàn chỉnh vào nhật ký chung. Ghi lại các định danh và danh mục lý do đủ để chẩn đoán thao tác, với quyền truy cập bị giới hạn đối với bất kỳ bằng chứng bổ sung nào mà nhóm của bạn cần.

Kiểm tra 5: Tách các bài kiểm tra xác định khỏi giải quyết thực tế

Sử dụng các bài kiểm tra ứng dụng xác định để hành vi có thể dự đoán và một bài kiểm tra nhà giải quyết được phép riêng biệt để có bằng chứng dịch vụ thực tế.

Hướng dẫn kiểm tra của Cloudflare cung cấp khóa trang web và khóa bí mật giả với kết quả được kiểm soát. Những điều này hữu ích để kiểm tra xem ứng dụng của bạn có xử lý các đường dẫn xác minh thành công và thất bại mà không phụ thuộc vào thách thức biến đổi hay không.

Chúng không đo lường khả năng nhà giải quyết tạo ra kết quả sản xuất được chấp nhận. Một token giả và khóa bí mật thử nghiệm tương ứng thuộc về hợp đồng kiểm tra. Không trình bày một tài sản luôn thành công như bằng chứng rằng nhà giải quyết thương mại đạt được tỷ lệ thành công cụ thể.

Đối với giải quyết thực tế, sử dụng môi trường bạn sở hữu hoặc được cấp phép rõ ràng để kiểm tra, với cấu hình tương tự sản xuất và chứng thực dịch vụ cần thiết cho thử nghiệm đó. Giữ lưu lượng giao dịch giới hạn, tránh tạo thông báo cho khách hàng từ các gửi thử nghiệm tổng hợp và quyết định trước khi thử nghiệm dừng lại.

Nếu môi trường hoặc chứng thực đó thiếu, hoàn tất tài liệu và xem xét bản đồ cục bộ và ghi chú giai đoạn dịch vụ thực tế là chưa xác minh. Một yêu cầu thiếu rõ ràng là kết quả đánh giá hữu ích. Tạo ra một phản hồi thành công sẽ loại bỏ chính bằng chứng mà đánh giá được thiết kế để thu thập.

Trường hợp nào thuộc về bảng đánh giá hữu ích?

Bảng đánh giá hữu ích ghi lại kết quả mong đợi của mỗi giai đoạn liên quan trước khi chạy bài kiểm tra.

Trường hợp	Xử lý mong đợi	Bằng chứng cần giữ lại
Dữ liệu đầu vào bắt buộc bị thiếu	Từ chối yêu cầu hoặc ghi lại lỗi được tài liệu hóa	Tên trường và danh mục lỗi đã che
Dữ liệu tùy chọn của ứng dụng quan trọng	Xác minh giá trị đúng được bản đồ đến nhiệm vụ	Xem xét bản đồ và bối cảnh kiểm tra do bạn sở hữu
Nhiệm vụ vẫn đang xử lý	Giữ thao tác chờ trong ngân sách của nó	Tham chiếu nhiệm vụ và chuyển tiếp trạng thái
Token được trả về	Liên kết với thao tác hoạt động gốc	Hình dạng kết quả và ghi chú liên quan
Xác minh từ chối token	Lưu giữ lý do của máy chủ và dừng gửi này	Kết quả xác minh đã che
Biểu mẫu thay đổi trước khi hoàn tất	Đánh giá lại thao tác mong muốn trước khi sử dụng kết quả	Phiên bản biểu mẫu hoặc danh tính thao tác
Quy tắc ứng dụng thông thường thất bại	Báo cáo lỗi ứng dụng riêng biệt	Khẳng định ứng dụng và danh mục phản hồi

Bảng này là kế hoạch kiểm tra đề xuất, không phải các kết quả kiểm tra đã hoàn thành. Thêm yêu cầu cụ thể cho ứng dụng thay vì làm phình to danh sách với các trường hợp không ảnh hưởng đến quyết định.

Ví dụ, trang có nhiều widget cần liên kết biểu mẫu với widget rõ ràng. Một công nhân có thể khởi động lại cần cách xác định để xử lý các nhiệm vụ đang chạy. Những yêu cầu này thuộc về ứng dụng và khách hàng cùng nhau; chúng không nên được suy ra từ từ ngữ trên trang chủ của nhà cung cấp.

Bạn nên so sánh chi phí và độ trễ sau khi xác minh tương thích như thế nào?

So sánh chi phí và độ trễ trên cùng khối lượng công việc được phép chỉ sau khi hiểu các đường dẫn đầu vào và xác minh cần thiết.

Ghi lại thời gian tạo nhiệm vụ, thời điểm giải pháp có sẵn, hoàn tất xác minh và kết quả ứng dụng cuối cùng như các sự kiện riêng biệt. Bao gồm các lần thử thất bại trong báo cáo. Biểu đồ độ trễ chứa chỉ các mẫu thành công có thể che giấu các thất bại kéo dài, trong khi tính toán chi phí loại trừ các lần thử lại có thể dưới tính toán chi phí của các thao tác được chấp nhận.

Sử dụng hành vi thanh toán thực tế và bằng chứng hóa đơn hoặc sử dụng có sẵn cho dịch vụ được đánh giá. Không giả định rằng các nhiệm vụ thất bại luôn được tính phí, luôn được hoàn tiền hoặc bao gồm trong kế hoạch cụ thể. Đó là các điều khoản dịch vụ cụ thể cần kiểm tra hiện tại.

Báo cáo số lượng thao tác đã thử, số lượng được ứng dụng chấp nhận và các lần chưa giải quyết cùng với bất kỳ tỷ lệ phần trăm nào. Giữ cấu hình thách thức, phiên bản ứng dụng và khoảng thời gian đánh giá gắn với báo cáo để người đánh giá sau này có thể hiểu điều gì đã thay đổi.

Bản kiểm tra kỹ thuật này không cung cấp xếp hạng nhà cung cấp được đo lường. Nó cung cấp các yêu cầu bằng chứng cần thiết trước khi xếp hạng hoặc quyết định mua sắm có ý nghĩa cho khối lượng công việc của bạn.

Ra quyết định tích hợp từ bản đánh giá hợp đồng đã hoàn tất

Chọn giao diện giải quyết Turnstile khi hợp đồng nhiệm vụ được tài liệu hóa và kết quả chấp nhận quan sát của bạn đáp ứng yêu cầu ứng dụng.

Ghi lại điều gì đã được xác minh, điều gì thất bại và điều gì vẫn chưa được kiểm tra. Nếu bản đồ đầu vào rõ ràng nhưng xác minh máy chủ chưa bao giờ được thực hiện, sự phân biệt đó nên vẫn hiển thị trong quyết định. Đối với quy trình được hỗ trợ, CapSolver có thể cung cấp bước giải quyết trong khi ứng dụng của bạn giữ trách nhiệm cho thao tác dự định và kết quả cuối cùng.

FAQ

Câu hỏi: Nhà giải quyết có cần khóa bí mật Turnstile của tôi không?
Nhiệm vụ Turnstile của CapSolver được tài liệu hóa sử dụng websiteKey công khai và clientKey của CapSolver. Mật khẩu Turnstile của chủ trang web thuộc về xác thực phía máy chủ và không phải là một trường trong nhiệm vụ giải quyết đó.

Câu hỏi: Nhiệm vụ sẵn sàng có giống với việc gửi biểu mẫu thành công không?

A: Nhiệm vụ sẵn sàng cho biết kết quả giải quyết đã có sẵn. Ứng dụng vẫn cần xác thực token và kiểm tra riêng của mình trước khi coi hoạt động là hoàn tất.

Câu hỏi: Các khóa Turnstile giả có thể đo lường độ chính xác của người giải không?

Các khóa giả kiểm tra hành vi ứng dụng được kiểm soát. Chúng không xác lập độ chính xác giải quyết thương mại hoặc tỷ lệ chấp nhận trong sản xuất.

Câu hỏi: Tôi có nên thêm proxy vào mỗi nhiệm vụ Turnstile không?

Tuân theo tài liệu nhiệm vụ cụ thể. CapSolver hiện tại tài liệu AntiTurnstileTaskProxyLess cho Turnstile; các yêu cầu từ các nhiệm vụ CAPTCHA khác không nên được sao chép vào đó một cách tự động.

Câu hỏi: Tôi nên làm gì nếu một khả năng cần thiết chưa được tài liệu hóa?

Ghi chú khả năng chưa được giải quyết và lấy thông tin có thể kiểm chứng trước khi dựa vào nó. Không nên coi các khẳng định về phạm vi rộng hoặc các trường SDK có tên tương tự là bằng chứng.