بالنسبة لمنتدى خاص تمامًا (بدون وصول مجهول)، يبدو أن عدم وجود خيار وسائط آمن في تكوين التخزين المحلي الافتراضي إغفال كبير من وجهة نظري. لن أكون مندهشًا إذا كان الكثير من الأشخاص الذين يشغّلون منتديات خاصة لا يدركون أن جميع مرفقات منشوراتهم يمكن الوصول إليها علنًا (إذا عرفت عنوان URL). إذا كان نص منشوري لا يمكن الوصول إليه بشكل مجهول، فسأفترض بشكل حدسي أن مرفقات المنشور لا يمكن الوصول إليها أيضًا.
هل يستحق الأمر تقديم مشكلة تطلب ذلك لمعرفة نوع الدعم الذي سيحظى به؟ هل توجد مشكلة مماثلة بالفعل؟ تشكل هذه المشكلة حاليًا عائقًا أمام مجموعتنا الصغيرة المحدودة الموارد التي تحاول تشغيل Discourse في بيئة نمتلك فيها بالفعل أجهزة الاستضافة ولا نرغب في الدفع مقابل تخزين سحابي (خاصة بأسعار AWS S3) فقط لضمان عدم إمكانية مشاهدة وسائطنا بشكل مجهول.
أيضًا، سامحني على سذاجة هذا السؤال المحتمل. لكن هل يوجد بالفعل دعم لـ “buckets” منفصلة للuploads والنسخ الاحتياطية، أليس كذلك؟ هل سيكون من الصعب دعم bucket ثالث للuploads الآمنة؟ تذهب الuploads العامة إلى bucket العامة، وتذهب الuploads الآمنة إلى bucket الآمنة، ولا تكون هناك حاجة إلى قوائم تحكم بالوصول (ACLs) لكل كائن على حدة. وإذا تغيرت حالة الأمان لكائن ما، فيمكن ببساطة نقله بين الـ buckets؟
أعتقد أن الأمر يتطلب جهدًا كبيرًا. على الأقل يوم عمل، لكن ربما أسبوع؟
استضافة Cdck، التي تمول التطوير، تعمل مع التحميلات على S3، لذا فإن المواقع المستضافة ذاتيًا التي تتطلب تسجيل الدخول فقط والذين لا يملكون ميزانية لـ S3 هم المهتمون.
إذا رأى مستخدموك روابط مشاركة لمواردك، فيمكنهم ببساطة تنزيلها لمشاركتها. لا يبدو الأمر مشكلة كبيرة.
أنا لست مجنونًا لاعتقادي أن من الغريب أن يكون نص المنشور محميًا بينما المرفقات ليست كذلك، أليس كذلك؟
لكن هناك فرق كبير بين المشاركة المتعمدة والمشاركة العرضية. من الواضح أنه لا توجد طريقة حقيقية لمنع الأولى. أما الثانية فيمكن أن تحدث الآن ببساطة لأن الناس لا يفهمون التقنية الأساسية. فمثلاً، قد تُحوَّل إشعارات البريد الإلكتروني للمنشورات التي تتضمن روابط لصور مرفقة، دون قصد، إلى أشخاص غير أعضاء. وقد يكون خيار حذف المرفقات من رسائل البريد الإلكتروني، دون ربطه بوظيفة الوسائط الآمنة، بديلاً جيدًا في هذه الحالة.
حتى عندما يشارك الناس روابط المرفقات عمدًا، فقد يكونون ببساطة نسوا أن الرابط كان من فئة محمية. لكن في عالم مثالي، يجب أن تكون روابط المرفقات عديمة القيمة لأي شخص لا يملك صلاحية الوصول إلى تلك الفئة.
كما أن وجود خلل حالي أو مستقبلي في أحد تطبيقات S3 قد يسمح نظريًا بالعدّ المجهول للموارد في الدلو (bucket) أو بالقدرة على تخمين عناوين كائنات الوسائط وقصفها بالقوة الغاشمة. في عالم مثالي، أود أن يكون واجهتي S3 المحلية محمية بجدار ناري بعيدًا عن الإنترنت العام، بحيث لا يمكن الوصول إليها مباشرة إلا من قبل خادم Discourse.
لستَ مجنونًا، فتنفيذ تحميلات آمنة للإعدادات غير S3 ليس شيئًا أنا ضدّه بالتأكيد. الأمر فقط أننا لا نملك أيّ عجلة أو ضغط لبناء هذه الميزة، والتغيير ليس بسيطًا.
نحن نوظف أحيانًا متدربين وننفذ مشاريع تجريبية، وهذا بالتأكيد نوع من المشاريع يمكن أن يناسب إحدى هذه الفئات.
لدي حيلة سريعة أعتقد أنها ستوفر رفع ملفات آمن للمواقع التي تتطلب تسجيل الدخول.
بشكل أساسي، قم بإعداد Authentication Based on Subrequest Result | NGINX Documentation للرفع. المشكلة الوحيدة هي أنني لا أستطيع العثور على عنوان URL يُرجع خطأ 403/401 عند تفعيل خيار “يتطلب تسجيل الدخول”، لذا فإن محاولة الوصول إلى ملف مرفوع دون تسجيل الدخول تُنتج خطأ 500. هذا سيحدث فقط إذا كان لدى شخص ما عنوان URL للرفع وحاول الوصول إليه دون أن يكون مسجّل الدخول، لذا لا يبدو الأمر سيئًا جدًا.
الأمر يشبه هذا:
# JP
location = /auth {
internal;
proxy_pass http://discourse/categories;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
# END JP
location ~ ^/uploads/ {
auth_request /auth; #$JP
# ملاحظة: من المزعج حقًا أننا لا نستطيع ببساطة تعريف الرؤوس
# على المستوى الأعلى ووراثة القيم.
#
ليس لدينا خطط لإنشاء وظيفة دلو منفصلة للرفع الآمن، ولا نخطط لجعل الرفع الآمن يعمل مع الإعدادات غير S3 أو الإعدادات التي لا تحتوي على قوائم التحكم بالوصول (ACLs). قد ندرس القيام بذلك في المستقبل إذا كان هناك طلب كافٍ على هذا العمل لدرجة تجعل من المنطقي تخصيص الوقت والموارد لهذا الجهد.
لماذا تستخدم https://hashhackersforum.s3.us-east-2.amazonaws.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc بدلاً من https://forum.cdn.hashhackers.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc بينما أدخلت عنوان URL لشبكة CDN بشكل صحيح؟
لا يزعجني تجاهل هذه الرسالة، لكننا فعّلنا الوسائط الآمنة، مما يعني أنه لا يمكن استخدام شبكة توصيل محتوى (CDN). ربما لا ينبغي عرض هذه الرسالة على المواقع التي تم تفعيل خيار secure_media فيها.
آه… مكان آخر يصنع تحميلات آمنة لا ينبغي أن تكون كذلك. لا ينبغي وضع علامة ‘آمن’ على الشارات لأنها في الأساس صور عامة، مثل الصور الشخصية وشعارات الفئات وأشياء أخرى. سأحتاج إلى إجراء إصلاح للتأكد من عدم وضع علامة ‘آمن’ على صور الشارات، وسأحتاج أيضًا إلى سكريبت هجرة لإصلاح تلك التي تم وضع علامة ‘آمن’ عليها بالفعل.
أنا مندهش من أن هذا كان يعمل معك على الإطلاق، فلا شيء في الإصدار 2.8.0 كان يجب أن يؤثر على هذا.
شكرًا لك على ردك. هذه أول مرة أستخدم فيها لغة Ruby، وأنا معجب جدًا بوضوح هذه اللغة. بعد ساعات من تصحيح الأخطاء، أعتقد أنني وجدت المكان الذي يجب البحث فيه. أظن أنني فعلت العكس مما قلته لقد أضفت بعض الأسطر في نموذج Badge، والآن يمكنه تحميل الصور. أرى أيضًا أن لدينا علمًا for_site_setting هناك. أعتقد أنه يعتمد على هذه المعلومات لتعديل قائمة التحكم في الوصول (ACL) للكائنات على S3، وتحديد false لتلك العمود.
app/models/badge.rb
def image_url
if image_upload_id.present?
return upload_cdn_path(image_upload.url) if !image_upload.url.include?(SiteSetting.Upload.absolute_base_url)
uri = URI.parse(image_upload.url)
Rails.application.routes.url_for(
controller: "uploads",
action: "show_secure",
path: uri.path[1..-1],
only_path: true
)
end
end
سأقوم بمراجعة ما سيتغير في الترقية التالية لأتعلم المزيد عن ذلك.
هل يمكنك إخباري ما هي أفضل إصدار للاستخدام في الإنتاج؟
شكرًا لك!
آمل أن أتمكن من المساهمة أكثر في قاعدة الكود في المستقبل.
التغيير الذي قمت به في نموذج الشارة سيعمل بالتأكيد، ومن الرائع أنك تمكنت من إتمام ذلك في أول مرة تستخدم فيها Ruby! ومع ذلك، سأقوم بإصلاح المشكلة الأساسية حيث لا ينبغي أن تُعلَّم الشارات بأنها آمنة.
فرع tests-passed هو أفضل إصدار للاستخدام في الإنتاج لأنه سيحصل على جميع الإصلاحات الأحدث فور توفرها، رغم أن بعض الأشخاص قد يفضلون البقاء على فرع الاختبار التجريبي (beta) الذي يتلقى إصلاحات وتعديلات كل بضعة أسابيع تقريبًا.
سأخبرك عندما أكون قد أتممت إصلاح مشكلة اعتبار الشارات آمنة.
…ولكنني أتساءل ما إذا كانت المشكلة مرتبطة بتعليقك هنا؟
هل يُسمح للمستخدمين برفع صور رمزية عند تفعيل ميزة رفع الوسائط الآمنة؟ في الوقت الحالي، أواجه خطأً، ولكنني أتساءل عما إذا كان ذلك بسبب أن الصور الرمزية تُرفع إلى نفس الدلو الذي لا يُسمح فيه بالوصول العام…
إعجاب واحد (1)
Canapin
(Coin-coin le Canapin)
قسَّم هذا الموضوع في
126
لقد قمت مؤخرًا بإعادة تسمية “الوسائط الآمنة” والإعدادات ذات الصلة إلى “عمليات التحميل الآمنة” نظرًا لأنها لا تنطبق فقط على الصور/الفيديو وما إلى ذلك، والجميع يشير إليها بشكل عام باسم عمليات التحميل الآمنة على أي حال. الالتزام الأساسي ذو الصلة موجود هنا:
لقد أضفت بعض الأسطر في نموذج Badge، والآن يمكنه تحميل الصور. أرى أيضًا أن لدينا علمًا for_site_setting هناك. أعتقد أنه يعتمد على هذه المعلومات لتعديل قائمة التحكم في الوصول (ACL) للكائنات على S3، وتحديد false لتلك العمود.