أجريت مؤخرًا إعدادًا لحفظة رفع Cloudflare R2، فظهرت مشكلات في صور المصغرات للدردشة. لذا قمت ببعض البحث وأصلحت الإعداد بسرعة، ثم عثرت على هذا الموضوع: Cloudflare R2 Image URL Display Issue: Detailed Explanation and Fix. على أي حال، تفحصت إعدادات حفظة رفع S3 الأخرى ولاحظت أن المشكلة ليست محددة بـ Cloudflare حقًا.
الوصف
عند إعداد مخزن كائنات خارجي متوافق مع S3 للرفع، تتجاوز صور المصغرات في الدردشة شبكة توصيل المحتوى (CDN) وتُحمَّل مباشرةً من عنوان URL الخاص بالحافظة.
في حالة الحفظة الآمنة المتوافقة مع S3 مثل Cloudflare R2، لا تظهر صور المصغرات في الدردشة وتكون معطلة.
السبب الجذري هو أن مُسلسل الدردشة يفشل في تطبيق إعداد s3_cdn_url على المصغرات. فبدلًا من توجيه الصورة عبر شبكة توصيل المحتوى المهيأة، يتم تسريب عنوان URL الداخلي الخام للحافظة مباشرةً إلى حمولات المتصفح.
خطوات التكرار
يمكن تكرار هذه المشكلة في Meta ومواقع أخرى تستخدم حفظة رفع S3:
- انشر صورة في دردشة أو قناة.
- افحص عنوان URL لصورة المصغرة في وحدة التحكم (Console).
- انقر على الصورة للحصول على النسخة الأصلية الأكبر حجمًا، ثم افحص عنوان URL الخاص بها.
- قارن بينه وبين عنوان URL للمصغرة.
إليك مثال من دردشة Meta:
عنوان URL للمصغرة: من الحافظة
https://cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/meta/optimized/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532_2_375x500.jpeg
عنوان URL الأصلي: عبر شبكة توصيل المحتوى
https://global.discourse-cdn.com/meta/original/4X/4/7/9/479815360e0e6e0cd9f4ba565891776e84aea532.jpeg
في وحدة التحكم، يحتوي عنصر HTML الخاص بالمصغرة <img... على data-large-src = عنوان URL الخاص بشبكة CloudFront CDN، بينما يحتوي src على عنوان URL الخاص بحافظة AWS.
الأثر:
- بالنسبة لتخزين متوافق مع S3 مثل Cloudflare R2 الذي يكون آمنًا افتراضيًا ويمنع الوصول غير المصادق عليه إلى نقاط نهاية الحافظة الخام، فإن صور المصغرات في الدردشة (المحسنة) تكون معطلة.
- تسرب استهلاك النطاق الترددي لحفظة AWS وغيرها من مخازن الكائنات المتوافقة مع S3 التي تسمح بالوصول إلى نقاط نهاية الحافظة الخام، لأن الدردشة تتجاوز شبكة توصيل المحتوى بالكامل؛ مما يؤدي إلى دفع رسوم خروج مباشرة من S3 لجميع حركة مرور صور المصغرات في الدردشة.
- تسرب البنية التحتية: يتم كشف عناوين URL لتخزين الخلفية الخام (بما في ذلك أسماء الحفظة الداخلية وأحيانًا معرفات الحسابات) في حمولات JSON الخاصة بالعميل.
طلب سحب (PR):
لدي طلب سحب (PR) لإصلاح هذه المشكلة هنا:
يبدو أن Sam أضاف دالة getURLWithCDN إلى معاينة محرر الدردشة - ومع ذلك، لا أعتقد أنها تصل إلى تيار الدردشة؟
أتساءل عما إذا كان إصلاح المحرر قد يكون فشل في بعض إعدادات S3 أيضًا لأن getURLWithCDN تتعطل عند وجود تعارض في البروتوكول (// مقابل https://)؟ على أي حال، يوسع طلب السحب المذكور أعلاه عمل Sam من خلال إضافة أغلفة إلى تيار الدردشة وجعله محايدًا للبروتوكول.
حل مؤقت:
قبل أن أدرك أن هذه المشكلة تتجاوز مجرد Cloudflare، قمت بإنشاء مكون سمة خفيف الوزن. يقوم هذا المكون باعتراض نطاقات S3 الخام في عنصر DOM الخاص بالدردشة واستبدالها بنطاق شبكة توصيل المحتوى الصحيح قبل أن يحاول المتصفح تنزيلها. وهذا يوجه حركة المرور بشكل صحيح ويسد ثغرة استهلاك النطاق الترددي. وقد قمت بتكييفه ليعمل مع أي تخزين كائنات متوافق مع S3. كل ما يتطلبه الأمر هو إعدادان فقط: «عنوان URL الخام لحافظة S3» و«عنوان URL لشبكة توصيل المحتوى S3».
(لا أعرف سبب تعطل روابط GitHub المضمنة هنا) تم الإصلاح الآن