Chrome DevTools Protocol + CaptchaAI untuk diagnostik CAPTCHA di lingkungan pengujian

Lingkup aman: Panduan ini hanya untuk lingkungan QA, staging, dan praproduksi milik sendiri atau yang sudah Anda kantongi otorisasinya. Isinya soal pola diagnostik, pengujian, dan observabilitas untuk integrasi CAPTCHA Anda sendiri — bukan untuk situs pihak ketiga atau alur tanpa izin.

Kalau widget CAPTCHA muncul di produksi tapi menghilang di staging, atau backend Anda menolak token yang jelas-jelas valid, jawabannya hampir selalu ada di lapisan jaringan — dan di situlah Chrome DevTools Protocol (CDP) menang. CDP membuka request jaringan, siklus hidup halaman, dan eksekusi JavaScript apa adanya, sehingga Anda bisa melihat persis apa yang dikirim browser dan apa yang dijawab server, bukan menebak dari layar yang blank.

Untuk tim QA di Indonesia yang lingkungan CI-nya berjalan di AWS ap-southeast-1 (Singapura) atau ap-southeast-3 (Jakarta), pendekatan ini praktis: satu skrip diagnostik yang bisa Anda jalankan di pipeline, tanpa perlu buka DevTools secara manual di setiap build.

Empat langkah diagnostik, sekilas

Alur diagnostik CAPTCHA di staging bisa dipadatkan menjadi urutan yang selalu sama, dari lapisan jaringan ke lapisan backend:

1. Rekam trafik jaringan untuk memastikan request widget benar-benar terjadi.
2. Konfirmasi sitekey yang tertanam di halaman uji cocok dengan konfigurasi server.
3. Kirim task ke CaptchaAI, lalu polling sampai token siap.
4. Verifikasi apakah backend menerima token itu — dan kalau menolak, cari tahu kenapa.

Apa yang bisa Anda lihat lewat CDP di QA

CDP bukan sekadar pengganti klik kanan "Inspect". Untuk diagnostik integrasi CAPTCHA di halaman uji sendiri, empat hal ini yang paling sering menyelamatkan waktu debugging:

• Trafik jaringan mentah — setiap request ke widget CAPTCHA, termasuk yang gagal diam-diam sebelum halaman selesai render.
• Deteksi sitekey pada halaman milik sendiri, langsung dari DOM, tanpa mengira-ngira dari HTML statis.
• Timing siklus request, dari navigasi sampai loadEventFired, untuk menemukan race condition antara skrip CAPTCHA dan kode Anda.
• Jejak verifikasi backend, supaya Anda tahu apakah penolakan datang dari token, action, atau konfigurasi secret yang tidak sinkron.

Langkah 1: rekam trafik jaringan dengan CDP

Langkah pertama diagnosis adalah melihat request apa saja yang benar-benar terjadi. Buka sesi CDP lewat Playwright, aktifkan domain Network, lalu catat setiap URL yang lewat. Kalau request ke skrip CAPTCHA tidak pernah muncul di log, masalahnya ada di loading halaman staging, bukan di penyelesaian CAPTCHA-nya.

import asyncio, json
from playwright.async_api import async_playwright

async def trace_qa():
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        ctx = await browser.new_context()
        client = await ctx.new_cdp_session(await ctx.new_page())
        await client.send('Network.enable')
        client.on('Network.requestWillBeSent', lambda e: print(e['request']['url']))

Filter output berdasarkan pola seperti recaptcha, turnstile, atau challenges.cloudflare.com untuk menyaring kebisingan dan langsung fokus ke request yang relevan.

Langkah 2: konfirmasi sitekey di halaman uji internal

Setelah trafik terlihat, pastikan sitekey yang tertanam di halaman sama dengan yang diharapkan backend. Buka halaman QA Anda (misalnya https://staging.example.com/captcha-demo) dan ekstrak atribut data-sitekey dari elemen .g-recaptcha atau .cf-turnstile. Bandingkan nilai itu dengan konfigurasi server. Sitekey yang tertukar antara environment staging dan produksi adalah salah satu penyebab paling umum backend menolak token yang sebenarnya sah.

Langkah 3: kirim task ke CaptchaAI dari QA

Begitu sitekey terkonfirmasi, kirim task ke in.php memakai URL staging Anda, lalu polling res.php sampai statusnya selesai. Simpan waktu penyelesaian sebagai metrik diagnostik — angka ini menjadi baseline yang berguna untuk membandingkan build berikutnya. CaptchaAI menyelesaikan reCAPTCHA v2, Cloudflare Turnstile, dan Cloudflare Challenge, jadi satu alur diagnostik yang sama bisa Anda pakai untuk ketiga tipe di halaman uji.

Karena penagihan CaptchaAI berbasis thread (bukan per solve), pipeline CI yang menjalankan banyak validasi QA per hari tetap punya biaya yang bisa diprediksi — sebuah nilai plus untuk tim dan agensi yang sensitif terhadap biaya.

Langkah 4: verifikasi respons backend

Ini bagian yang sering terlewat. Suntikkan token ke formulir QA, submit, lalu lewat CDP periksa apakah backend Anda menjawab dengan kode sukses. Token yang lolos di sisi browser tapi mental di sisi server hampir selalu berujung pada satu dari tiga nilai yang tidak sinkron.

Tiga nilai yang wajib dicek saat token ditolak

• action — pada reCAPTCHA v3, nilai yang tidak cocok akan ditolak backend meski token valid.
• sitekey — pastikan halaman staging memakai sitekey yang sama dengan yang diverifikasi server.
• secret — nilai yang masih menunjuk ke environment lain adalah penyebab klasik penolakan diam-diam.

Hanya trace CDP yang menunjukkan ketiganya apa adanya, tanpa perlu menebak dari pesan error yang samar.

Tabel pemecahan masalah cepat

Observabilitas dan logging QA

Catat log terstruktur untuk setiap eksekusi QA. Metrik yang dianjurkan: durasi total token, kode respons HTTP, ID task, dan kedalaman antrean. Pisahkan saluran log per lingkungan (development, staging, praproduksi) dan korelasikan dengan distributed tracing (mis. OpenTelemetry) lewat correlation id. Kemampuan memutar ulang skenario penuh dari satu id biasanya memangkas waktu diagnosis insiden setidaknya separuh. Untuk tim yang berjalan di region Jakarta atau Singapura, mencatat latensi jaringan terpisah dari waktu penyelesaian CAPTCHA juga membantu memisahkan masalah rute dari masalah integrasi.

Checklist sebelum rilis

• Cakupan pengujian dibatasi pada aplikasi sendiri atau sumber daya yang Anda miliki otorisasinya — sejalan dengan prinsip UU PDP: hanya uji data yang memang berhak Anda proses.
• Kunci CaptchaAI disimpan di secret manager CI atau vault, bukan di source code.
• Setiap eksekusi mencatat latensi dan kode status respons.
• Strategi retry idempoten dengan batas atas untuk error sementara.
• Pengujian dapat direproduksi di pipeline CI.

Contoh lengkap pemanggilan QA dengan Python

Contoh Python berikut menunjukkan alur minimum untuk memvalidasi widget CAPTCHA pada lingkungan staging milik Anda sendiri lewat CaptchaAI: kirim task, lalu polling sampai token siap.

import os
import time
import requests

API_KEY = os.environ['CAPTCHAAI_KEY']
QA_PAGE_URL = os.environ['QA_PAGE_URL']  # contoh: https://staging.example.com/qa-login
QA_SITE_KEY = os.environ['QA_SITE_KEY']


def submit_qa_recaptcha() -> str:
    payload = {
        'key': API_KEY,
        'method': 'userrecaptcha',
        'googlekey': QA_SITE_KEY,
        'pageurl': QA_PAGE_URL,
        'json': 1,
    }
    response = requests.post(
        'https://ocr.captchaai.com/in.php',
        data=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()['request']


def fetch_qa_result(task_id: str) -> dict:
    params = {
        'key': API_KEY,
        'action': 'get',
        'id': task_id,
        'json': 1,
    }
    while True:
        response = requests.get(
            'https://ocr.captchaai.com/res.php',
            params=params,
            timeout=30,
        )
        response.raise_for_status()
        data = response.json()
        if data.get('request') != 'CAPCHA_NOT_READY':
            return data
        time.sleep(5)

FAQ

Apa bedanya CDP dengan Selenium biasa untuk diagnostik ini?

CDP bekerja langsung di level protokol, jadi Anda melihat request jaringan dan siklus halaman apa adanya tanpa lapisan abstraksi. Untuk QA, artinya Anda bisa memeriksa persis request mana yang gagal — sesuatu yang sulit dilihat dari API WebDriver tingkat tinggi.

Kenapa widget CAPTCHA muncul di produksi tapi tidak di staging?

Biasanya karena sitekey atau domain yang terdaftar berbeda antar environment. Trace CDP akan menunjukkan apakah skrip widget gagal dimuat atau ditolak karena domain staging belum diizinkan pada konfigurasi CAPTCHA Anda.

Berapa lama waktu penyelesaian yang wajar dijadikan baseline QA?

Jangan patok satu angka; catat waktu penyelesaian aktual dari beberapa eksekusi di staging Anda, lalu jadikan median-nya sebagai baseline. Bandingkan build berikutnya terhadap baseline itu, bukan terhadap angka pihak lain.

Bisakah alur QA ini dipakai untuk hCaptcha?

Untuk hCaptcha, belum bisa lewat CaptchaAI — hCaptcha dan FunCaptcha tidak termasuk tipe yang didukung saat ini. Alur diagnostik di panduan ini berlaku untuk reCAPTCHA v2/v3, Cloudflare Turnstile dan Challenge, serta GeeTest v3.

Panduan terkait

• Panduan mulai cepat CaptchaAI
• Pola QA CAPTCHA yang terotorisasi
• Menguji endpoint CAPTCHA pada formulir sendiri
• Saat tes browser gagal padahal API berjalan normal
• Menyelesaikan reCAPTCHA v2 lewat API
• Menyelesaikan Cloudflare Turnstile lewat API
• Menyelesaikan GeeTest v3 lewat API

Validasi integrasi CAPTCHA Anda di lingkungan sendiri dengan CaptchaAI.