Ruby से reCAPTCHA Enterprise हल करें

1. 1.

   साइट प्रोफ़ाइल सक्रिय करें

   solvethree कंसोल में लक्ष्य होस्टनाम सेट करें और सुनिश्चित करें कि उसकी प्रोफ़ाइल आपके वर्कस्पेस के लिए सक्रिय है। होस्टनाम और ऐक्शन भेजने से प्रोफ़ाइल नहीं बनती। साइट प्रोफ़ाइल सेटअप देखें।

2. 2.

   एनवायरनमेंट वेरिएबल सेट करें

   SOLVETHREE_API_KEY को अपने वर्कस्पेस की API कुंजी पर और SOLVETHREE_PROXY को उस HTTP या HTTPS प्रॉक्सी URL पर सेट करें जिसका उपयोग आप लक्ष्य को टोकन सबमिट करते समय भी करेंगे। कुंजी सर्वर पर रखें।

3. 3.

   उदाहरण के इनपुट बदलें

   accounts.example.com को लक्ष्य होस्टनाम से बदलें—पूरे URL से नहीं—और login को उस लक्ष्य के लिए आवश्यक ऐक्शन से बदलें। अनुरोध एक proxy का उपयोग करता है; साथ में proxyCandidates न जोड़ें। type और url को शामिल न करें। recaptchaType छोड़ने पर डिफ़ॉल्ट enterprise-v3 चुना जाता है।

उदाहरण को solve.rb के रूप में सहेजें और वे वेरिएबल सेट करने के बाद Ruby से चलाएँ। यह net/http, json और securerandom लोड करता है; JSON अनुरोध बॉडी और API प्रतिक्रियाएँ सँभालता है।

require 'net/http'
require 'json'
require 'securerandom'

api = 'https://api.solvethree.com/v1'
input = {site: 'accounts.example.com', action: 'login', proxy: ENV.fetch('SOLVETHREE_PROXY'), requestId: SecureRandom.uuid}
deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + 180
call = lambda do |method, path, body = nil|
  remaining = deadline - Process.clock_gettime(Process::CLOCK_MONOTONIC)
  raise 'Local deadline reached' if remaining <= 0
  uri = URI(api + path)
  request = method == :post ? Net::HTTP::Post.new(uri) : Net::HTTP::Get.new(uri)
  request['Authorization'] = 'Bearer ' + ENV.fetch('SOLVETHREE_API_KEY')
  request['Accept'] = 'application/json'
  if body
    request['Content-Type'] = 'application/json'
    request.body = JSON.generate(body)
  end
  # Net::HTTP's own proxy configuration is separate from input[:proxy].
  http = Net::HTTP.new(uri.hostname, uri.port, nil)
  http.use_ssl = uri.scheme == 'https'
  http.open_timeout = [10, remaining].min
  http.read_timeout = [25, remaining].min
  http.write_timeout = [25, remaining].min
  http.max_retries = 0
  response = http.request(request)
  raise "API HTTP #{response.code}" unless response.is_a?(Net::HTTPSuccess)
  JSON.parse(response.body)
end

task_id = nil
begin
  result = call.call(:post, '/tasks?waitMs=0', input)
  task_id = result.fetch('id')
  while %w[pending solving].include?(result.fetch('status'))
    result = call.call(:get, '/tasks/' + URI.encode_www_form_component(task_id) + '?waitMs=15000')
    sleep(1) if %w[pending solving].include?(result.fetch('status'))
  end
  raise "Task failed: #{result['errorCode']}" unless result['status'] == 'ready'
  puts "Ready task: #{task_id}"
  # Submit result['solution']['token'] with its userAgent/secChUa and original proxy.
rescue StandardError => error
  warn "Recovery requestId=#{input[:requestId]} taskId=#{task_id || 'unknown'}"
  raise error
end

स्क्रिप्ट निर्माण का एक अनुरोध भेजती है, लौटाई गई टास्क ID सहेजती है और जब तक उसका स्टेटस pending या solving रहता है, उस टास्क को प्राप्त करती रहती है। केवल ready उपयोग योग्य समाधान देता है। किसी भी प्रतिक्रिया की बॉडी को सफलता पेलोड के रूप में पार्स करने से पहले उसका HTTP स्टेटस सफल होना चाहिए।

HTTPS को स्पष्ट रूप से सक्षम किया गया है। स्वचालित पुनः प्रयास बंद हैं और रीडायरेक्ट का अनुसरण करने के बजाय HTTP स्टेटस जाँच उन्हें अस्वीकार करती है। टास्क बॉडी की प्रॉक्सी समाधान के लिए है; यह Ruby से solvethree API तक के कनेक्शन को कॉन्फ़िगर नहीं करती।

साझा मोनोटोनिक समय-सीमा पोलिंग को 180-सेकंड का स्थानीय समय देती है। हर अनुरोध शुरू होने पर शेष समय के अनुसार कनेक्शन, रीड और राइट टाइमआउट सीमित किए जाते हैं। इसे पोलिंग की सीमा मानें, जारी अनुरोध को रद्द करने वाला सख्त टाइमर नहीं। Ruby Net::HTTP दस्तावेज़ अलग-अलग टाइमआउट सेटिंग का वर्णन करते हैं।

उदाहरण तैयार टास्क की ID प्रिंट करता है, टोकन नहीं। तैयार परिणाम से solution.token पढ़ें और उसे लक्ष्य अनुरोध के अपेक्षित टोकन फ़ील्ड में रखें। उसकी जगह टास्क ID न भेजें।

User-Agent हेडर के लिए लौटाए गए solution.userAgent और Sec-CH-UA के लिए solution.secChUa का उपयोग करें। इस टास्क को दी गई उसी प्रॉक्सी से, निर्धारित लक्ष्य को सबमिट करें। लौटाई गई पहचान को किसी असंबंधित ब्राउज़र के हेडर से न बदलें।

तैयार टास्क का मतलब है कि solvethree ने समाधान बना दिया है। उसने आपका एप्लिकेशन अनुरोध स्वीकार किया या नहीं, यह जानने के लिए लक्ष्य की प्रतिक्रिया अलग से जाँचें।

स्क्रिप्ट API HTTP त्रुटि उत्पन्न करती है।

असफल HTTP प्रतिक्रिया की जाँच करें। यह अनुरोध-स्तर की त्रुटि है, टास्क का अंतिम परिणाम नहीं।

यह आज़माएँ: दोबारा प्रयास करने से पहले उस प्रतिक्रिया का निदान करें। बिना बदले अमान्य इनपुट बार-बार सबमिट न करें।

टास्क failed स्टेटस पर पहुँचता है।

परिणाम में errorCode और error, दोनों की जाँच करें। उदाहरण के त्रुटि संदेश में केवल errorCode शामिल है।

यह आज़माएँ: उस टास्क को पोल करना बंद करें और बताए गए कारण को ठीक करें। विफल समाधानों का शुल्क वापस किया जाता है; विफलता का मतलब हमेशा अपर्याप्त क्रेडिट नहीं होता।

टास्क ID मिलने से पहले निर्माण का समय समाप्त हो जाता है।

मानक त्रुटि आउटपुट में लिखी गई रिकवरी requestId सुरक्षित रखें। टाइमआउट से यह साबित नहीं होता कि निर्माण विफल हुआ।

यह आज़माएँ: उसी अनुरोध ID के साथ हूबहू वही टास्क अनुरोध सबमिट करके रिकवरी करें। स्क्रिप्ट को बस दोबारा न चलाएँ: नए रन में नई ID बनती है और एक और टास्क बन सकता है।

पोलिंग स्थानीय समय-सीमा तक पहुँच जाती है या उसका कनेक्शन टूट जाता है।

लॉग की गई टास्क ID और अनुरोध ID सुरक्षित रखें।

यह आज़माएँ: दूसरा टास्क बनाने से पहले ज्ञात टास्क ID वाला टास्क प्राप्त करें। स्थानीय एक्सेप्शन टास्क का अंतिम स्टेटस नहीं है।

प्रोसेस रीस्टार्ट के बाद रिकवरी के लिए, POST भेजने से पहले अनुरोध ID और मूल टास्क इनपुट सुरक्षित रखें, फिर टास्क ID लौटने पर उसे भी सुरक्षित रखें। समान इनपुट के साथ अनुरोध ID का दोबारा उपयोग करने पर मौजूदा टास्क लौटता है; उसी ID को रखते हुए इनपुट बदलने पर टकराव होता है। निदान के अगले चरण के लिए API त्रुटि हैंडलिंग देखें।