الكلجديدمُحسّنإصلاح
مُحسّن

جدول النشاط يناسب شاشات الحواسيب المحمولة، وإضافة علامات تبويب للوحة

يناسب جدول النشاط الآن شاشة MacBook مقاس 14 بوصة دون الحاجة إلى التمرير الجانبي، ويحتفظ كل عمود بقيمته. أصبحت لوحة التفاصيل عبارة عن لوحة مبوبة (Request، و Response headers، و Response body)، لذلك تظهر الإجابة في الأعلى بدلا من التمرير لأسفل بمقدار 900px. تتبع تلميحات الأدوات مؤشر الماوس وتعرض عنوان URL بالكامل.

مُحسّن

يعرض النشاط الطلب الذي أرسلته بالفعل

يقرأ عمود الطريقة الآن الفعل من نص الطلب (GET، POST، PUT، إلخ)، بدلا من عرض POST دائما لأن هذا ما تلقته طبقة API لدينا. تسجل استدعاءات Playground أيضا عنوان IP للمتصفح الخاص بالشخص الذي نقر على إرسال، بحيث يمكن للحساب المشترك معرفة من قام بتشغيل ماذا.

جديد

اختر المتصفح الذي يعرضه طلب MCP الخاص بك

يتيح FourA MCP 0.6.0 للوكيل اختيار المتصفح الذي يعرضه الطلب. يقبل foura_single و foura_proxy القيم browser أو os أو version، أو معرف profile دقيق من الكتالوج العام في GET /api/profiles. تنتقل هذه البيانات داخل الطلب الذي يتجه بالفعل إلى الخادم الأساسي (upstream)، لذلك لا يوجد استدعاء إضافي. إذا تركتها فارغة، فسيعرض الطلب أحدث إصدار من Google Chrome، تماما كما في السابق. أي مجموعة لا يمكن للكتالوج عرضها ترجع كخطأ يسرد ما هو متاح، لذلك لا يتم إرسال الطلب أبدا كمتصفح لم تختره.

ترجع كلتا الأداتين الآن defense عندما يقوم الهدف بتشغيل فحص الروبوتات (bot check). يعني defense.solved: false أن النص الأساسي قد يكون صفحة تحدي بدلا من المحتوى الذي طلبته، وهي إشارة لإعادة المحاولة باستخدام متصفح مختلف أو التصعيد، بدلا من تحليل صفحة حظر كبيانات.

تصحيح واحد في نفس الإصدار: ذكر وصف unblocker أن الإعداد الافتراضي له كان معطلا. لقد كان قيد التشغيل دائما، لذلك كانت الطلبات تحمل بالفعل مجموعة header كاملة للمتصفح. يتطابق المخطط المنشور الآن مع السلوك.

مُحسّن

تظهر النسخة البطيئة الآن كمتدهورة

تستجيب النسخة المشبعة لفحص الصحة في غضون 3 إلى 10 ثوانٍ بينما تستغرق النسخة السليمة من 9 إلى 225 مللي ثانية، وكلاهما كان يظهر على أنه سليم. تظهر النسخة البطيئة الآن كمتدهورة، وتحمل السبب الخاص بالنسخة نفسها، لذلك نرى المشكلة عندما تكون مجرد خادم بطيء واحد ولم تصبح بعد طلبك الفاشل. تتم مراقبة Auto أيضًا، مع تعيين حدود للمدة التي يستغرقها الحل الصعب الحقيقي بدلاً من الحدود العامة التي يتم تشغيلها عند كل نجاح.

جديد

اختيار ملف تعريف المتصفح لكل طلب

تخبر المعلمة profile أداة إلغاء الحظر بالمتصفح الذي يجب محاكاته في /api/single و /api/proxy. قم بتمرير معرف ملف تعريف دقيق (مثل firefox147 أو chrome146)، أو دع browser + os + version تصل إلى أحدث تركيبة مطابقة. تُرجع GET /api/profiles الكتالوج الحالي (79 ملف تعريف عبر خمس عائلات من المتصفحات)، بحيث لا تضطر إلى كتابة قائمة ثابتة في الكود تصبح قديمة. توفر ساحة تجارب Dashboard نفس أداة الاختيار في شكل ثلاث قوائم تحديد متتالية.

مُحسّن

يحدد Playground المتصفح ونظام التشغيل والإصدار

يحتوي Playground في لوحة المعلومات الآن على ثلاث قوائم تحديد متتالية لنظام التشغيل، والمتصفح، والإصدار، يتم سحبها مباشرة من كتالوج الملفات الشخصية. اختر أي اثنين منها وسينحصر الخيار الثالث في ما يتم حله فعليًا. يؤدي اختيار ملف شخصي إلى تشغيل unblocker، لأن API يرفض أي ملف شخصي بدونه.

إصلاح

صفحة الحالة تقرأ عمليات النشر التدريجي بشكل صحيح

تُعتبر الخدمة الآن متوقفة فقط عندما تفقد كل instance، وهي الحالة الوحيدة التي لا يجد فيها الـ request الخاص بك مكاناً للوصول إليه. لم تعد عمليات النشر التدريجي الروتينية تظهر كحوادث في صفحة الحالة.

مُحسّن

عاد التوقيع الافتراضي لـ Unblocker ليصبح حديثا

أصبح التوقيع الافتراضي الذي يرسله Unblocker الآن إصدارا رئيسيا حاليا، وليس الإصدار القديم الذي ثبتته برامج الكشط. المواقع التي بدأت في إرجاع صفحات حظر ثابتة للإصدارات الرئيسية الأقدم أصبحت ترجع صفحاتها الحقيقية على Single و Browser. تم تحديث كلا المنتجين معا، لذا فإن إعادة إرسال cf_clearance من Browser إلى Single لا تزال تصل متطابقة بايت ببايت.

إصلاح

تغييرات الخطة تكتمل بخطوة 3D Secure

عندما يطلب المصرف الذي تتعامل معه 3D Secure عند ترقية الخطة، كان الـ request يستعلم باستمرار عن تغيير لم يصل أبدًا (لم يطلب منك أحد المصادقة). يعالج الآن مسار تغيير الخطة الخطوة الإضافية كما يحدث في الاشتراك الأول، لتتم عملية الترقية بنجاح.

جديد

ظهور الخطط المخصصة في علامة تبويب الفوترة

إذا قام أحد المشرفين بتعيين خطة مخصصة لك، فإنها تظهر الآن في قسم الفوترة / الخطة على النحو التالي 'خطتك المخصصة: {name} ({price})' مع زر للاشتراك. قبل ذلك، كان التعيين غير مرئي حتى يخبرك شخص ما بوجوده.

مُحسّن

يخصم Browser الرصيد لكل نظام حماية يتخطاه، وليس Cloudflare فقط

كان Browser يخصم 30 رصيدا لفئة تخطي الحماية فقط عند ظهور clearance cookie الخاص بـ Cloudflare. الآن، يقوم بنفس الإجراء لأي نظام حماية نتعرف عليه ونتخطاه، بدءا من SiteGround. تتضمن الـ response أيضا defenses: { present, cleared }، لتتمكن من معرفة المورد الذي اعترض طريقك حتى لو لم نتخطاه بعد (يتم حاليا التعرف على DataDome و PerimeterX و Akamai و Incapsula و hCaptcha، ولكن لم يتم تخطيها بعد).

مُحسّن

استجابة المتصفح تحدد كل نظام حماية موجود وتم تخطيه

تعيد استجابات المتصفح الآن defenses: { present, cleared }: كل مزود قام الهدف بتشغيله، وكل مزود تمكنا بالفعل من تخطيه. تتبع الفوترة القاعدة نفسها. يُعد الطلب الذي يتخطى أي مزود (وليس Cloudflare فقط) بمثابة حل للحماية، والمزودون الذين نتعرف عليهم ولكن لا يمكننا التغلب عليهم بعد يظهرون في present ولا يرفعون السعر أبدا.

جديد

Single يجتاز تحديات SiteGround بدون متصفح

تعمل SiteGround كواجهة لجزء كبير من متاجر WordPress و WooCommerce الصغيرة، لذلك تعتبر شاشة Robot Challenge الخاصة بها فئة من الأهداف وليست موقعا واحدا. باستخدام unblocker: true، يقوم Single الآن بحلها ضمن العملية ويرجع الصفحة الحقيقية. قبل ذلك، كان عليك تشغيل Browser لتلك الفئة من الأهداف، مما كان يعني الدفع مقابل جلسة متصفح والانتظار. يعود cookie الخاص بالتخطي في الـ response، لذلك تظل إعادة الطلب رخيصة.

إصلاح

المتصفح يتعامل مع الصفحات الانتقالية التي تعيد التوجيه

يتعامل المتصفح الآن مع صفحة التحدي التي تعيد التوجيه قبل قراءة محتواها، لذا فإن الطلبات الموجهة إلى المواقع المحمية تعود بمحتوى بدلاً من استجابة فارغة.

جديد

Single يحل تحدي Robot Challenge من SiteGround

تضع SiteGround شاشة 'Robot Challenge Screen' أمام العديد من متاجر WordPress و WooCommerce الصغيرة؛ لا يوجد شيء للنقر عليه، إنه إثبات عمل SHA-1. يقوم Single الآن بتخطي هذا التحدي في طلب واحد ويعيد الصفحة الحقيقية، بتكلفة 2 رصيد بدلا من 30 رصيد لجلسة متصفح. هذه هي أول آلية دفاع ليست من Cloudflare يتعامل معها Single بمفرده.