في البداية، ظننت أنني أغفلت بعض الإعدادات، لكن المشكلة قابلة للتكرار هنا في موقع meta: https://meta.discourse.org/uploads/short-url/dw1U4hctATusBlHsUmWQXeme66j.csv (تم التحميل هنا) هو إعادة توجيه 302 إلى //assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv
أليس من المفترض أن يعيد التوجيه إلى https://d11a6trkgmumsb.cloudfront.net/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv بدلاً من ذلك؟
هذا الأمر معقد قليلاً، لقد ألقيت نظرة عليه للتو. بشكل أساسي، نقوم دائمًا بالتنزيل من S3 باستخدام عنوان URL موقع التوقيع عند إجراء “تنزيل قسري”، وهو ما يحدث عند النقر على رابط المرفق أو النقر على زر “تنزيل” في صورة. والسبب في ذلك هو إضافة رؤوس content-disposition المناسبة:
لا أعتقد أنه من الممكن جعل عنوان URL الخاص بشبكة CDN يتصرف بهذه الطريقة؟ يُستخدم عنوان URL الخاص بشبكة CDN للصور فقط عند عرضها مضمنة، وليس عند تنزيلها. أيضًا، في حالة الصور والمرفقات الآمنة التي تحتوي على قائمة تحكم في الوصول (ACL) خاصة، يجب استخدام عنوان URL موقع التوقيع دائمًا.
@martin بخصوص روابط المرفقات، لا أرى كيف يمكن تعيينها دائمًا على “فرض التنزيل”. حاليًا، عند تحميل ملف غير صورة، يكون عنوان URL المعروض الناتج عنوان URL قصيرًا بدون المعلمة ?dl=1 والتي يتم حلها إلى قيمة السمة url للملف المحمل المقابل (وهو ليس عنوان URL موقع مسبقًا ويفشل أيضًا في حالتنا حيث أن عنوان URL ليس عنوان URL لشبكة توصيل المحتوى S3 ولكنه عنوان URL مُنشأ قد يعمل فقط لموفري S3 معينين).
هل هناك طريقة لفرض تنزيل المرفقات دائمًا، أم أن السلوك الحالي هو في الواقع خطأ؟
مع عنوان نقطة نهاية URL https://s3.de.ovh.cloud.net وعنوان URL لشبكة توصيل المحتوى (CDN) لـ S3 تم تكوينه إلى https://storage.de.ovh.cloud.net/v1/<some-unique-user-id>/<the-bucket-name>
عند حل عناوين URL القصيرة، يستخدم Discourse عنوان URL لنقطة النهاية لإنشاء عنوان URL الناتج (وهو ما يفشل نظرًا لأنه لا يتضمن معرف المستخدم الصحيح لـ OVH - الجزء الموجود في عنوان URL لشبكة توصيل المحتوى لـ S3).
ومع ذلك، فإن فرض عناوين URL القصيرة لتكون dl=1 سيؤدي إلى إنشاء عنوان URL موقع مسبقًا يعمل، وهو ما سيكون جيدًا بالنسبة لي.
لقد قمت بتعيين متغيرات البيئة هذه (الخاصة بـ S3) داخل ملف YAML للحاوية:
ربما يكون هذا خارج نطاق هذا الموضوع، ولكن إذا كان السلوك الحالي مقصودًا، فكيف أو أين يمكن للمرء تجاوز عرض الروابط المختصرة في الواجهة الأمامية؟ أفكر في مجرد الارتباط بعملية الطهي للمشاركات ثم إلحاق معلمة الاستعلام بالروابط المختصرة للمرفقات. أنا على دراية بكيفية كتابة إضافات JavaScript لـ Discourse، ولكن في معظم الأوقات أواجه صعوبة في العثور على الأداة (Widget) المناسبة لـ “إعادة فتح” أو تجاوز الدالة.
حسنًا، لقد وجدت المكان الذي يتم فيه إنشاء Markdown للمرفقات وبقدر ما أفهم واجهة برمجة تطبيقات المكون الإضافي، لا يمكن للمرء (بسهولة) تجاوزها (حتى أعتقد أنه لا ينبغي عليه فعل ذلك).
لذا فإن فكرتي الأولية بإضافة معلمة ?dl=1 إلى تلك الروابط تبدو وكأنها الطريقة الخاطئة للقيام بذلك.
تقديم الملفات من S3 عبر شبكة توصيل محتوى (CDN) (غير ممكن للمرفقات كما أشار @martin، حيث قد لا نتمكن من تعيين اسم الملف للتنزيل بشكل صحيح في هذه الحالة)
إنشاء عنوان URL موقع مسبقًا لكائن S3
لكن السلوك الحالي لا يفعل أيًا من الأمرين ويتوقع أن يكون لدلو S3 قائمة تحكم في الوصول عامة. هذا هو الحال أيضًا لموفري S3 المدعومين (بما في ذلك أمازون)، لذلك أتساءل لماذا لا نجعل خيار force_download في Discourse.store.url_for افتراضيًا إلى true عند حل الروابط المختصرة لمتاجر S3؟
نواجه نفس المشكلة مع Cloudflare R2، حيث يبدو أنها لا تسمح باستخدام عنوان URL المباشر لـ S3 بدون عنوان URL موقع مسبقًا.
ولا يدعم R2 قوائم التحكم في الوصول (ACL) للحاويات.