سجل التغييرات

عندما يعرض هدف محمي بواسطة Cloudflare صفحة حظر جغرافي حقيقية (451) بعد اجتياز التحدي، كان منتج Browser يبلغ عنها كحالة 200 لأن المراقب قام بتثبيت حالة التخطي. يقرأ المراقب الآن Document الفعلي بعد التخطي، بحيث تبقى 200 كـ 200، وتظهر 451 كـ 451، ويرفض Auto المحتوى الخاطئ ويستمر في البحث عن مخرج يتطابق فعليًا مع قواعد validate الخاصة بك.

يفتح الاختصار Cmd+K (Ctrl+K) الآن لوحة الأوامر ونافذة البحث بغض النظر عن تخطيط لوحة المفاتيح. كنا نطابق الحرف المكتوب (к على تخطيط سيريلي)، لذلك لم يحصل أي شخص يستخدم تخطيطا غير لاتيني على أي شيء. الآن نحن نطابق المفتاح الفعلي. تم الإصلاح عبر الموقع الرئيسي، والمدونة، والمستندات.

قد تستغرق عملية حل Auto الباردة عدة دقائق، ويبقى request الآن مفتوحا طوال ميزانيته بالكامل. تعود الأخطاء من أي طبقة بتنسيق JSON يمكن لعميلك تحليله.

المواقع التي يمكن إعادة استخدام الـ cookie فيها (كان bet365 هو المؤشر) كانت تظل عالقة في حل المتصفح المكلف بمقدار 15 رصيدا لكل طلب بدلا من الانخفاض إلى الإعادة الرخيصة بتكلفة 2 رصيد بعد الحل الأول. خطآن: تم تفعيل القفل عند أي خطأ نقل عابر، وعملية الإعادة الناجحة للمتصفح لم تقم أبدا بتحديث ملفات الـ cookie للجلسة. تم إصلاح كليهما. الطلبات المتكررة على المواقع التي يمكن إعادة استخدام الـ cookie فيها تكلف الآن 2 رصيد بعد الحل الأول، تماما كما يشير التسعير.

لقد قمنا بتشديد قيود الوصول عبر نطاقات مختلفة (cross-origin) بحيث لا يمكن لغير foura.ai استدعاء الـ API باستخدام بيانات الاعتماد. كما قمنا بتعزيز فلتر المدخلات على endpoint المقاييس وحذف السر الاحتياطي المخصص للتطوير فقط. ولن تتغير عمليات التكامل الحالية.

إذا قمت بتعيين validate.status.accept على request، فإن المحرك يعامل استجابة non-200 المقبولة كنجاح تام. كانت Activity لا تزال تصنف تلك الاستجابات كإخفاقات، مما أدى إلى تشويه إحصاءات الاستخدام الخاصة بك. تتبع النتائج الآن قرار validate الخاص بك، لذا فإن رمز 403 الذي قبلته يظهر كنجاح، وليس App Fail.

إذا كنت تكشط صفحات باللغة السيريلية، أو الصينية، أو اليابانية، أو غيرها من الصفحات غير المعتمدة على UTF-8 عبر Single، فقد كان الـ body يعود سابقاً على شكل mojibake. كنا نفرض فك ترميز كل response كترميز UTF-8 قبل أن ترى الـ raw bytes. الآن، نقرأ الـ charset من الـ response (من Content-Type، ثم <meta charset>، ثم UTF-8 كخيار احتياطي) ونفك ترميزه بشكل صحيح. شكراً لـ Alexandar Kanchev (Sensika) على الإبلاغ عن هذا.

بعض الـ proxies المنتشرة على الإنترنت لا تقوم بتمرير الـ request الخاص بك فعلياً. بل تعكسه على شكل تفريغ خادم بنص صريح وتحاول استخراج ما بداخله. أصبحنا الآن نكشف هذا النمط قبل أن يصل الـ response إلى الكود الخاص بك، لذا فإن Single و Browser و Proxy Finder تعيد جميعاً فشلاً صريحاً (أو تقوم بإعادة المحاولة) بدلاً من هذه البيانات عديمة الفائدة.

لقد قمنا بإصلاح بطء كان يتسبب في انتظار الـ proxies المكتشفة حديثًا قبل التحقق من صحتها. يقوم Proxy Finder الآن بفحصها على الفور، مما يحافظ على تحديث المجموعة باستمرار مع وجود المزيد من الـ proxies النشطة والصالحة للعمل قيد التدوير.

يتتبع Playground الآن السمة Domain بشكل صحيح، لذلك تبقى الـ cookies المقتصرة على المضيف في المضيف الخاص بها. تضع طريقة العرض Parsed شارة HO عليها، وتطابق طريقة العرض Raw ما أرسله الـ upstream.

أصبحت جميع حقول Playground الآن متوافقة مع المخطط: يفرض المتصفح استخدام GET، ويخفي مساحة النص، وتعرض علامة التبويب Raw نفس الـ JSON الذي يصل إلى API بالإضافة إلى كود curl لإعادة الإنتاج.

مع unblocker: true، يحمل Single و Proxy Finder الآن توقيع unblocker الكامل حتى المصدر، لذا فإن جدران الحماية من الروبوتات التي تتحقق منه تسمح بمرور الطلب.

تُرجع بعض مواقع Cloudflare الاستجابة 200 OK ولكنها تحقن برمجية خلفية تُصدر الـ cookie الحقيقي cf_clearance بعد لحظة. وكان Browser يُرجع الصفحة قبل وصول الـ cookie ذاك، مما يترك مخزن الـ cookie فارغاً. أما الآن، ينتظر Browser حدث الـ cookie، لتتمكن من الحصول على cf_clearance نظيف يمكنك إعادة استخدامه عبر Single أو Proxy.

كان زر "Older" في المدونة يعيد توجيهك إلى الصفحة 1. أصبح تقسيم الصفحات متاحاً الآن عبر عناوين URL بالصيغة /blog/page/N/ مع نظام تنقل مرقم، مما يتيح لك تصفح المقالات الأقدم بالفعل. شكراً، Vladimir Petrov.

يقوم المتصفح الآن بتمرير كل طلب عبر محرك JavaScript، لذلك يتم عرض تحديات Cloudflare والصفحات التي تعتمد بشكل كبير على JS كما هو متوقع.