n8n'den CAPTCHA çözüm API'sini çağırın

1. 1.

   Site profilini etkinleştirin

   Hedef ana makine adını solvethree konsolunda yapılandırın ve profilinin çalışma alanınız için etkin olduğundan emin olun. Bir görevde ana makine adı ve eylem göndermek profili oluşturmaz.

2. 2.

   n8n’de bir Header Auth kimlik bilgisi oluşturun

   Değeri Bearer ve ardından çalışma alanınızın API anahtarı olacak şekilde bir Authorization başlığı göndermesini sağlayın. Anahtarı görev JSON’unda değil, kimlik bilgisinde saklayın.

HTTP Request düğümünü Create task olarak adlandırın. Sorgulama düğümü, ilk görev kimliğini almak için bu adı referans alacaktır.

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

site, action ve proxy değerlerini isteğinizin ana makine adı, eylemi ve proxy’siyle değiştirin. proxy veya proxyCandidates alanlarından tam olarak birini gönderin; bu örnekte tek bir proxy kullanılır. type veya url eklemeyin. Varsayılan reCAPTCHA türü Enterprise v3’tür.

Örnekteki requestId değerini her yeni mantıksal görev için benzersiz bir değerle değiştirin. Zaman aşımından sonra bu görevi kurtarmanız gerekirse değeri değiştirmeyin. 1–64 ASCII harfi, rakam, alt çizgi veya kısa çizgi kabul eder.

waitMs, JSON gövdesinde değil URL sorgusunda yer almalıdır. Ağ ek yüküne pay bırakmak için HTTP isteği zaman aşımını, istenen 15 saniyelik bekleme süresinin üzerinde ayarlayın; 30 saniye makul bir başlangıç ayarıdır, çözüm süresi garantisi değildir. Header Auth kimlik bilgisi kimlik doğrulamayı sağladığından, bunu Başlıkları Gönder altında tekrar eklemeniz gerekmez.

Görev verisini incelemeden önce başarısız HTTP yanıtlarını işleyin. Başarılı bir yanıt için bir IF veya Switch düğümü bağlayın ve {{ $json.status }} değerini inceleyin.

Hazır durumdaki bir reCAPTCHA görevi için döndürülen token’ı, döndürülen userAgent ve secChUa kimliğiyle ve başarılı olan proxy üzerinden gönderin. Hazır durumdaki bir görev, çözümün üretildiği anlamına gelir; web sitesinin sonraki isteği kabul ettiğini göstermez.

Başarısız çözümlerin ücreti iade edilir. Girdileri değiştirmeden yeniden denemek veya çalışma alanının kredisinin yetersiz olduğunu varsaymak yerine bildirilen hatayı teşhis edin.

1. 1.

   Sabit bir son zaman sınırı kaydedin

   Create task çalışmadan önce iş akışında sorgulama için bir son zaman sınırı saklayın; örneğin oluşturmanın başlamasından iki dakika sonrası. Bu, iş akışınızın durdurma politikasıdır, solvethree API sınırı değildir. Sonraki yanıtların üzerine yazmaması için bu sınırı HTTP yanıtının dışında tutun.

2. 2.

   Her sorgulama adımını koşula bağlayın

   Beklemede veya çözülüyor durumlarında, geçerli zamanı kaydedilen son zaman sınırıyla karşılaştırmak için bir IF düğümü kullanın. Süre dolmuşsa döngüyü sonlandırın ve görev kimliğini saklayın. Aksi hâlde bir Wait düğümüyle iki saniye bekleyin, ardından GET öncesinde zaman sınırını tekrar kontrol edin.

3. 3.

   Mevcut görevi alın

   İkinci bir HTTP Request düğümünü aşağıdaki ayarlarla yapılandırın. Yanıtını aynı durum dalına geri yönlendirin. Sorgulama dalını asla Create task düğümüne geri yönlendirmeyin.

Görev kimliği ifadesi {{ $('Create task').item.json.id }} şeklindedir. En son öğe bir sorgulama yanıtı veya başka iş akışı verileri içerse bile id değerini adı belirtilen oluşturma düğümünden okur. İfadedeki düğüm adını iş akışınızla tutarlı tutun.

GET, 15 saniyeye kadar beklemeyi kabul eder. Bu HTTP isteğine oluşturma isteğiyle aynı zaman aşımı payını tanıyın. Son zaman sınırı yeni sorgulama girişimlerini durdurur; zaten çalışmakta olan bir istek bu sınırdan sonra tamamlanabilir.

n8n dışındaki eşdeğer GET isteği şöyledir:

curl --fail-with-body --max-time 30 \
  "https://api.solvethree.com/v1/tasks/$TASK_ID?waitMs=15000" \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY"

Bağlantı zaman aşımı, oluşturmanın başarısız olduğunu kanıtlamaz. Bir kimlik aldıysanız o görevi alın. Almadıysanız mevcut görevi kurtarmak için POST isteğini aynı görev girdileri ve aynı requestId ile tekrarlayın. Bu kimliği farklı görev girdileriyle yeniden kullanmak çakışmaya neden olur.

Benzer şekilde, sorgulama için belirlediğiniz son zaman sınırına ulaşılması yerel bir durdurma koşuludur, başarısız görev durumu değildir. Sonraki bir çalıştırmada başka bir çözüm için ödeme yapmak yerine görevi alabilmek için ilk kimliği saklayın.