أبرز النقاط
تتيح العديد من المواقع صفحتها الرئيسية للجميع ولكنها تحظر كل شيء بعد نقرة واحدة أعمق. يتعامل Auto مع هذا الأمر الآن: فهو يأخذ session التي تمنحها صفحة الدخول، ثم يطلب الصفحة التي أردتها وهو يحملها. نال Browser النصيب الأكبر من العمل هذا الأسبوع. فهو يكمل التحقق من مربع الاختيار للموقع عند وصول عدة requests إلى نفس الصفحة في وقت واحد، وعندما تظل الصفحة مغلقة، فإنه يُبلغ عما رآه بدلا من كلمة واحدة عامة.
ما الجديد
Auto يفتح الصفحات المحمية خلف session
ترفض صفحة إعلان eBay أي request جديد بارد على كل مسار لدينا. ولكن يفتح نفس الرابط URL عندما يحمل الـ request ملفات cookie التي تقدمها صفحة دخول eBay لأي زائر. لا يلزم تسجيل دخول، ولا حساب مستعار، ولا أي شيء لا يمكنك فعله يدويا في علامة تبويب.
يقوم Auto بذلك نيابة عنك الآن. عندما يصل exit إلى origin ويستمر رفض الصفحة العميقة، يجلب Auto جذر الموقع من خلال نفس الـ exit، ويحتفظ بأي cookies تعود، ثم يكرر الطلب. وتخبرك الـ response بحدوث ذلك: تعرض الدرجة الفائزة warmup.
لكن التكلفة هي الجزء الأكثر أهمية. تأتي هذه الـ session قابلة للنقل، لذا فإن ملفات الـ cookie لا تكون مقيدة بالـ exit الذي حصل عليها. وتتم عمليات القراءة اللاحقة عبر /api/proxy وتصل إلى /api/single مقابل 2 credits. إنها نفس سلسلة التصعيد ثم إعادة التشغيل التي كتبنا عنها لتجاوز Cloudflare clearance، مع استخدام session cookies الخاصة بالموقع كبديل لـ cf_clearance.
هذا محدد بقصد: محاولتان لكل request، على exits مختلفة، فقط بعد فشل الـ URL العميق بالفعل، وفقط عندما يكون الـ exit قد وصل إلى الـ origin في المقام الأول. وبالتالي، فإن الموقع الذي يحظرنا ببساطة يتكلف استدعاءين فرعيين إضافيين لمرة واحدة، وليس حلقة تكرار لا نهائية. المزيد عن كيفية اختيار السلم لدرجاته في المقال المخصص لـ Auto.
Browser يتجاوز تحديات مربعات الاختيار عند تداخل الـ requests
يكمل Browser الآن التحقق من مربع الاختيار على الـ requests المتزامنة لنفس الصفحة. ثلاثة في وقت واحد على موقع إخباري محمي بواسطة Turnstile: 5.2 ثانية، 5.8 ثانية، 9.1 ثانية.
أجرينا تغييرين أصغر أيضا. لا تُحسب النقرة إلا بعد اختفاء الـ widget فعليا، لأن Cloudflare تعيد إصدار التحدي بمعدل أكبر مما تتوقع (النقرة الأولى غالبا لا تكون نهاية الأمر). والصفحة التي يتم تجاوزها تُبلغ عن defenseSolved: true في الـ call الذي تجاوزها، وهو نفس الـ call الذي تُحسب تكلفته للحل.
الصفحة المحظورة توضح لك ما رآه الـ solver
تشير رسالة "Timeout" إلى مشكلة في زمن الاستجابة. ولكن في معظم الأحيان لا يكون زمن الاستجابة هو المشكلة، ويكون الحل مجرد exit آخر.
عندما ترفض خدمة التحقق محاولة ما، فإنها تعيد إصدار التحقق وتضع علامة إعادة المحاولة الخاصة بها داخل الـ jar. يقرأ Browser تلك العلامة. وبدلا من انتظار انتهاء المهلة، يجيب في غضون 17 ثانية تقريبا، محددا المزود، والنقرات التي قام بها، وما إذا كان قد تم منح تصريح التجاوز:
Timeout after 12s: the cloudflare challenge did not complete from this exit
(2 checkbox presses, clearance granted, challenge re-issued by the site)
يوضح لك أحد هذين السطرين ضرورة إرسال الـ request بطريقة مختلفة. بينما لا يخبرك الآخر بأي شيء.
أصبحت أخطاء طبقة الـ API أكثر وضوحا أيضا. فالـ request الذي يتجاوز مدة الانتظار يعود كـ timeout، والخدمة التي يتعذر الوصول إليها تعود كـ unavailable، ولا يوصف أي منهما بأنه مشكلة proxy عندما لا يتضمن الـ request أي proxy من الأساس. يتم الالتزام بـ timeout_ms في استدعاء Browser حتى الحد الأقصى البالغ 120 ثانية الذي يقبله الـ API، بحيث يحصل الهدف البطيء على الوقت المحدد الذي عينته وتقرأ قرار المحرك نفسه بدلا من قرار البوابة. المعلمات مدرجة في API reference.
تفاصيل الفوترة، وتصحيح الفاتورة خلال شهر إصدارها
تتضمن الفواتير البلغارية اسم ممثل الشركة (MOL) في خانة المستلم. لم يكن النظام يجمع هذه البيانات سابقا، لذا كان هذا السطر يظهر فارغا دائما. يحتوي قسم تفاصيل الفوترة على هذا الحقل الآن.
يوفر جدول Invoices أيضا خيار Update details لأي فاتورة لا تزال ضمن شهر إصدارها وتختلف بياناتها المحفوظة عن ملف الفوترة الحالي الخاص بك. يحدد مربع الحوار كل حقل يتغير والقيمة الجديدة له، ويوضح بدقة أن الرقم والتواريخ والمبالغ تظل كما هي دون تغيير، ويعد تأكيدك بمثابة موافقة مسجلة من جانبنا. تظهر الفاتورة الموجودة ضمن هذه الفترة والتي لا تتطلب أي تعديل عبارة "Editable until" متبوعة بالتاريخ، لتكون الفترة الزمنية واضحة أمامك بدلا من معرفتها لاحقا.
خلف الكواليس
يتم تقديم كل script تشغله Dashboard من النطاق الخاص بنا مباشرة، وتسجيل الدخول يعيدك فقط إلى مسار داخل هذا الموقع.
تتم عمليات نشر خدمة التقديم (rendering service) خادما تلو الآخر، ويجب على كل خادم تقديم صفحة فعلية بنجاح قبل الانتقال إلى الخادم التالي.
في بوابة الحالة، يقدم الـ endpoint الخاص بالمشكلات العناصر المفتوحة والتي تم حلها عبر الـ API العام، بما يطابق تماما ما تعرضه الصفحة.
الرفض الذي يحدد سببه بوضوح يستهلك استدعاء واحدا. أما الانتظار الذي ينتهي بـ "Timeout" فيتركك تخمن الخطوة التالية، مع دفع نفس التكلفة. الأخطاء هي جزء أساسي من تجربة المنتج، وبدأنا هذا الأسبوع التعامل معها على هذا الأساس.