أبرز المستجدات
يؤثر تغييران هذا الأسبوع على ما يعود من طلباتك (requests). فلن تصل نصوص الاستجابة (response bodies) كرموز مشوهة (mojibake) في المواقع غير المرمزة بـ UTF-8، والاستجابات غير الحاملة لرمز 200 والمقبولة عبر validate تُحتسب أخيراً كنجاح بدلاً من الفشل. كما قمنا بسد بعض الثغرات الأمنية في API الخاص بالعملاء.
ما الجديد
الصفحات غير المرمزة بـ UTF-8 تُرجع نصاً مقروءاً على Single
إذا قمت باستدعاء Single على منتديات بلغارية، أو مواقع تجارة إلكترونية صينية، أو مواقع إخبارية يابانية، أو أي شيء يستخدم windows-1251 أو GBK أو Big5 أو Shift_JIS، فقد كان نص الاستجابة (response body) يعود سابقاً في شكل بايتات تالفة. كانت طبقة HTTP الأساسية تستخدم مفكك ترميز UTF-8 ثابتاً، لذا كانت الصفحات المكتوبة باللغة الكيريلية تصل كـ промоции ولم تكن هناك طريقة لاستعادة النص الأصلي من جانبك.
تم إصلاح هذا على طبقة الطلب (request layer). يقوم Single الآن باكتشاف ترميز الأحرف المصدر (عبر header لـ Content-Type ثم <meta charset> ثم <meta http-equiv>) ويقوم بتحويل الترميز إلى UTF-8 قبل أن يصل النص إلى غلاف JSON الخاص بك. وتمر صفحات UTF-8 أو ASCII دون أي تغيير. لا يتم مطلقاً تفكيك ترميز المحتوى الثنائي مثل الصور أو ملفات PDF. إذا كنت تريد البايتات الخام، فإن returnBuffer: true لا يزال يعيد لك الـ buffer الأصلي.
مفعّل افتراضياً. لا توجد علامة (flag) تحتاج لتغييرها. الصفحات التي كانت تعمل سابقاً لا تزال تعمل، والصفحات التي كانت تُرجع نصوصاً تالفة أصبحت الآن تُرجع نصاً مقروءاً. لا يتعين على مستخدمي المتصفح التفكير في هذا أيضاً، حيث يقوم Chromium بتفكيك ترميز الأحرف بشكل أصيل.
قواعد validate تحدد الآن تصنيف النجاح
عندما تقوم بضبط validate على طلب (request) (على سبيل المثال validate.status.accept = [200, 403])، فإن محرك الطلبات كان يحترم قاعدتك بالفعل ويعالج الاستجابة دون خطأ. ولكن مصنف النتائج لدينا في المراحل اللاحقة كان يتجاهل قاعدتك ويصنف أي شيء ليس 200 حرفياً كـ application_fail. نتج عن ذلك أثران: ظهور استجابة 403 المقبولة لديك كفشل في Dashboard، وبما أن النجاح فقط هو القابل للفلترة والدفع، فإن تلك الاستجابات التي تم تسليمها لم تكن تُحتسب في الفاتورة أيضاً.
يحترم المصنف الآن ما تم تحديده في validate. تُحتسب الطلبات التي تحتوي على validate كنجاح كلما قام المحرك بمعالجتها دون خطأ، بغض النظر عن الحالة (status). وتتصرف الطلبات التي لا تحتوي على validate تماماً كما كانت سابقاً (النجاح عند الحالة 200 فقط)، وبالتالي لم يتغير المسار القديم.
هذا الإصلاح يطبق بأثر مستقبلي فقط: تحتفظ السجلات التاريخية بنتائجها المخزنة، بينما يتم تصنيف الطلبات الجديدة بشكل صحيح. لذا، إذا كنت ترى App Fail على استجابات كنت تعلم أنها صالحة، فهذا هو السبب.
تعزيز الأمان في API الخاص بالعملاء
لقد أطلقنا Wave 0 من مراجعة الأمان عبر API الخاص بالعملاء:
- أصبح CORS مقتصراً الآن على
https://foura.ai. كان الإعداد السابق يعكس أي مصدر (origin) أثناء إرسال بيانات الاعتماد، وهو الإعداد القياسي لـ CSRF. لا تتأثر استدعاءات المتصفح من نفس المصدر (same-origin) واستدعاءات API من جانب الخادم لديك. - كان مسار المقاييس (metrics route) خلف الجدول الزمني لنشاطك (Activity timeline) يقبل فلتر
outcomeحر الشكل يتدفق مباشرة إلى الاستعلام. تم الآن إدراجه في القائمة البيضاء لقيم النتائج المعروفة فقط. لم يكن هذا قابلاً للاستغلال من حساب عادي، ولكن كان من الجدير إغلاقه.
لا يغير أي منهما أي اتفاقية لـ API. لن تلاحظهما أثناء الاستخدام العادي. ولكن العثور على مشكلة وإغلاقها قبل أن يلاحظها أحد لا يزال يستحق الإعلان عنه.
تطابق تسميات النشاط (Activity) مع نظرة عامة (Overview)
تحديث بسيط. كان جدول النشاط (Activity) في Dashboard الخاصة بك يعرض سلاسل النتائج الخام مثل Application_fail بينما كانت عناصر Overview والمخطط الدائري والجدول الزمني تعرض تسميات مألوفة (App Fail) وتصنف كل نتيجة بالألوان. نفس البيانات، بطريقتي عرض مختلفتين. لقد تم مزامنتهما الآن، حيث يقرأ كلاهما من نفس خريطة التسميات والألوان، لذا يظهر حالة الصف بنفس الشكل أينما تحققت منها.
الأرقام
لا يحمل هذا الأسبوع أرقاماً جديدة لزمن الاستجابة (latency) أو معدل النجاح (success-rate). معظم هذا العمل يتعلق بالدقة والأمان، حيث المقياس الصحيح هو "التوقف عن ارتكاب الأخطاء" بدلاً من "العمل بشكل أسرع". يجب أن يحتوي ملخص الأسبوع القادم على بيانات معدل النقل (throughput) لبعض العمليات الجارية حالياً.