Scarnox · Blog

reCAPTCHA v2 ทำงานอย่างไรและแก้อย่างไร (เร็ว ๆ นี้)

reCAPTCHA v2 เป็น captcha คลาสสิกของ Google มันแสดงช่องติ๊กที่มีข้อความ "I'm not a robot" และเมื่อไม่แน่ใจเกี่ยวกับผู้เข้าชม ก็จะเพิ่มความท้าทายรูปภาพ solver สำหรับตัวนี้ต้องสร้าง response token ที่ถูกต้องซึ่งเว็บไซต์สามารถตรวจกับ Google ได้ การรองรับ reCAPTCHA v2 ของ Scarnox กำลังจะมาเร็ว ๆ นี้ คู่มือนี้อธิบายว่า widget ทำงานอย่างไร แนวทางทั่วไปที่คนใช้กันในปัจจุบัน และสิ่งที่ควรคาดหวังจาก solver ที่ใช้ token

Scarnox ยังไม่ solve reCAPTCHA v2 แบบใช้งานจริง task type เดียวที่ใช้งานได้จริงในวันนี้คือ PopularCaptcha แบบ proxyless หากโปรเจกต์ของคุณต้องการ reCAPTCHA v2 ตอนนี้ แนวทางด้านล่างคือตัวเลือกที่เป็นไปได้จริง

หน้าเว็บฝัง container element ที่มี attribute data-sitekey sitekey นั้นระบุเว็บไซต์กับ Google เมื่อ widget โหลด มันรันการตรวจสอบในเบราว์เซอร์ โดยดูพฤติกรรมของผู้เข้าชม cookie และประวัติ แล้วส่งการประเมินความเสี่ยงไปยัง Google

หากการประเมินเป็นความเสี่ยงต่ำ ช่องติ๊กจะถูกติ๊กเองและ widget เขียน token ลงในฟิลด์ที่ซ่อนชื่อ g-recaptcha-response หากการประเมินเป็นความเสี่ยงสูงกว่า ผู้เข้าชมจะเห็นความท้าทายรูปภาพ เช่น การเลือกช่องที่มีวัตถุบางอย่าง การผ่านความท้าทายก็เขียน token เช่นกัน

จากนั้น backend ของเว็บไซต์จะส่ง token นั้นไปยัง endpoint ตรวจสอบของ Google พร้อม secret key ของเว็บไซต์ Google ตอบกลับว่าสำเร็จหรือล้มเหลว เนื่องจากการตรวจสอบเกิดขึ้นบนเซิร์ฟเวอร์ ฟอร์มที่ยอมรับ token โดยไม่ตรวจกับ Google จึงไม่ได้รับการป้องกันจาก reCAPTCHA เลย

ทำไมจึงถูกทำเครื่องหมาย

ช่องติ๊กคือการตัดสินความเสี่ยง ไม่ใช่ปริศนา ตัวกระตุ้นที่พบบ่อยคือ:

request จำนวนมากที่พุ่งมาจาก IP address เดียว
session ใหม่ที่ไม่มี cookie หรือประวัติ
สภาพแวดล้อมเบราว์เซอร์ที่ดูเหมือนถูกควบคุมอัตโนมัติ เช่น การตั้งค่า headless แบบค่าเริ่มต้น
รูปแบบการป้อนข้อมูลที่ไม่เหมือนคนขยับเมาส์หรือพิมพ์

การเข้าใจตัวกระตุ้นเหล่านี้สำคัญกว่าตัว widget เองมาก หากทราฟฟิกของคุณไม่ไปกระตุ้นช่องติ๊ก คุณก็จะไม่เห็นความท้าทายรูปภาพ

แนวทางทั่วไปที่ใช้ได้ในวันนี้

แนวทางเหล่านี้ถูกใช้อย่างกว้างขวาง และเป็นแนวทางที่ซื่อตรง แนวทางเหล่านี้ช่วยลดความถี่ที่ความท้าทายปรากฏในงานที่ชอบด้วยกฎหมาย

รักษา session ให้เหมือนจริง ใช้ cookie และโปรไฟล์เบราว์เซอร์ที่สม่ำเสมอตลอด session แทนการเริ่มใหม่ทุกหน้า
ควบคุมจังหวะ request อัตราที่คงที่และช้าดูเหมือนคนมากกว่าการพุ่งเป็นชุด
ใช้เบราว์เซอร์จริงสำหรับ widget เบราว์เซอร์เต็มรูปแบบที่ตั้งค่าปกติมีโอกาสถูกทำเครื่องหมายน้อยกว่า headless ที่ถูกตัดทอน คู่มือการตรวจจับ headless browser แสดงสัญญาณที่พบบ่อย
ขอข้อยกเว้นหรือ test key หากคุณเป็นเจ้าของเว็บไซต์ ให้ใช้ test key ที่ Google เผยแพร่ใน staging หากไม่ใช่ ให้ขอให้เจ้าของเพิ่มคุณเข้า allowlist
ให้มนุษย์อยู่ในลูป สำหรับงานปริมาณน้อย คนสามารถติ๊กช่องและส่ง token ต่อได้ วิธีนี้ช้าแต่เชื่อถือได้

แนวทางเหล่านี้ไม่รับประกันว่าความท้าทายจะไม่ปรากฏเลย แต่ช่วยลดความถี่ ซึ่งทำให้งานที่ชอบด้วยกฎหมายมีเสถียรภาพ

solver ที่ใช้ token จะทำอะไร

solver สำหรับ reCAPTCHA v2 ที่ใช้ token ทำสิ่งเดียวกับที่ PopularCaptcha ทำในวันนี้ มันรับ sitekey และ URL ของหน้า สร้าง token g-recaptcha-response ที่ถูกต้อง และคืนให้โค้ดของคุณ จากนั้นโค้ดของคุณใส่ token ลงในฟอร์มและส่งก่อนที่ token จะหมดอายุ

Scarnox จะบันทึกประเภท task และฟิลด์เพิ่มเติมใด ๆ ไว้ใน API reference เมื่อการรองรับ reCAPTCHA v2 เปิดให้ใช้งาน จนกว่าจะถึงตอนนั้น อย่าสร้างโค้ดจาก interface ที่สมมติขึ้น รูปแบบ request จะคล้ายกับตัวอย่าง PopularCaptcha แต่ให้ตรวจเอกสารเพื่อดูค่าที่แน่นอน

checklist สำหรับงาน reCAPTCHA v2

เมื่อคุณวางแผนงานที่แตะฟอร์ม reCAPTCHA v2 ให้ตรวจจุดเหล่านี้:

เว็บไซต์เป็นของคุณหรือไม่ หากใช่ ให้ใช้ test key ใน staging และทดสอบบน production น้อยที่สุด
งานนี้ชอบด้วยกฎหมายหรือไม่ การเก็บข้อมูลสาธารณะและเวิร์กโฟลว์ของคุณเองเป็นสิ่งที่ชอบด้วยกฎหมาย ส่วนการแอบใช้บัญชีและสแปมไม่ใช่
อัตรา request ต่ำพอที่ช่องติ๊กจะไม่ถูกกระตุ้นหรือไม่
คุณมีแผนสำหรับความท้าทายรูปภาพไหม ไม่ว่าจะเป็นคนหรือ solver เมื่อมันเปิดให้ใช้งาน
คุณตรวจผลการตรวจสอบฝั่งเซิร์ฟเวอร์หรือไม่ ไม่ใช่แค่ดูว่ามี token อยู่หรือไม่

ความผิดพลาดที่พบบ่อย

ปัญหาที่พบบ่อยที่สุดในการเชื่อมต่อ reCAPTCHA v2 คือ token ที่ดูถูกต้องแต่เว็บไซต์ปฏิเสธ มีสาเหตุหลักสามอย่าง อย่างแรกคือ sitekey กับ URL ของหน้าไม่ตรงกัน token ผูกกับหน้าที่แสดง widget ดังนั้น sitekey ที่นำมาจากหน้าหนึ่งแต่ส่งไปยังอีกหน้าจะล้มเหลว อย่างที่สองคือ token ที่หมดอายุ token มีอายุสั้น ดังนั้นสคริปต์ที่ solve ก่อนแล้วค่อยทำขั้นตอนอื่นที่ช้า ๆ จะส่งค่าที่หมดอายุแล้ว อย่างที่สามคือไม่มีการตรวจฝั่งเซิร์ฟเวอร์ที่ปลายทางของคุณ หากการทดสอบของคุณตรวจแค่ว่ามี token อยู่ คุณจะไม่สังเกตเห็นว่าขั้นตอนการตรวจสอบล้มเหลว

ความผิดพลาดกลุ่มที่สองมาจากเวิร์กโฟลว์รอบ ๆ widget การล็อกอินบน session หนึ่งแล้วส่งฟอร์มจากอีก session หนึ่งเป็นสิ่งที่พบบ่อย เพราะการตรวจสอบอาจขึ้นอยู่กับ session ที่โหลด widget การ retry ฟอร์มที่ถูกปฏิเสธหลายครั้งติดกันก็ทำให้ session ดูน่าสงสัย ซึ่งอาจเปลี่ยนความท้าทายเดียวให้กลายเป็นชุดของความท้าทาย เมื่อมีอะไรล้มเหลว ให้หยุด ตรวจสถานะของหน้า แล้วลองอีกครั้งด้วยค่าใหม่

Scrape อย่างมีความรับผิดชอบ

หากฟอร์มเป็นส่วนหนึ่งของงาน scraping ให้ตรวจ robots.txt และข้อกำหนดการใช้งานของเว็บไซต์ก่อนเริ่ม รักษาอัตราให้ต่ำ และอย่าเก็บข้อมูลส่วนบุคคลที่ไม่จำเป็น คู่มือความถูกกฎหมายของ web scraping ครอบคลุมประเด็นหลัก