أهم التحديثات
أصبح اختيار profile للمتصفح إعداداً متاحاً لكل request على حدة. حدد المتصفح ونظام التشغيل (OS) المطلوبين، وسيتطابق كل من fingerprint وheaders مع هذا التحديد. تعلم Single هذا الأسبوع إكمال فحصين إضافيين (الفحوصات الحسابية الخاصة بـ SiteGround وeBay) دون الحاجة لتشغيل Browser. كما تعرض واجهة Activity في Dashboard الآن ما طلبته فعلياً، بدلاً من التفاصيل التقنية للعمليات التي نُفذت في الخلفية.
ما الجديد
اختر profile للمتصفح لكل request
حتى الآن، كان unblocker: true يختار توقيعاً واحداً فقط (أياً كان الإعداد الافتراضي الحالي لدينا) وينتهي الأمر عند ذلك. يمكنك الآن تحديد خيار مخصص:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
أو اطلب تركيبة محددة من المتصفح ونظام التشغيل:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
يرفض الـ API التركيبات غير المعروفة بالاسم ويسرد ما هو متاح بالفعل، وبالتالي لا يمكن لأي خطأ مطبعي أن يرسل بصمة لم تطلبها دون علمك.
الكتالوج الكامل متاح على GET /api/profiles. وهو عام (لا يتطلب مفتاحا)، لأنه قائمة إمكانيات وليس سرا. حتى كتابة هذه السطور، يتوفر 79 إعدادا مسبقا عبر Chrome وFirefox وEdge وSafari وTor، على أنظمة Windows وmacOS وAndroid وiOS. يقرأ الـ Playground من القائمة نفسها، لذا تعرض القائمة المنسدلة دائما ما يمكن لبرمجتك طلبه بالضبط.
أهمية ذلك: إذا كان هدفك يحلل الـ requests حسب نظام التشغيل، أو كان فريقك يجري اختبارات A/B لتحديد أي بيئة تتجاوز جدار حماية معينا، يمكنك الآن تثبيت هذا المتغير بينما يتغير كل شيء آخر.
Single يكمل الفحوصات الحسابية لـ SiteGround وeBay
اثنان من أنظمة الحماية التي كانت تفرض في السابق التحويل عبر Browser يتم تجاوزهما الآن على Single. يرسل eBay تحدي proof-of-work خاصا به (لغز Argon2)، بينما يشغل SiteGround فحصه الخاص عبر جزء كبير من مواقع الاستضافة المشتركة. كلاهما يُحل دون rendering، مما يعني أن الـ response يعود في شكل HTTP request مفرد وتتم محاسبته وفقا لذلك.
كما توسعت إشارات الحماية في الـ responses أيضا. تحمل ردود Browser الآن defenses: { present, cleared }، لتتمكن من معرفة المزود الذي يقف أمام الصفحة وما إذا تمكنا من تجاوزه. تتبع الفوترة القاعدة نفسها: أي مزود نتجاوزه يُحسب، أيا كانت علامته التجارية. قبل هذه الترقية، كانت خدمة فحص واحدة فقط تُحسب كصفحة تفاعلية. انضمت إليها ثلاث خدمات أخرى الآن.
إعادة بناء عرض النشاط في Dashboard
كان هناك عمودان في قائمة Activity داخل Dashboard يعرضان بيانات غير دقيقة. كان HTTP method يظهر دائما كـ POST في كل صف (جميع الـ endpoints لدينا تستخدم POST، لذا كان العمود قيمة ثابتة لا تقدم أي إفادة). وكان client IP في استدعاءات Playground يسجل الموقع الذي انطلق منه طلب Playground، وليس عنوان الشخص الذي نقر على Run.
تم إصلاح الأمرين. يعرض عمود method الآن الفعل الذي أرسلته داخل request body. كما يقرأ client IP في صفوف Playground الآن عنوان IP لمتصفح المستخدم المسجل دخوله، منقولا داخل Playground token موقع لمنع أي عميل API من تزييفه.
تمت إعادة بناء بقية واجهة العرض أثناء العمل على ذلك. أصبح الجدول ملائما لشاشات الكمبيوتر المحمول دون إخفاء أعمدة، وتم دمج عمود المنتج داخل سطر الـ request، وحصلت لوحة التفاصيل على علامات تبويب بحيث يحصل كل من الـ request والـ response وملخص الحماية على شريط تمرير خاص به.
الفوترة: 3D Secure عند تغيير الخطة
إذا كانت الجهة المصدرة لبطاقتك تطلب تأكيد 3DS لتغيير الخطة (وليس فقط عند الاشتراك الأولي)، فإن تلك الخطوة لم تكن تعمل وكان التغيير يتراجع تلقائيا دون إشعار. أصبحت تعمل الآن. إذا حاولت تغيير خطتك خلال الشهر الماضي وبدا وكأن شيئا لم يحدث، فهذا هو السبب.
خلف الكواليس
يرفض Playground إنشاء response header من بيانات الموقع الذي تم جلبه (وهي فئة من أخطاء header-injection رصدناها مبكرا). كما يتحقق endpoint الفوترة على Dashboard من ملكية المتصل للمورد قبل الاستجابة، مما يغلق ثغرة من نوع IDOR.
حصل خط أنابيب النشر نفسه على أسبوع شاق من الإصلاحات بعد أن تسبب انقطاع في الخدمة يوم 6 في ملء قرص مضيف النشر في منتصف عملية البناء. أصبحت كل خدمة ترفض البناء دون توفر مساحة كافية على القرص، وتتم عمليات النشر بالتسلسل بدلاً من التسابق، وتظل البوابة تعمل عند اضطراب الواجهة الخلفية، كما تخرج الخدمات بالفعل عند استلام SIGTERM بدلاً من التعليق حتى يتم إنهاؤها بعد ثلاثين ثانية.
لفترة طويلة، كان تحديد "أي بصمة متصفح يتم استخدامها" قراراً نتخذه نيابة عنك. لم يعد الأمر بحاجة لأن يكون كذلك.