Görev hazır. reCAPTCHA token'ı neden reddediliyor?

{
  "id": "example-task",
  "status": "ready",
  "solution": {
    "token": "EXAMPLE_TOKEN",
    "userAgent": "EXAMPLE_USER_AGENT",
    "secChUa": "EXAMPLE_CLIENT_HINTS"
  }
}

Bu örnekte solution.token, hedefin reCAPTCHA token'ını beklediği yere gönderilecek değerdir. id, solvethree görevini tanımlar; token değildir. Çözüm nesnesinin tamamını da göndermeyin.

Yalnızca yanıtı tutan değişkeni değil, gönderilen son isteği inceleyin. Boş bir değer veya formda kalmış eski bir token yerine güncel token'ı içerdiğini kontrol edin. Token'ları paylaşılan günlüklere kaydetmeyin.

Gönderilen token doğru, ancak hedef yine de reddediyor.

Görevin site ana makine adını, korunan isteğin ana makine adıyla karşılaştırın. Farklı bir alt alan adı veya ortam olup olmadığını kontrol edin.

Şunu deneyin: Token'ı amaçlanan ana makine adı için isteyin ve o hedefe gönderin. Hedef sitenin çalışma alanınızın erişebildiği etkin bir profili olmalıdır.

Bir etkileşim için istenen token başka bir etkileşim için kullanılıyor.

Görevin action değerini, bu korumalı istek için beklenen tam action değeriyle karşılaştırın.

Şunu deneyin: Gönderdiğiniz etkileşimle ilişkili action değerini kullanın.

Entegrasyon yanlış reCAPTCHA varyantını kullanıyor.

Görev isteğindeki recaptchaType alanını inceleyin. Varsayılan değeri enterprise-v3'tür; ağ geçidi v3 değerini de kabul eder.

Şunu deneyin: Hedefin ürününü açıkça eşleştirin. Enterprise v3 için enterprise-v3 kullanın.

Hem klasik reCAPTCHA hem de reCAPTCHA Enterprise web sitesi yanıt token'larının süresi iki dakika sonra dolar ve bu token'lar tek kullanımlıktır. Klasik token'lar bir kez doğrulanabilir; Enterprise token'ları bir kez değerlendirilebilir. Hazır token stoğu tutmak yerine, çözümlemeyi korumalı isteğin hemen öncesinde yapın.

• Gönderim gecikmeli yapılıyorsa çözümleme ile token'ın gönderilmesi arasında ne kadar süre geçtiğini kontrol edin.
• Token zaten doğrulandıysa veya değerlendirildiyse başka bir gönderim için yeniden kullanmayın.
• Token'ı hedefe göndermeden önce sırf test etmek için ayrı bir doğrulama veya Enterprise değerlendirmesi çalıştırmayın. Bu test, token'ın tek kullanım hakkını tüketebilir.

Çözümleme başarılı oluyor ancak gönderimde başka bir bağlantı kullanılıyor.

Çözümlemede başarılı olan proxy ile korumalı istekte kullanılan proxy'yi karşılaştırın. proxyCandidates sağladıysanız ilk adayın başarılı olduğunu varsaymayın.

Şunu deneyin: Başarılı proxy üzerinden gönderin. Çözümleme ile gönderim arasında IP değiştirmek isteğin başarısız olmasına neden olabilir.

Gönderimi yapan istemci kendi varsayılan tarayıcı başlıklarını kullanıyor.

Giden User-Agent ve Sec-CH-UA değerlerini solution.userAgent ve solution.secChUa ile karşılaştırın.

Şunu deneyin: Döndürülen tarayıcı kimliğini başarılı proxy ile birlikte kullanın. Token'ı ilgisiz user-agent veya client-hint değerleriyle birleştirmeyin.

Hedefin HTTP durumunun yanı sıra yanıt gövdesini de inceleyin. Tek başına 403, isteği hangi korumanın reddettiğini göstermez. Başka bir token istemeden önce açık bir token hatası veya ana makine adı/action uyuşmazlığı arayın.

Doğrulama ayrıntıları mevcutsa klasik reCAPTCHA'nın success sonucunu ve döndürülen bağlam/hata bilgilerini kontrol edin. Enterprise için token geçerliliğini ve ilgili değerlendirme nedenlerini inceleyin. Puanın tek başına reddi açıkladığını varsaymayın: değerlendirmenin nasıl kullanılacağına web sitesi karar verir.

Nedeni hâlâ belirleyemiyorsanız görev kimliği, kullanıldıysa requestId, ürün, zaman damgası, hedef ana makine adı/action değeri, HTTP durumu veya görev hatası ve hassas bilgilerden arındırılmış yanıt açıklamasıyla [email protected] adresine başvurun. API anahtarlarını, proxy parolalarını, token'ları, çerezleri ve müşteri verilerini kaldırın.