CapSolver reCAPTCHA entegrasyonunu solvethree'ye taşıyın

solvethree varsayılan olarak reCAPTCHA v3 Enterprise kullanır ve standart v3’ü de kabul eder. Diğer herkese açık ürünleri Kasada ve Ticketmaster TMPT’dir. reCAPTCHA v2, hCaptcha, Turnstile veya tarayıcı uzantısıyla çözümü desteklemez; dolayısıyla her CapSolver entegrasyonunun yerini alabilecek evrensel bir alternatif değildir.

Bir reCAPTCHA görevi göndermeden önce hedef siteyi konsolda yapılandırın ve çalışma alanınızın kullanabileceği etkin bir profil olduğundan emin olun. Ana makine adı ve eylem göndermek bu profili oluşturmaz. CapSolver’ın websiteKey alanını kaldırıp kalan isteğin yeterli olduğunu varsaymayın.

Başlangıç isteği, CapSolver’ın clientKey alanını ve sağlayıcıya özgü görev sarmalayıcısını kullanır:

{
  "clientKey": "CAPSOLVER_API_KEY",
  "task": {
    "type": "ReCaptchaV3Task",
    "websiteURL": "https://accounts.example.com/login",
    "websiteKey": "PUBLIC_SITE_KEY",
    "pageAction": "login",
    "isEnterprise": true,
    "proxy": "http://user:[email protected]:8080"
  }
}

solvethree için aşağıdaki düz gövdeyi POST https://api.solvethree.com/v1/tasks adresine gönderin. Authorization başlığını Bearer ve ardından çalışma alanınızın API anahtarı olacak şekilde ayarlayın. Bu anahtarı sunucuda tutun; clientKey alanını yeni JSON gövdesine taşımayın.

{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "example_login_001"
}

Örnek, recaptchaType değerini varsayılanda bıraktığı için bir Enterprise isteğidir. Hedefiniz standart v3 kullanıyorsa bunu açıkça seçin; her CapSolver görev türünü varsayılan Enterprise türüne dönüştürmeyin.

Bir CapSolver ProxyLess görevinin burada doğrudan proxy’siz karşılığı yoktur: solvethree, çağıranın bir proxy girdisi sağlamasını gerektirir. Mevcut entegrasyonunuz bir proxy yönetmiyorsa bu, alan adı değişikliği değil, entegrasyon değişikliğidir. Yeni isteğe bir SOCKS proxy yapılandırması da kopyalamayın; solvethree HTTP ve HTTPS proxy URL’lerini kabul eder.

Çözüm ve gönderim için kullanılan yolun net olması için tek bir proxy ile başlayın. Bunun yerine proxyCandidates kullanıyorsanız yol, sorgu veya fragment içermeyen en fazla on iki farklı HTTP veya HTTPS proxy URL’si sağlayın. Adaylar, hizmetin alternatif ağ çıkışlarını denemesini sağlar; bir proxy’nin veya hedefin çalışacağını garanti etmez.

CapSolver, asenkron sonuçları clientKey ve taskId ile getTaskResult üzerinden alır. solvethree bunları Bearer kimlik doğrulamalı GET /v1/tasks/:id üzerinden alır. HTTP çağrısının yanı sıra sonuç ayrıştırıcısını da güncelleyin; CapSolver’ın durum ve hata alanları farklı bir sözleşmeye aittir.

1. 1.

   Önce HTTP yanıtını kontrol edin

   Başarılı yanıt verisini okumadan önce başarısız HTTP yanıtlarını işleyin. HTTP isteği hatası ve başarısız bir çözüm görevi ayrı ayrı ele alınmalıdır.

2. 2.

   Oluşturma işleminden dönen görevi inceleyin

   reCAPTCHA oluşturma işlemi varsayılan olarak 15 saniyeye kadar bekler, bu nedenle yanıt zaten son durumda olabilir. Yalnızca ready kullanılabilir bir çözüm içerir. Görev pending veya solving durumundaysa döndürülen solvethree görev kimliğini kullanarak alın.

3. 3.

   Hazır veya başarısız durumunda sorgulamayı durdurun

   ready durumunda çözümü gönderim kodunuza aktarın. failed durumunda errorCode ve error değerlerini inceleyin ve o görevi sorgulamayı durdurun. Başarısız çözümlerin ücreti iade edilir. Değiştirilmemiş geçersiz girdilerle körü körüne yeniden denemeyin veya her başarısızlığın yetersiz kredi anlamına geldiğini varsaymayın.

Aşamalı geçiş sırasında her görev kimliğini sağlayıcısıyla etiketleyin. Mevcut CapSolver görevlerini CapSolver üzerinden tamamlayın ve yeni solvethree görevlerini solvethree üzerinden yönlendirin. Eski sağlayıcının görev kimliğini yeni API’ye göndermek yerine sonuçlarını adaptörünüzde ortak bir biçime dönüştürün.

reCAPTCHA sonucunu amaçlanan hedefe gönderirken solution.token kullanın. Döndürülen userAgent ve secChUa değerlerini de saklayın ve gönderim için başarılı proxy’yi kullanın. Mevcut adaptörünüz yalnızca bir token dizesi döndürüyorsa bu bilgileri gönderimi yapan istemciye aktaracak şekilde değiştirin.

Hazır bir token reddedilirse başka bir çözüm için ödeme yapmadan önce giden uygulama isteğini inceleyin. İsteğin bir görev kimliği veya eski token değil, yeni token içerdiğini ve gönderimin döndürülen tarayıcı kimliğini, başarılı proxy’yi ve amaçlanan hedef URL’yi kullandığını kontrol edin. ready durumundaki bir görev, çözümün üretildiği anlamına gelir; hedefin sonraki isteğinizi kabul ettiği anlamına gelmez.

Geçiş sonrası örnek, kurtarma için requestId içerir. Her yeni mantıksal görev için bir değer üretin ve bunu istek girdilerinin aynısıyla birlikte saklayın. 1–64 ASCII harfi, rakam, alt çizgi veya kısa çizgi içermelidir. Aynı görev isteğiyle yeniden kullanılması mevcut görevi döndürür; farklı girdilerle kullanılması çakışmaya yol açar.

Oluşturma zaman aşımına uğrarsa kimliğiniz varsa görevi alın veya aynı gövdeyi aynı requestId ile yeniden gönderin. Yanıtın kaybolması, oluşturmanın başarısız olduğunu kanıtlamaz. Yalnızca istemciniz beklemeyi bıraktı diye yeni bir kimlik üretmeyin.

İstemcinizin zaman aşımında reCAPTCHA’nın varsayılan olarak 15 saniyeye kadar süren oluşturma beklemesine ve ağ ek yüküne pay bırakın. GET sorgulaması varsayılan olarak beklemeden döner ve 15000 değerine kadar waitMs kabul eder. waitMs değerini görev JSON’una değil, URL sorgusuna koyun ve sorgulama zaman aşımında da bu beklemeye pay bırakın.