At first I thought I had missed some configuration, but it’s reproducible here on meta: https://meta.discourse.org/uploads/short-url/dw1U4hctATusBlHsUmWQXeme66j.csv (uploaded here) is a 302 redirect to //assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv
Shouldn’t it redirect to https://d11a6trkgmumsb.cloudfront.net/original/3X/5/e/5ebb2cfb8cc907e8e8f7c6559a72d2f4a8ba2f8f.csv instead?
This is a little bit tricky, I had a look at this just now. Basically we are always downloading from S3 with a presigned URL if we are doing a “force download”, which is what happens when we are clicking on the attachment link or clicking on the Download button on an image. This is so the appropriate content-disposition headers can be added:
I do not think it is possible to make the CDN URL behave in this way? The CDN URL for images is only used when displaying them inline, not when downloading them. Also in the case of secure images and attachments which have a private ACL the presigned URL must always be used.
@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) للحاويات.