عنوان URL لـ S3 CDN غير مستخدم في التحميلات غير الصورية

Maybe related to S3 CDN URL ignored when uploading into posts.

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?

5 إعجابات

Hmmm there may possibly be an issue here @martin can you investigate? We should probably redirect to the CDN if possible.

5 إعجابات

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:

attachment; filename="#{upload.original_filename}"; filename*=UTF-8''#{upload.original_filename}

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.

إعجابَين (2)

@martin بخصوص روابط المرفقات، لا أرى كيف يمكن تعيينها دائمًا على “فرض التنزيل”. حاليًا، عند تحميل ملف غير صورة، يكون عنوان URL المعروض الناتج عنوان URL قصيرًا بدون المعلمة ?dl=1 والتي يتم حلها إلى قيمة السمة url للملف المحمل المقابل (وهو ليس عنوان URL موقع مسبقًا ويفشل أيضًا في حالتنا حيث أن عنوان URL ليس عنوان URL لشبكة توصيل المحتوى S3 ولكنه عنوان URL مُنشأ قد يعمل فقط لموفري S3 معينين).

هل هناك طريقة لفرض تنزيل المرفقات دائمًا، أم أن السلوك الحالي هو في الواقع خطأ؟

إعجاب واحد (1)

هل يمكنك التوسع هنا، هل تستخدم Amazon S3، أم مزودًا مختلفًا؟ إذا كان الأمر كذلك، فأي واحد؟

إعجاب واحد (1)

نعم، يبدو أنني أستخدم مزود S3 غير مدعوم (OVH Object Storage)

مع عنوان نقطة نهاية 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 للحاوية:

DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: DE
DISCOURSE_S3_ENDPOINT: https://s3.de.cloud.ovh.net
DISCOURSE_S3_ACCESS_KEY_ID: ...
DISCOURSE_S3_SECRET_ACCESS_KEY: ...
DISCOURSE_S3_CDN_URL: https://storage.de.ovh.cloud.net/v1/<some-unique-user-id>/<the-bucket-name>
DISCOURSE_S3_UPLOAD_BUCKET: <the-bucket-name>
DISCOURSE_S3_INSTALL_CORS_RULE: false
إعجاب واحد (1)

ربما يكون هذا خارج نطاق هذا الموضوع، ولكن إذا كان السلوك الحالي مقصودًا، فكيف أو أين يمكن للمرء تجاوز عرض الروابط المختصرة في الواجهة الأمامية؟ أفكر في مجرد الارتباط بعملية الطهي للمشاركات ثم إلحاق معلمة الاستعلام بالروابط المختصرة للمرفقات. أنا على دراية بكيفية كتابة إضافات JavaScript لـ Discourse، ولكن في معظم الأوقات أواجه صعوبة في العثور على الأداة (Widget) المناسبة لـ “إعادة فتح” أو تجاوز الدالة.

حسنًا، لقد وجدت المكان الذي يتم فيه إنشاء Markdown للمرفقات وبقدر ما أفهم واجهة برمجة تطبيقات المكون الإضافي، لا يمكن للمرء (بسهولة) تجاوزها (حتى أعتقد أنه لا ينبغي عليه فعل ذلك).

لذا فإن فكرتي الأولية بإضافة معلمة ?dl=1 إلى تلك الروابط تبدو وكأنها الطريقة الخاطئة للقيام بذلك.

فيما يتعلق بعدم فرض التنزيلات للروابط المختصرة التي تم حلها: إذا فهمت الحجة ضد قوائم التحكم في الوصول العامة على دلاء S3 بشكل صحيح، فيجب إما:

  1. تقديم الملفات من S3 عبر شبكة توصيل محتوى (CDN) (غير ممكن للمرفقات كما أشار @martin، حيث قد لا نتمكن من تعيين اسم الملف للتنزيل بشكل صحيح في هذه الحالة)
  2. إنشاء عنوان URL موقع مسبقًا لكائن S3

لكن السلوك الحالي لا يفعل أيًا من الأمرين ويتوقع أن يكون لدلو S3 قائمة تحكم في الوصول عامة. هذا هو الحال أيضًا لموفري S3 المدعومين (بما في ذلك أمازون)، لذلك أتساءل لماذا لا نجعل خيار force_download في Discourse.store.url_for افتراضيًا إلى true عند حل الروابط المختصرة لمتاجر S3؟

إعجاب واحد (1)

أواجه نفس المشكلة هنا، ما أتوقعه هو أن يتم تنزيل الملف الموجود خلف uploads/short-url أو إعادة توجيهه إلى عنوان URL الخاص بـ S3 CDN.

إعجابَين (2)

نواجه نفس المشكلة مع Cloudflare R2، حيث يبدو أنها لا تسمح باستخدام عنوان URL المباشر لـ S3 بدون عنوان URL موقع مسبقًا.
ولا يدعم R2 قوائم التحكم في الوصول (ACL) للحاويات.

يبدو أن “discourse” أضافت مؤخرًا “استخدام عنوان URL لشبكة توصيل المحتوى (CDN) لجميع التحميلات” مما يحل هذه المشكلة.