ERROR_WRONG_USER_KEY ve 3 İstek Hatası Nasıl Düzeltilir

error_wrong_user_key, API anahtarınızın kodunuzdan hiç çıkmadığı anlamına gelir. Teşhisin tamamı bu ve bunu en baştan söylemekte fayda var, çünkü neredeyse herkes bunu “anahtarım yanlış” diye okuyup yeni bir anahtar yapıştırmaya başlıyor. CapSkip’in, yanlış olan bir anahtar için ayrı bir kodu var. error_wrong_user_key ve yanındaki üç kod, çözücü daha bir CAPTCHA’ya hiç bakmadan önce döner: gönderdiğiniz HTTP isteğinin biçimini tarif ederler, isteğin ilgili olduğu doğrulamayı değil.
Dört kod ve onlarla karıştırılan kod
Bunlar, gönderim uç noktasından veya yoklama uç noktasından, her zamanki OK yanıtı yerine düz metin olarak geri gelir. Hepsi deterministiktir. Aynı isteği yeniden denemek aynı yanıtı üretir; yani bunlardan herhangi birinin etrafına yeniden deneme döngüsü kurmak boşa harcanmış zamandır. Aşağıdaki ikinci satır, bu dörtten biri olmayan kardeş koddur; çünkü işin büyük kısmı bu ikisini birbirinden ayırmaktır.
| Kod | Resmî anlamı | Pratikte ne anlama geliyor |
|---|---|---|
| ERROR_WRONG_USER_KEY | API anahtarı eksik veya boş | key parametresi yoktu ya da vardı ama değeri boştu |
| ERROR_KEY_DOES_NOT_EXIST | Geçersiz API anahtarı | Bir anahtar ulaştı ama CapSkip onu tanımıyor |
| ERROR_WRONG_METHOD | Geçersiz HTTP metodu veya action parametresi | method değeri CapSkip’in bildiklerinden biri değil ya da action değeri get değil |
| ERROR_WRONG_ID_FORMAT | Geçersiz captcha ID biçimi | Yoklamada kullandığınız id yalın bir sayı değil |
| ERROR_BAD_PARAMETERS | Eksik ya da geçersiz zorunlu parametreler | O CAPTCHA türü için gerekli bir alan eksik ya da hatalı biçimlendirilmiş |
Görsel yükleme kodları ve reCAPTCHA’ya özgü olanlar dahil tam liste şurada: CapSkip API dokümantasyonu.
ERROR_WRONG_USER_KEY: anahtar yanlış değil, hiç yok
Eksik olmak ile geçersiz olmak, iki farklı çözümü olan iki farklı hatadır ve CapSkip bunları bilerek ayırır. Bir anahtar sunucuya ulaştı ama tanınmadıysa error_key_does_not_exist alırsınız; bu da şurada anlatılıyor: o kodun kılavuzu. Bunun yerine error_wrong_user_key alıyorsanız, tanınabilir hiçbir şey ulaşmamış demektir; o hâlde değere bakmayı bırakın ve anahtarın gönderilip gönderilmediğine bakmaya başlayın.
# No key parameter at all. This is what produces it. curl -X POST \ -d "method=userrecaptcha" \ -d "googlekey=YOUR_SITEKEY" \ -d "pageurl=https://example.com/page-with-recaptcha" \ http://127.0.0.1:8080/in.php ERROR_WRONG_USER_KEY
Buna dört şey yol açar; kabaca ne sıklıkta yol açtıklarına göre sıralanmış hâlde:
- Kodun çalıştığı yerde tanımlı olmayan bir ortam değişkeni. Bir kabukta var olup bir serviste olmaması, bunun klasik hâlidir. Değer boş bir metin olarak okunur ve istemci, key parametresini arkasında hiçbir şey olmadan gönderir.
- Kodun yanında dağıtılmamış bir yapılandırma dosyasından okunan bir anahtar.
- key parametresini yalnızca bir değişken doluysa ekleyen, elle yazılmış bir istemci: boş bir metin, parametreyi sessizce düşürür.
- Parametreleri, isteğin onları taşımayacağı bir yere koyan bir istemci; örneğin form alanlarını okuyan bir uç noktada JSON gövdesi kullanmak.
Çağrıdan önce değerin kendisini değil, uzunluğunu yazdırın. Sıfır uzunluk size gereken bilgiyi verir ve bir kimlik bilgisini log dosyasına düşürmez.
Bu neden yalnızca bir sunucuda başlıyor
Aynı kodu aylardır çalıştıran insanların kafasını karıştıran kısım burası. CapSkip anahtarı yalnızca uygulamada API Key Validation açıkken ister. Yeni bir yerel kurulumda bu kapalıdır; yani hiç anahtar içermeyen bir istek kabul edilir ve hiçbir zaman kimse şikâyet etmez. İstemciniz, onu yazdığınız günden beri boş bir anahtar gönderiyor olabilir.
Sonra çözücüyü masanızda olmayan bir makineye taşırsınız. CapSkip’in iki bağlantı modu var: Local, 127.0.0.1 adresine bağlanır ve yalnızca o cihaza yanıt verir; Server ise ağınıza veya genel IP’nize bağlanır, böylece başka bir makine, bir VPS ya da barındırılan bir worker ona API üzerinden ulaşabilir. Statik bir genel IP, adresi sabit tutar. İkisi de şurada anlatılıyor: bağlantı ayarları. Bu adımı atarken anahtar doğrulamasını açmak doğru olan şeydir; bu aynı zamanda kodunuzdaki her gizli anahtar hatasının bir anda yüzeye çıktığı andır. Her iki durumda da bu hâlâ sizin donanımınız ve kullanım hâlâ ölçülmez; yani bu bir yapılandırma değişikliğidir, ödediğiniz tutarda bir değişiklik değil.
Anahtarları birkaç worker’a dağıtıyorsanız, her birine kendi anahtarını verin ki tek bir anahtar, diğerlerine dokunmadan iptal edilebilsin. İşin o tarafı şurada ele alınıyor: CAPTCHA API anahtarları oluşturma kılavuzu.
ERROR_WRONG_ID_FORMAT: muhtemelen yanıtın tamamını gönderdiniz
Bunun tek bir baskın nedeni var ve bir kez öğrendikten sonra fark etmesi kolay. Gönderim uç noktası yalın bir sayıyla yanıt vermez. OK ile id’yi bir dikey çizgiyle ayırarak yanıt verir; o metni doğrudan yoklama isteğine aktaran bir istemci de sayı olmayan bir id göndermiş olur.
# What in.php actually returns: OK|212 # Wrong. The whole reply went into id. curl "http://127.0.0.1:8080/res.php?key=YOUR_API_KEY&action=get&id=OK|212" ERROR_WRONG_ID_FORMAT # Right. Split on the pipe and send the number. curl "http://127.0.0.1:8080/res.php?key=YOUR_API_KEY&action=get&id=212"
JSON isteyin, ayrıştırma daha az kırılgan olur; çünkü id, ayraçlı bir metnin yarısı olarak değil, bir alan olarak gelir. Her hâlükârda bölmeden önce öneki kontrol edin, çünkü bir hata kodunda dikey çizgi bulunmaz ve körlemesine bölmek size id olarak hata kodunu geri verir.
# A hand rolled client has to do this itself. The SDK does not,
# which is most of why it is worth using.
reply = httpx.post(IN_URL, data=payload).text # "OK|212"
if not reply.startswith("OK|"):
raise RuntimeError(reply) # it is an error code
captcha_id = reply.split("|", 1)[1] # "212"Ham istek ve yoklama döngüsünün, aynı ayraç işlemesini de içeren işlenmiş bir örneği şurada: curl ile CAPTCHA çözme anlatımı.
ERROR_WRONG_METHOD: yanlış fiil ya da yanlış kelime
Bu kodu iki ayrı hata paylaşır; belirsiz görünmesinin nedeni budur. Birincisi HTTP fiilidir: GET ile çağırdığınız bir uç noktaya form gövdesi olarak gönderilen parametreler hiçbir yere ulaşmaz. İkincisi, method parametresinin kendisidir; bu parametrenin, çözdüğünüz tür için CapSkip’in tanıdığı değerlerden biri olması gerekir: görsel için post veya base64, her iki sürümde de reCAPTCHA için userrecaptcha, Cloudflare için turnstile, GeeTest v3 için geetest.
Bunların çoğunu iki yazım hatası oluşturur: reCAPTCHA uç noktası googlekey isterken ona sitekey göndermek ve userrecaptcha yerine recaptcha ya da userecaptcha göndermek. Aynı kod yoklama tarafını da kapsar; orada da action değerinin birebir get metni olması gerekir.
ERROR_BAD_PARAMETERS: tür ile alanlar uyuşmuyor
method anlaşıldı ama onun için gerekli olan bir şey eksikti ya da hatalı biçimlendirilmişti. Bu, türe özgüdür; dolayısıyla yararlı soru her zaman şudur: CapSkip hangi türü sorduğunuzu düşünüyor?
- reCAPTCHA hem googlekey hem pageurl ister; pageurl, widget’ın yüklendiği sayfanın şema dahil tam URL’si olmalıdır.
- reCAPTCHA v3, version değerinin v3 olmasını ister. Bununla birlikte invisible göndermek, bir v3 isteğine v2 alanı koymak demektir.
- Turnstile doğrulama sayfaları, sitekey’in yanı sıra data ve pagedata da ister. Bileşen modunda ikisi de gerekmez.
- GeeTest, gt ile challenge değerlerini birlikte ister; challenge yaklaşık bir dakikada sona erdiği için bayatlamış bir challenge, sonradan değil tam burada başarısız olur.
- Görsel CAPTCHA’lar, multipart yükleme için file ya da base64 için body ister; asla ikisi birden değil.
Göndermek üzere olduğunuz yükü, anahtarı gizleyerek loglayın ve o tür için parametre tablosuyla karşılaştırarak okuyun. On seferin dokuzunda cevap o tek satırda görünür.
Boş yanıt bunlardan biri değildir
Hiçbir şey döndürmeyen bir yoklama farklı bir durumdur ve bunu adıyla anmakta fayda var, çünkü boş bir yanıt bozuk bir id sanılıyor. Boş bir gövde, sonucun zaten alınmış olduğu ya da id’nin mevcut olmadığı anlamına gelir. CapSkip bir sonucu bir kez okumanıza izin verir. Başarılı olan, sonra kodda break unutulduğu için tekrar dönen bir yeniden deneme döngüsü, ikinci seferde boş bir metin okur ve doğru çözülmüş bir CAPTCHA için başarısızlık bildirir.
Sonucu ilk aldığınızda saklayın. Ayrıca boş yanıtı CAPCHA_NOT_READY ile karıştırmayın; o bir hata değil, normal bir yoklama durumudur ve şurada anlatılıyor: o yanıtın kılavuzu.
Bunları SDK üzerinden okumak
Dört kodun her biri, kod mesaj olarak taşınacak şekilde bir ApiException olarak gelir. Önce bu istisnayı kontrol edin, çünkü bu, CapSkip’in sizi anladığı ve reddettiği anlamına gelir; bu da CapSkip’e hiç ulaşamamaktan farklı bir sorun sınıfıdır.
# pip install capskip
from capskip import CapSkip, ApiException, NetworkException
solver = CapSkip(host="127.0.0.1", port=8080, apiKey=API_KEY)
try:
token = solver.recaptcha(sitekey=SITEKEY, url=PAGE_URL)["code"]
except ApiException as err:
# CapSkip answered and rejected the request. Do not retry.
print("Rejected:", err)
except NetworkException as err:
# CapSkip did not answer. Wrong host, wrong port, or not running.
print("Unreachable:", err)ValidationException’ı da burada bilmekte fayda var, çünkü o, hiçbir şey gönderilmeden önce tetiklenir. SDK, sorduğunuz tür için yanlış olan parametreleri reddeder; böylece ham HTTP üzerinde ERROR_BAD_PARAMETERS olarak geri gelecek bir hata, argümanı adıyla anan bir mesajla yerelde yakalanır. SDK’da toplam dört istisna türü var: ApiException, NetworkException, TimeoutException ve ValidationException. Hepsini tek bir yerde ele almayı tercih ederseniz, her biri CapSkipError adlı bir temel sınıftan türer. Aynı dördü Node.js, PHP ve C# istemcilerinde de var; onlar da şurada listeleniyor: CAPTCHA çözme SDK sayfası.
FAQ
ERROR_WRONG_USER_KEY ile ERROR_KEY_DOES_NOT_EXIST arasındaki fark nedir?
Bir anahtarın ulaşıp ulaşmadığı. Birincisi, key parametresinin eksik veya boş olduğu anlamına gelir; o hâlde yapılandırmanıza ve istek oluşturucunuza bakın. İkincisi, bir anahtarın ulaştığı ama CapSkip’in onu tanımadığı anlamına gelir; o hâlde değere ve uygulamanın gerçekte hangi anahtarı verdiğine bakın.
API anahtarına gerçekten ihtiyacım var mı?
Yalnızca CapSkip uygulamasında API Key Validation açıkken. Varsayılan olarak kapalıdır; çözücünün yalnızca loopback’e yanıt verdiği bir makinede bu sorun değildir. Çözücü bir ağ adresini dinlemeye başlamadan önce onu açın ve o andan itibaren bir anahtar gönderin.
Bunlardan herhangi birini yeniden denemeli miyim?
Hayır. Dördü de deterministiktir; yani ikinci deneme tam olarak birincisi gibi başarısız olur. Bunun yerine geçici hataları yeniden deneyin: bir bağlantı hatası, bir yoklama zaman aşımı ya da çözülemez olarak dönen bir CAPTCHA. Hatalı biçimlendirilmiş bir isteği yeniden denemek, yeniden deneme bütçenizi yalnızca bir hataya harcar.
Yerelde her şey çalışıyordu, sunucuda bozuldu. Neden?
Neredeyse her zaman, taşınmayla birlikte anahtar doğrulaması açıldığı ve anahtarın aslında hiçbir zaman gerçekten gönderilmiyor olduğu için. İkinci en yaygın neden, kabuğunuzda var olan ama kodu çalıştıran serviste olmayan bir ortam değişkenidir. Değerin uzunluğunu, çağrının yapıldığı noktada kontrol edin.
Kısa özet
Bu dört kod, CAPTCHA ile değil, sizin isteğinizle ilgilidir. error_wrong_user_key, key parametresine hiçbir şeyin ulaşmadığı anlamına gelir; bu da yanlış bir değerden çok bir yapılandırma sorunudur. ERROR_WRONG_ID_FORMAT neredeyse her zaman, dikey çizgiyle ayrılmış yanıtın olduğu gibi gönderildiği anlamına gelir. ERROR_WRONG_METHOD yanlış bir fiil ya da yanlış bir yazım anlamına gelir, ERROR_BAD_PARAMETERS ise sorduğunuz türe ait olmayan bir alan anlamına gelir. Hiçbiri yeniden denemeye değmez.
Bunların her birini kesin olarak çözen parametre tabloları şurada: API dokümantasyon sayfası. Bunları yanlış yapma fırsatının çoğunu ortadan kaldıran Python istemcisi ise şurada: Python CAPTCHA çözücü sayfası.
Hata ayıklarken hatırlamakta fayda var: CapSkip, kendi donanımınızda çalışan bir captcha atlatma aracı olduğundan, işi çözmeye çalışırken yüz kez gönderdiğiniz hatalı biçimlendirilmiş bir istek size zamandan başka hiçbir şeye mal olmaz.
