أبرز النقاط
أصبح اختيار ملف تعريف المتصفح متاحا الآن كإعداد لكل request. حدد المتصفح ونظام التشغيل الذي تريده، وسوف تصف البصمة بالإضافة إلى الـ headers نفس الشيء. تعلم Single حل نظامي حماية إضافيين هذا الأسبوع (تحدي SG-Captcha من SiteGround وتحدي Argon2 من eBay) دون الحاجة إلى تشغيل Browser. وتقوم واجهة Activity في الـ Dashboard الآن بتسجيل ما طلبته، وليس العمليات الداخلية التي تمت تحته.
ما الجديد
اختر ملف تعريف المتصفح الخاص بك لكل 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 من نفس القائمة، لذا فإن القائمة المنسدلة تعرض دائما بالضبط ما يمكن أن يطلبه الكود الخاص بك.
سبب أهمية ذلك: إذا كان هدفك يحلل الطلبات حسب نظام التشغيل، أو كان فريقك يجري اختبار A/B لمعرفة أي حزمة تتخطى جدارا معينا، فأنت الآن تحافظ على استقرار هذا المتغير بينما يتغير كل شيء آخر.
Single يتجاوز SG-Captcha واختبار إثبات العمل لـ eBay
آليتا دفاع كانتا تجبران الطلب على المرور عبر Browser أصبحتا الآن تتجاوزان عبر Single. تقدم eBay تحدي إثبات العمل الخاص بها (لغز Argon2) وتحمي SiteGround جزءا من مواقع الاستضافة المشتركة باستخدام SG-Captcha. كلاهما يحلان بدون تصيير، مما يعني أن الاستجابة تعود في شكل طلب HTTP واحد وتسعر بناء على ذلك.
زادت إشارة الدفاع في الاستجابات أيضا. تحمل استجابات Browser الآن defenses: { present, cleared }، حتى تتمكن من معرفة المورد الذي يقف أمام الصفحة وما إذا كنا قد نجحنا في تجاوزه. تتبع الفوترة نفس القاعدة: أي مورد نتجاوزه يتم احتسابه، أيا كانت العلامة التجارية. كان Cloudflare هو التجاوز المدفوع الوحيد قبل هذه الفترة. ينضم إليه الآن Akamai Bot Manager و SG-Captcha وتحدي eBay.
إعادة بناء واجهة النشاط في لوحة التحكم
كان هناك عمودان في قائمة النشاط في لوحة التحكم يعرضان بيانات خاطئة. كان عمود طريقة HTTP يعرض دائما POST في كل صف (جميع الـ endpoints الخاصة بنا هي POST، لذا كان العمود ثابتا ولا يقدم أي معلومات). وكان عنوان IP العميل في استدعاءات Playground يسجل من أين تم الاستدعاء، وليس الشخص الذي ينقر على Run.
تم إصلاح كليهما. يعرض عمود الطريقة الآن الفعل الذي أرسلته داخل جسم الطلب. يعرض عنوان IP العميل في صفوف Playground الآن عنوان IP المتصفح للمستخدم المسجل دخوله، والذي يتم نقله داخل token موقع لـ Playground بحيث لا يمكن لعميل الـ API تزييفه.
تمت إعادة بناء بقية الواجهة في نفس الوقت. يتناسب الجدول مع شاشة الكمبيوتر المحمول دون إخفاء الأعمدة، ويندمج عمود المنتج في سطر الطلب، واكتسبت لوحة التفاصيل علامات تبويب بحيث يحصل كل من الطلب والاستجابة وملخص الدفاع على شريط تمرير خاص به.
الفوترة: 3D Secure عند تغيير الخطة
إذا كان مصدر بطاقتك يطلب تأكيد 3DS لتغيير الخطة (وليس فقط عند الاشتراك الأولي)، فلم تكن تلك الخطوة تعمل وكان التغيير يتراجع بصمت. أما الآن فهي تعمل. إذا حاولت تغيير الخطة في الشهر الماضي وبدا أنه لم يحدث شيء، فهذا هو السبب.
تحت الغطاء
يرفض الـ Playground بناء ترويسة استجابة من بيانات موقع تم جلبه (وهي فئة من أخطاء حقن الترويسات التي اكتشفناها مبكرا). يتحقق endpoint الفوترة في لوحة التحكم من أن المتصل يمتلك المورد قبل الاستجابة، مما يغلق مسار IDOR.
تلقى مسار النشر نفسه إصلاحات بحجم أسبوع شاق بعد انقطاع في يوم 6 أدى إلى امتلاء قرص المضيف أثناء عملية البناء. ترفض كل خدمة الآن البناء دون مساحة متوفرة في القرص، وتتسلسل عمليات النشر بدلا من التسابق، وتظل البوابة قيد التشغيل عندما تتذبذب الواجهة الخلفية، وتخرج الخدمات فعليا عند تلقي SIGTERM بدلا من التعليق حتى يتم إنهاؤها بالقوة بعد 30 ثانية.
لفترة طويلة، كان تحديد "أي توقيع متصفح" قرارنا الذي نتخذه بالنيابة عنك. لم يعد هذا ضروريا.