أبرز المستجدات
يمكنك الآن تركيب الـ requests وإرسالها وإعادة تشغيلها باستخدام مفتاح API الخاص بك مباشرة في لوحة التحكم. يغطي الـ playground الجديد جميع المنتجات الثلاثة ويحتفظ بالـ cookies والـ presets وسجل العمليات (history) عبر التشغيلات المختلفة. وقد صدر معه إصلاحان لضمان الموثوقية: كان unblocker: true يتراجع في الأداء بصمت لعدة أسابيع (وهو يعمل الآن مجددًا end-to-end)، ويقوم Browser الآن بالتقاط cookie التحدي السلبي (passive-challenge) الخاص بـ Cloudflare والمسمى cf_clearance بشكل موثوق.
ما الجديد
الـ Playground في لوحة التحكم
أصبح /dashboard/#playground بيئة عمل حقيقية الآن. ثلاثة تبويبات للمنتجات (Single و Proxy Finder و Browser)، وشريط URL، والـ headers، والـ body، مع إتاحة جميع الخيارات (flags) الخاصة بكل منتج ومطابقتها مع الـ schema الفعلية لكل منها. أرسل الـ request، وشاهد الـ response وهو يُعرض بأوضاع عرض JSON و HTML والنص المنسق. ابحث عبر نوافذ الـ response باستخدام Ctrl/Cmd+K. قم بتوسيع الـ response لملء الشاشة بالكامل عندما تحتاج إلى قراءة كتل برمجية ضخمة من HTML.
إليك بعض الميزات التي نتجت عن بنائه بالطريقة التي نفضل استخدامها بأنفسنا:
- يتم حفظ الـ cookies التي تتلقاها في jar مخصص لكل host. يقوم الـ request التالي لنفس الـ host بإرفاقها تلقائيًا، ويمكنك فحص أي cookie أو تعديله أو حذفه قبل الإرسال.
- يجمع شريط البروكسيات العاملة (working-proxies rail) كل معرف proxy id يعود من تشغيل ناجح لـ Proxy Finder، بحيث يمكنك النقر على "use" وإعادة استخدام هذا الـ proxy في request لـ Single أو Browser دون الحاجة لإعادة كتابته.
- حفظ الـ requests كـ presets. إعادة تشغيل أي من آخر 20 عملية تشغيل من نافذة السجل (history dialog).
- يعرض لك منشئ الـ curl الأمر الدقيق (مع
x-api-key) الذي يمكنك تشغيله من واجهة الأوامر (terminal) لإرسال نفس الـ request.
يقوم الـ playground بتوقيع token داخلي قصير الأجل، بحيث لا يغادر مفتاحك النصي الصريح لوحة التحكم أبدًا. تُحتسب الحصة (quota) والمقاييس (metrics) و last_used_at ضمن المفتاح الذي اخترته، تمامًا كما لو كنت قد أرسلت الـ request من الكود الخاص بك.
عاد unblocker: true للعمل مجددًا end-to-end
لقد اكتشفنا مشكلة في البناء (build issue) كانت تتسبب في تراجع أداء requests لـ Single و Proxy Finder التي تستخدم unblocker: true بصمت طوال الأسابيع القليلة الماضية. تم شحن البناء دون ربط آلية التخطي (bypass) فعليًا، لذا فإن الـ requests التي كان ينبغي لها تجاوز جدران الحماية ضد البوتات على مستوى المصافحة (handshake-level anti-bot) كانت تحصل على توقيع request عام بدلاً من ذلك. وكانت المواقع التي ينبغي أن تسمح بمرورنا تقوم بحظرنا.
تم نشر الإصلاح. لقد تحققنا من العمل end-to-end عبر أحد عشر هدفًا حقيقيًا، بما في ذلك ثلاثة أهداف على صفحات Cloudflare البينية (interstitials) التي كانت تتطلب سابقًا استخدام Browser لتجاوزها. يمررها Single بمفرده الآن. يعود مسار التدفق المتسلسل Proxy Finder + Browser + Single (البحث عن proxy، والحصول على cookie من نوع cf_clearance من Browser، ثم إرسال الـ request للصفحة باستخدام Single بالإضافة إلى الـ cookie ونفس الـ proxy) بـ HTML كامل في دورة اتصال واحدة (round trip).
هذا الخطأ نتحمل مسؤوليته بالكامل. كان unblocker: true يعمل يوم إطلاقه، وتعطل بهدوء أثناء عملية إعادة بناء روتينية. إذا قمت بتشغيل request باستخدام unblocker: true ضد موقع محمي في الأسابيع القليلة الماضية وظهر لك الخطأ 403 بدلاً من الاستجابة المتوقعة 200، فهذا هو السبب. يرجى المحاولة مرة أخرى.
يتعامل Browser مع تحدي JavaScript السلبي من Cloudflare
توفر Cloudflare وضعي تحدٍ. الوضع النشط (HTTP 403 بالإضافة إلى الصفحة البينية) كنا نتعامل معه بالفعل. أما الوضع السلبي فهو أكثر دهاءً: تعود الصفحة بالرمز 200 فورًا، ولكن Cloudflare تحقن مسبار JavaScript غير متزامن (async JavaScript probe) يأخذ بصمة العميل (fingerprints) وعندها فقط يصدر الـ cookie من نوع cf_clearance. قبل هذا الإصلاح، كان Browser ينهي الـ response قبل اكتمال عمل المسبار، وبالتالي لم يكن cookie التخليص يصل إلى الـ jar أبدًا.
يستمع Browser الآن إلى حدث Set-Cookie بشكل صريح وينتظر cf_clearance إذا رأى علامة التحدي السلبي (passive-challenge) في الـ body. لا يوجد استعلام دوري (polling)، ولا فترة سماح ثابتة، ولا انتظار إضافي للمواقع التي لا تستخدم Cloudflare. هناك اثنا عشر نطاقًا حقيقيًا في مجموعة الاختبارات، ثلاثة منها تتبع المسار السلبي، وتعود بـ clearance cookies بشكل موثوق الآن.
سد ثغرة SSRF عند حافة الـ API
إن وجود مفتاح API صالح بصيغة pk_live_... لا يمنح ترخيصًا للوصول إلى شبكتنا الخاصة. يرفض الـ API الآن أي هدف يقع اسم المضيف (hostname) الصريح الخاص به أو تحليل DNS له ضمن النطاقات المحجوزة لـ RFC 5735 أو 6598 أو IPv6. ويتم تشغيل نفس الفحص في كل منتج من منتجات الخلفية (backend) كخط دفاع ثانٍ.
لن تلاحظ أي تغيير على السطح. نحن نغلق فئة من عمليات فحص الشبكة الداخلية قبل أن تتمكن من إكمال مصافحة TCP (TCP handshake).
المدونة تحصل على معاينات فريدة لشبكات التواصل الاجتماعي، وإصلاح تقسيم الصفحات
تنشئ كل تدوينة الآن صورة Open Graph الخاصة بها مع عرض عنوان التدوينة والمقتطف (excerpt) على بطاقة الهوية البصرية. انسخ رابطًا مثل foura.ai/blog/... والصقه في Discord أو LinkedIn أو Slack أو Twitter وسترى المعاينة المخصصة للتدوينة بدلاً من المعاينة الافتراضية العامة.
كان تقسيم الصفحات (pagination) في فهرس المدونة معطلاً بصمت. كان زر "Older" يعيدك إلى الصفحة 1. لقد أعدنا بناءه باستخدام URLs تعتمد على المسار (/blog/page/N/)، وأضفنا تنقلاً مرقمًا مع نافذة ذكية، وأضفنا وسوم روابط rel=prev/next مناسبة للسلاسل المقسمة إلى صفحات. تقوم عناوين URL القديمة بصيغة ?page=N بإجراء تحويل 301 إلى الشكل الجديد، لذا لن يُفقد أي شيء تمت أرشفته مسبقًا.
خلف الكواليس
إن خادم MCP الخاص بنا متاح الآن على mcp.foura.ai لأي أدوات LLM تدعم بروتوكول Model Context Protocol. المصادقة هي نفس الـ Bearer token بصيغة pk_live_... الذي تستخدمه مع REST API. وهو يعرض المنتجات الثلاثة كأدوات (Single و Proxy Finder و Browser) ومجموعة من الـ prompts. إذا كنت تقوم بربط FourA بـ Claude Code أو أي عميل (agent) يدعم MCP، فيمكنك التوقف عن تشغيل جسر محلي (local bridge).
إذا كنت قد تجنبت استخدام لوحة التحكم لأن الـ playground السابق كان مجرد نموذج أولي بسيط، فافتحها هذا الأسبوع. إنها الواجهة التي نستخدمها الآن بأنفسنا عندما يبدو شيء ما غير صحيح مع هدف API.