حل reCAPTCHA Enterprise باستخدام Python

ثبّت حزمة SDK الرسمية لـ Python:

python -m pip install https://solvethree.com/downloads/solvethree_sdk-0.1.0-py3-none-any.whl

1. 1.

   إنشاء ملف تعريف الموقع

   اضبط اسم المضيف المستهدف في لوحة تحكم solvethree، وتأكد من أن ملف تعريفه نشط ومتاح لمساحة عملك. إرسال اسم مضيف في طلب حل لا ينشئ ملف تعريف. راجع إعداد ملف تعريف الموقع إذا لم تكن قد أعددت واحدًا.

2. 2.

   تعيين SOLVETHREE_API_KEY

   في الصدفة أو بيئة النشر التي ستشغّل السكربت، عيّن SOLVETHREE_API_KEY إلى مفتاح API لمساحة عملك. احتفظ به على الخادم، وليس في كود المتصفح أو ملف مصدر مُودَع في المستودع.

3. 3.

   تعيين SOLVETHREE_PROXY

   عيّن SOLVETHREE_PROXY إلى عنوان URL للوكيل الذي سيستخدمه الحل وطلب التطبيق اللاحق. يستخدم المثال وكيلًا واحدًا، لذا لا تضف proxyCandidates أيضًا.

احفظ هذا المثال باسم solve.py. استبدل accounts.example.com باسم المضيف الذي أعددته، دون مخطط بروتوكول أو مسار، واستبدل login بالإجراء المستخدم في الصفحة المستهدفة.

import os
from uuid import uuid4
from solvethree import Solvethree, SolvethreeError, TaskFailedError

client = Solvethree(os.environ["SOLVETHREE_API_KEY"])
request = {
    "site": "accounts.example.com",  # Use your configured hostname.
    "action": "login",              # Use the page's actual action.
    "proxy": os.environ["SOLVETHREE_PROXY"],
    "requestId": str(uuid4()),
}
try:
    result = client.solve(request, timeout=180)
except TaskFailedError as error:
    raise SystemExit(f"Task failed: {error.error_code}") from None
except SolvethreeError as error:
    # Keep these IDs so an interrupted request can be recovered.
    raise SystemExit(f"Recover request {error.request_id}, task {error.task_id}") from None

solution = result["solution"]
token = solution["token"]
user_agent = solution["userAgent"]
client_hints = solution["secChUa"]
print("Ready task:", result["id"])  # Do not print the token or proxy password.

يستخدم الطلب enterprise-v3 افتراضيًا، لذا لا يحتاج إلى حقل recaptchaType. لا تضف type أو url؛ فهما ليسا من حقول طلب reCAPTCHA.

يعمل Solvethree بشكل متزامن. ينشئ client.solve المهمة مرة واحدة، ثم يستعلم دوريًا حتى يعيد نتيجة جاهزة أو يطرح استثناءً. هنا، يضع timeout=180 حدًا قدره 180 ثانية لانتظار العميل. عند النجاح، يستخرج السكربت الرمز ووكيل المستخدم وتلميحات العميل دون طباعة قيم حساسة.

تابع في السكربت نفسه بعد الحل. ثبّت requests بشكل منفصل كما هو موضح في المثال. استبدل عنوان URL لتسجيل الدخول وبيانات النموذج بطلب تطبيقك الفعلي، بما يشمل أي بيانات اعتماد مطلوبة ورمز CSRF وملفات تعريف ارتباط الجلسة.

# Continue after client.solve(). Install requests separately: pip install requests.
import requests

# This example endpoint accepts the standard reCAPTCHA form field.
# Use your application's real URL, form fields, CSRF token and session.
response = requests.post(
    "https://accounts.example.com/login",
    data={"g-recaptcha-response": solution["token"]},
    headers={
        "User-Agent": solution["userAgent"],
        "sec-ch-ua": solution["secChUa"],
    },
    proxies={"http": request["proxy"], "https": request["proxy"]},
    timeout=30,
    allow_redirects=False,
)
# Inspect the application's response to determine whether it accepted the request.
print("Application HTTP status:", response.status_code)

يفترض هذا المثال أن التطبيق يقبل الرمز في g-recaptcha-response. تحقّق من الطلب الفعلي بدلًا من افتراض اسم الحقل هذا. إذا كان النموذج يعتمد على جلسة قائمة، فأرسله عبر تلك الجلسة بدلًا من إنشاء طلب جديد بلا ملفات تعريف ارتباط.

احتفظ بقيمتَي userAgent وsecChUa المُعادتين، واستخدم الوكيل نفسه الذي قدّمته للحل. قد يؤدي تبديل عناوين IP أو استبدال هوية المتصفح بأخرى غير مرتبطة إلى فشل الطلب.

تعني المهمة الجاهزة أن حلًا قد أُنشئ، وليس أن التطبيق قبله. افحص استجابة التطبيق والجلسة الناتجة؛ فرمز حالة HTTP وحده لا يثبت نجاح تسجيل الدخول. إذا رفض التطبيق الرمز، فتحقّق من الطلب الصادر قبل الدفع مقابل حل آخر: يجب أن يتضمن solution.token، لا معرّف المهمة ولا رمزًا قديمًا. راجع تشخيص رفض الرمز.

يُنشئ المثال requestId جديدًا في كل مرة يبدأ فيها السكربت. احفظ هذا المعرّف والطلب الأصلي قبل استدعاء solve إذا كنت بحاجة إلى الاستئناف بعد إعادة تشغيل العملية. مجرد إعادة تشغيل السكربت ينشئ طلبًا منطقيًا جديدًا.

• إذا تضمّن الاستثناء task_id، فاستخدم get_task لاستئناف الاستعلام الدوري عن تلك المهمة. لا تنشئ مهمة بديلة لمجرد انتهاء مهلة الاتصال.
• إذا انقطع الإنشاء ولم يكن لديك سوى request_id، فأعد إرسال طلب المهمة المطابق باستخدام requestId نفسه. سيعيد المهمة الموجودة؛ أما تغيير مدخلات المهمة مع إعادة استخدام المعرّف فيؤدي إلى تعارض.
• عند حدوث TaskFailedError، أوقف الاستعلام الدوري عن تلك المهمة. افحص errorCode وerror قبل إعادة المحاولة؛ فلن يُصلح حل آخر المدخلات غير الصالحة ما لم تتغير. تُسترد تكلفة عمليات الحل الفاشلة.

لا تعيد حزمة SDK محاولة إنشاء المهمة تلقائيًا. لكنها تلتزم بـ Retry-After عند حدوث إخفاقات مؤقتة في الاستعلام الدوري ضمن المهلة النهائية للحل. لمزيد من التحكم في الانتظار والاستئناف، راجع الاستعلام الدوري عن المهام والمهل الزمنية.