أبرز النقاط
يمكنك الآن إنشاء وإرسال وإعادة تشغيل requests باستخدام API key الخاص بك مباشرة من لوحة التحكم. تغطي بيئة الاختبار (playground) الجديدة جميع المنتجات الثلاثة وتحتفظ بملفات cookies والإعدادات المسبقة وسجل العمليات عبر مختلف التشغيلات. كما تم إطلاق إصلاحين للاعتمادية مع هذا التحديث: ميزة unblocker: true كانت تتراجع في الأداء بصمت لعدة أسابيع (وهي تعمل الآن مجددا، من البداية إلى النهاية)، وأصبح Browser يلتقط الآن cookie التحدي السلبي cf_clearance من Cloudflare بشكل موثوق.
ما الجديد
بيئة اختبار لوحة التحكم
أصبحت /dashboard/#playground بيئة عمل حقيقية الآن. تتضمن ثلاثة تبويبات للمنتجات (Single وProxy Finder وBrowser)، وشريط URL، وheaders، وbody، مع إتاحة جميع الخيارات الخاصة بكل منتج ومطابقتها لمخطط (schema) كل منتج الفعلي. أرسل request وراقب استجابة response مع أوضاع عرض JSON وHTML والنص العادي. يمكنك البحث عبر لوحات الاستجابة باستخدام Ctrl/Cmd+K، وتوسيع الاستجابة لتشمل مساحة العرض الكاملة عندما تحتاج لقراءة نص HTML طويل.
بعض الميزات التي نتجت عن بنائها بالطريقة التي نفضل استخدامها بأنفسنا:
- يتم حفظ ملفات cookies المستلمة في وعاء مخصص لكل host. يرفق request التالي إلى نفس host هذه الملفات تلقائيا، ويمكنك فحص أو تعديل أو حذف أي cookie قبل الإرسال.
- شريط للبروكسيات العاملة يجمع كل proxy id مسترجع من عملية تشغيل ناجحة لـ Proxy Finder، بحيث يمكنك النقر على "use" وإعادة استخدام هذا proxy في request عبر Single أو Browser دون إعادة كتابته.
- حفظ requests كإعدادات مسبقة، وإعادة تشغيل أي من آخر 20 عملية تشغيل من نافذة السجل.
- أداة توليد أمر cURL تعرض الأمر الدقيق (باستخدام
x-api-key) الذي يمكنك تشغيله من الطرفية لإرسال نفس request.
تقوم بيئة الاختبار بتوقيع token داخلي قصير الأجل، وبذلك لا يغادر مفتاحك النصي الصريح لوحة التحكم أبدا. تُحسب الحصص (Quota) والمقاييس وlast_used_at على المفتاح الذي اخترته، تماما كما لو كنت قد أرسلت request من التعليمات البرمجية الخاصة بك.
unblocker: true يعمل مجددا، من البداية إلى النهاية
اكتشفنا مشكلة في البناء تسببت في خفض مستوى requests الخاصة بـ Single وProxy Finder مع unblocker: true بصمت خلال الأسابيع الماضية. تم إطلاق البناء دون ربط ملف تعريف المتصفح فعليا، لذلك فإن requests التي كان ينبغي أن تحمل بصمة متصفح كانت تحصل على بصمة request عامة بدلا من ذلك. وكانت المواقع التي كان ينبغي أن تسمح بمرورنا تقوم بحظرنا.
تم نشر الإصلاح. وتحققنا من عمله بالكامل عبر أحد عشر هدفا في بيئات عمل حقيقية، بما في ذلك ثلاثة أهداف خلف صفحات تحقق كانت تتطلب سابقا استخدام Browser. يتجاوزها Single الآن بمفرده. كما أن مسار العمل المتسلسل Proxy Finder + Browser + Single (العثور على proxy، ثم الحصول على cookie من نوع cf_clearance من Browser، ثم إرسال request الصفحة عبر Single مع الـ cookie ونفس الـ proxy) يعيد كود HTML كاملا في دورة طلب واحدة.
هذا الخطأ كان من جانبنا. كان unblocker: true يعمل يوم إطلاقه، وتعطل دون تنبيه أثناء إعادة بناء روتينية. إذا أرسلت request باستخدام unblocker: true إلى موقع محمي خلال الأسابيع القليلة الماضية وظهرت لك استجابة 403 بدلا من 200 المتوقعة، فهذا هو السبب. جرب مجددا الآن.
Browser يتعامل مع تحدي JavaScript السلبي من Cloudflare
لدى Cloudflare نمطان للتحدي. النمط النشط (HTTP 403 مع صفحة وسيطة) كنا نتعامل معه بالفعل. أما النمط الخامل فهو أكثر خفاء: ترجع الصفحة الرمز 200 فورًا، لكن Cloudflare تحقن مسبار JavaScript غير متزامن يقوم بأخذ بصمة العميل ولا يصدر ملف تعريف الارتباط cf_clearance إلا بعد ذلك. قبل هذا الإصلاح، كان المتصفح ينهي الاستجابة قبل اكتمال المسبار، وبالتالي لم يكن ملف تعريف الارتباط للتخويل يصل مطلقا إلى المخزن.
يستمع المتصفح الآن إلى حدث Set-Cookie بشكل صريح وينتظر cf_clearance إذا رصد علامة التحدي الخامل في متن الاستجابة. دون فحص دوري، ودون فترة سماح ثابتة، ودون انتظار إضافي للمواقع التي لا تستخدم Cloudflare. اثنا عشر نطاقا واقعيا في مجموعة الاختبارات، ثلاثة منها على المسار الخامل، تُرجع ملفات تعريف الارتباط للتخويل بشكل موثوق الآن.
إغلاق ثغرة SSRF على مستوى واجهة API
إن مفتاح API صالح لـ pk_live_... لا يمنح ترخيصا للوصول إلى شبكتنا الخاصة. ترفض واجهة API الآن أي هدف يقع اسم مضيفه النصي أو ناتج تحليل DNS الخاص به ضمن كتل RFC 5735 أو 6598 أو الكتل المحجوزة لـ IPv6. ويتم تشغيل الفحص نفسه في كل منتج خلفي كخط دفاع ثان.
لن تلاحظ أي تغيير ظاهريا. نحن نغلق فئة كاملة من مسابير الشبكة الداخلية قبل أن تتمكن حتى من إتمام مصافحة TCP.
المدونة تحصل على معاينات اجتماعية مخصصة وإصلاح الترقيم
تنشئ كل مقالة في المدونة الآن صورة Open Graph خاصة بها تحتوي على عنوان المقال ومقتطف منه معروضين على بطاقة الهوية البصرية. الصق رابط foura.ai/blog/... في Discord أو LinkedIn أو Slack أو Twitter وسترى المعاينة المخصصة للمقال بدلا من الصورة البديلة العامة.
كان الترقيم في فهرس المدونة معطلا بشكل غير ملحوظ؛ حيث كان زر "Older" يعيدك إلى الصفحة 1. أعدنا بناءه بالاعتماد على عناوين URL قائمة على المسارات (/blog/page/N/)، وأضفنا تنقلا مرقما بنافذة ذكية، ووسوم روابط rel=prev/next ملائمة للسلاسل المرقمة. عناوين ?page=N القديمة تقوم بإعادة توجيه 301 إلى الصيغة الجديدة، لذلك لن يُفقد أي شيء تمت فهرسته سابقا.
ما وراء الكواليس
خادم MCP الخاص بنا متاح الآن عبر mcp.foura.ai لأي أدوات LLM تدعم Model Context Protocol. عملية التوثيق هي نفسها باستخدام رمز Bearer الخاص بـ pk_live_... الذي تستخدمه مع REST API. وهو يوفر المنتجات الثلاثة كأدوات (Single و Proxy Finder و Browser) ومجموعة من التوجيهات. إذا كنت تقوم بربط FourA في Claude Code أو أي وكيل يدعم MCP، يمكنك التوقف عن تشغيل جسر محلي.
إذا كنت تؤجل استخدام لوحة التحكم لأن بيئة الاختبار السابقة كانت مجرد نموذج أولي، فافتحها هذا الأسبوع. إنها الواجهة التي نستخدمها نحن أنفسنا الآن عندما يبدو أمر ما غير صحيح تجاه هدف API.