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

ربما يكون مرتبطًا بـ تجاهل عنوان URL الخاص بـ S3 CDN عند التحميل في المنشورات.

في البداية، ظننت أنني أغفلت بعض الإعدادات، لكن المشكلة قابلة للتكرار هنا في موقع 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 بدلاً من ذلك؟

5 إعجابات

هممم، قد يكون هناك مشكلة هنا @مارتن، هل يمكنك التحقيق؟ يجب علينا على الأرجح إعادة التوجيه إلى CDN إذا أمكن.

5 إعجابات

هذا الأمر معقد قليلاً، لقد ألقيت نظرة عليه للتو. بشكل أساسي، نقوم دائمًا بالتنزيل من S3 باستخدام عنوان URL موقع التوقيع عند إجراء “تنزيل قسري”، وهو ما يحدث عند النقر على رابط المرفق أو النقر على زر “تنزيل” في صورة. والسبب في ذلك هو إضافة رؤوس content-disposition المناسبة:

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

لا أعتقد أنه من الممكن جعل عنوان URL الخاص بشبكة CDN يتصرف بهذه الطريقة؟ يُستخدم عنوان URL الخاص بشبكة CDN للصور فقط عند عرضها مضمنة، وليس عند تنزيلها. أيضًا، في حالة الصور والمرفقات الآمنة التي تحتوي على قائمة تحكم في الوصول (ACL) خاصة، يجب استخدام عنوان URL موقع التوقيع دائمًا.

إعجابَين (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) لجميع التحميلات” مما يحل هذه المشكلة.