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

كانت القوائم المنسدلة، ومربعات الاختيار، وأشرطة التمرير، والحقول المعبأة تلقائيا، وأزرار مربعات الحوار تظهر بمظهر فاتح عند تفعيل السمة الداكنة (مربعات بيضاء، وحدود خارجية عشوائية). الآن أصبحت كل عناصر التحكم تتبع السمة النشطة. تمنع النوافذ المنبثقة تمرير الصفحة خلفها، وتظهر تلميحات الأدوات داخل مربعات الحوار في المقدمة، وتخفي حقول إدخال الأرقام أزرار التدوير الخاصة بها.

لم يظهر زر PDF في بعض الفواتير المدفوعة لأننا لم نقم بتعيين الرابط الأساسي. تحتوي كل فاتورة مدفوعة في علامة تبويب الفواتير الآن على زر PDF يعمل.

إذا مررت validate سلبيا إلى /api/auto (مثل {data: {fail: ['"Due to legal reasons"']}})، فقد تمر صفحة Cloudflare البينية 'Just a moment' كنجاح مخزن مؤقتا لأن قائمة الفشل لم تتطابق مع نصها. يرفض Auto الآن صفحات التحدي قبل تطبيق قواعد التحقق الخاصة بك، ويقوم بتبديل المخرج السيئ وإعادة الحل بدلا من تقييمه.

إذا قمت بتعيين مهلة طويلة على foura_auto عبر خادم MCP المستضاف، فقد تنتهي مهلة الطلب عند الحافة قبل انتهاء استدعائك. تم إصلاح ذلك. تعمل الآن الاستدعاءات التلقائية ذات الميزانية الكاملة بميزانيتها البالغة 180 ثانية من البداية إلى النهاية.

إذا كنت تواجه أخطاء 429 عند إطلاق العديد من طلبات Auto المتزامنة نحو هدف واحد، فإن تلك الطلبات كانت تتجه إلى مخرج واحد مخزن مؤقتا لأن المسار الدافئ كان يختار المفضل حسب النتيجة ويعيد التشغيل مرة واحدة. تفتح Auto الآن جلسات إضافية عند الطلب وتوجه كل طلب إلى المخرج الأقل حملا، بحيث يتوزع التدفق عبر معرفات proxy متعددة بدلا من الضغط على معرف واحد. تم القياس محليا: تدفق مكون من 100 طلب على مضيف محمول بدون cookie يتوزع الآن عبر المجموعة الموسعة في غضون ثوان.

تقوم Cloudflare بحقن نص برمجي سلبي حتى في الصفحات التي تمر بشكل نظيف، وكان Auto يعامل أي إشارة إليه على أنها تحدٍ نشط ويقوم بتشغيل حل كامل للمتصفح على أي حال. الآن فقط العلامات البينية الحقيقية (صفحة 'just a moment' وما شابهها) هي التي تؤدي إلى تشغيل مسار المتصفح؛ تعود استجابة 200 النظيفة من مستوى proxy الأرخص. يتبع Auto أيضاً ما يصل إلى 5 عمليات إعادة توجيه افتراضياً (يمكن تكوين ذلك عبر followRedirects).

عندما يعرض هدف محمي بواسطة 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 النشطة والصالحة للعمل قيد التدوير.