reCAPTCHA v2 hoạt động thế nào và cách giải (sắp ra mắt)
reCAPTCHA v2 là captcha kinh điển của Google. Nó hiển thị một ô đánh dấu có nhãn "I'm not a robot" và, khi không chắc về người truy cập, nó thêm một thử thách hình ảnh. Bộ giải cho nó phải tạo ra một token phản hồi hợp lệ mà trang có thể xác minh với Google. Scarnox sẽ sớm hỗ trợ reCAPTCHA v2. Hướng dẫn này giải thích widget hoạt động ra sao, các hướng tiếp cận chung mọi người dùng hiện nay, và những gì nên kỳ vọng từ một bộ giải dạng token.
Scarnox chưa giải reCAPTCHA v2 trực tiếp. Loại task đang hoạt động duy nhất hiện nay là PopularCaptcha, proxyless. Nếu dự án của bạn cần reCAPTCHA v2 ngay bây giờ, các hướng tiếp cận dưới đây là lựa chọn thực tế.
Widget hoạt động thế nào
Trang nhúng một phần tử chứa có thuộc tính data-sitekey. Sitekey đó định danh trang với Google. Khi widget tải, nó chạy các kiểm tra trong trình duyệt, xem hành vi, cookie và lịch sử của người truy cập, rồi gửi đánh giá rủi ro tới Google.
Nếu đánh giá là rủi ro thấp, ô đánh dấu tự tick, và widget ghi một token vào trường ẩn tên g-recaptcha-response. Nếu đánh giá rủi ro cao hơn, người truy cập thấy một thử thách hình ảnh, chẳng hạn chọn các ô có một vật thể cụ thể. Vượt qua thử thách cũng ghi token.
Backend của trang sau đó gửi token tới endpoint xác minh của Google, cùng với secret key của trang. Google trả về thành công hoặc thất bại. Vì việc xác minh diễn ra ở phía server, một form chấp nhận token mà không kiểm tra với Google thì không thực sự được reCAPTCHA bảo vệ.
Vì sao bị gắn cờ
Ô đánh dấu là một quyết định rủi ro, không phải một câu đố. Các nguyên nhân thường gặp là:
- một loạt request từ một địa chỉ IP;
- một phiên trình duyệt mới không có cookie hoặc lịch sử;
- một môi trường trình duyệt trông như tự động hóa, chẳng hạn cấu hình headless mặc định;
- một kiểu nhập liệu không giống người di chuyển chuột hoặc gõ phím.
Hiểu các nguyên nhân này quan trọng hơn bản thân widget. Nếu lưu lượng của bạn không kích hoạt ô đánh dấu, bạn sẽ không bao giờ thấy thử thách hình ảnh.
Các hướng tiếp cận chung hiệu quả hiện nay
Các hướng tiếp cận này được dùng rộng rãi, và chúng là những hướng trung thực. Chúng làm giảm tần suất thử thách xuất hiện với công việc hợp pháp.
- Giữ phiên thật. Dùng lại cookie và một profile trình duyệt nhất quán trong suốt phiên, thay vì bắt đầu mới ở mỗi trang.
- Điều tiết request. Tốc độ đều và chậm trông giống người hơn nhiều so với một đợt bùng phát.
- Dùng trình duyệt thật cho widget. Một trình duyệt đầy đủ với cài đặt thông thường ít bị gắn cờ hơn một cấu hình headless tối giản. Hướng dẫn phát hiện headless browser liệt kê các tín hiệu thường gặp.
- Xin ngoại lệ hoặc khóa thử nghiệm. Nếu bạn sở hữu trang, dùng khóa thử nghiệm đã công bố của Google trong môi trường staging. Nếu không, hãy xin chủ trang đưa vào danh sách cho phép.
- Có người trong vòng lặp. Với tác vụ khối lượng thấp, một người có thể hoàn thành ô đánh dấu và chuyển token đi. Cách này chậm nhưng đáng tin cậy.
Các hướng tiếp cận này không đảm bảo thử thách không bao giờ xuất hiện. Chúng làm giảm tần suất, và đó là điều giữ cho một công việc hợp pháp ổn định.
Bộ giải dạng token sẽ làm gì
Một bộ giải dạng token cho reCAPTCHA v2 làm điều tương tự PopularCaptcha làm hiện nay. Nó nhận sitekey và URL trang, tạo một token g-recaptcha-response hợp lệ, và trả nó về cho code của bạn. Sau đó code của bạn ghi token vào form và gửi trước khi token hết hạn.
Scarnox sẽ tài liệu hóa loại task và các trường bổ sung trong tài liệu API khi hỗ trợ reCAPTCHA v2 ra mắt. Cho đến lúc đó, đừng xây dựng dựa trên một giao diện giả định. Cấu trúc request sẽ tương tự ví dụ PopularCaptcha, nhưng hãy kiểm tra tài liệu để biết các giá trị chính xác.
Danh sách kiểm tra cho công việc reCAPTCHA v2
Khi bạn lên kế hoạch một công việc chạm tới form reCAPTCHA v2, hãy kiểm tra các điểm sau:
- Trang có phải của bạn không? Nếu có, dùng khóa thử nghiệm trong staging và giữ các lần thử trên production ở mức tối thiểu.
- Công việc có hợp pháp không? Thu thập dữ liệu công khai và quy trình làm việc của chính bạn là hợp pháp; lạm dụng tài khoản và spam thì không.
- Tốc độ có đủ thấp để ô đánh dấu im lặng không?
- Bạn có kế hoạch cho thử thách hình ảnh chưa, hoặc là một người, hoặc là một bộ giải khi nó đã hoạt động?
- Bạn có kiểm tra kết quả xác minh phía server, không chỉ sự tồn tại của token không?
Lỗi thường gặp
Lỗi phổ biến nhất của một tích hợp reCAPTCHA v2 là một token trông đúng nhưng trang vẫn từ chối. Ba nguyên nhân chiếm phần lớn các trường hợp này. Thứ nhất là sitekey và URL trang không khớp: token gắn với trang nơi widget được hiển thị, nên một sitekey lấy từ trang này rồi gửi tới trang khác sẽ thất bại. Thứ hai là token cũ. Token có thời hạn ngắn, nên một script giải trước rồi chạy một chuỗi bước khác dài sẽ gửi một giá trị đã hết hạn. Thứ ba là thiếu kiểm tra phía server ở phía bạn. Nếu các kiểm thử của bạn chỉ xác nhận token tồn tại, bạn sẽ không nhận ra bước xác minh đang thất bại.
Một nhóm lỗi thứ hai đến từ quy trình quanh widget. Đăng nhập trên một phiên rồi gửi form từ một phiên khác là lỗi thường gặp, vì việc xác minh có thể phụ thuộc vào phiên đã tải widget. Thử gửi lại một form bị từ chối nhiều lần liên tiếp cũng làm phiên trông đáng ngờ, và có thể biến một thử thách đơn lẻ thành một loạt thử thách. Khi có lỗi, hãy dừng lại, kiểm tra trạng thái trang, rồi thử một lần nữa với giá trị mới.
Scrape có trách nhiệm
Nếu form là một phần của công việc scraping, hãy kiểm tra robots.txt và điều khoản của trang trước khi bắt đầu. Giữ tốc độ thấp, và đừng thu thập dữ liệu cá nhân mà bạn không cần. Hướng dẫn về tính hợp pháp của web scraping bao quát các cân nhắc chính.