المرفقات المصدرة للتقارير (اختبرت مع طرق عرض الصفحات المجمعة) لا يتم تمييزها على أنها آمنة على الرغم من أن الملف لديه قائمة تحكم وصول خاصة، مما يمنع التنزيل لأن الرابط المختصر يشير إلى رابط غير موقع. بعد تشغيل مهمة uploads:secure_upload_analyse_and_update في rake، تم تمييزها بشكل صحيح على أنها آمنة (كانت هناك 3 منشورات أخرى/5 تحميلات تم العثور عليها أيضًا ولكن لم أتمكن من تحديد ماهيتها).
هل يمكنك توضيح ما تقصده بـ “مرفق التقرير المصدر”؟ لقطة شاشة؟
هذا غريب، إذا جربت هذا على موقع وسائط آمن، يتم تمييز التحميل بشكل آمن. هل يمكنك إظهار سجل التحميل بهذا الشكل بعد المحاولة مرة أخرى؟
#<Upload:0x0000556ae80c5208
id: 532362,
user_id: 1436,
original_filename: "consolidated-page-views-220318-031153-54.zip",
filesize: 480,
width: nil,
height: nil,
url: "//blah.zip",
created_at: Fri, 18 Mar 2022 03:11:53.556489000 UTC +00:00,
updated_at: Fri, 18 Mar 2022 03:11:53.842038000 UTC +00:00,
sha1: "12345",
origin: nil,
retain_hours: nil,
extension: "zip",
thumbnail_width: nil,
thumbnail_height: nil,
etag: "12345",
secure: true,
access_control_post_id: 377702,
original_sha1: "12345",
verification_status: 1,
animated: nil,
security_last_changed_at: Fri, 18 Mar 2022 03:11:53.836860000 UTC +00:00,
security_last_changed_reason: "login is required | source: post creator">
هل يتطلب موقعك تسجيل الدخول؟
لا يلزم تسجيل الدخول
#<Upload:0x000055646d495a30
id: 62749,
user_id: 1,
original_filename: "web-crawlers-220318-032906-26.zip",
filesize: 3017,
width: nil,
height: nil,
url:
"//[nope].storage.googleapis.com/original/3X/6/7/679649f9c6d33541cf5f5d2c48c2ef514bde36a0.zip",
created_at: Fri, 18 Mar 2022 03:29:07.114686000 UTC +00:00,
updated_at: Fri, 18 Mar 2022 03:29:07.328592000 UTC +00:00,
sha1: "679649f9c6d33541cf5f5d2c48c2ef514bde36a0",
origin: nil,
retain_hours: nil,
extension: "zip",
thumbnail_width: nil,
thumbnail_height: nil,
etag: "54f0df6d95a84d04877aa20f238c3b1e",
secure: false,
access_control_post_id: 214238,
original_sha1: "5cc4f437505ae3a07bdd27bbe2653462de31db6d",
verification_status: 1,
animated: nil,
security_last_changed_at: Fri, 18 Mar 2022 03:29:07.112534000 UTC +00:00,
security_last_changed_reason: "no checks satisfied | source: upload creator">
إعداد موقعنا secure_media يتم التحقق منه فقط مقابل AWS S3. قد تكون هذه هي المشكلة.
هذا هو الجزء الغريب:
security_last_changed_reason: "no checks satisfied | source: upload creator"
بالنسبة لي، مع login_required false و secure_media true في إعدادات موقعي، أحصل على هذا عند تصدير تقرير ويتم إرساله إلي عبر رسالة خاصة:
security_last_changed_reason: "access control post dictates security | source: post creator"
هذا منطقي لأن منشئ المنشور للرسالة الخاصة لديه المرفق مرفقًا، وعند تلك النقطة يجب تعيينه على secure: true. لديك access_control_post_id في سجل التحميل هذا ولكنه لا يبدو أنه يعمل بشكل صحيح؟
ماذا يحدث إذا قمت بتشغيل Post.find(214238).with_secure_media?
لا أعتقد أن هذا يجب أن يؤثر على ذلك، هذا سيؤثر فقط على قوائم التحكم في الوصول (ACLs) أعتقد.
ألن ينطبق هذا على جميع التحميلات الآمنة المحتملة؟ بالنظر إلى أن المشاركات التي تم إجراؤها في مواضيع خاصة ورسائل خاصة أخرى لا تواجه هذه المشكلة، لست متأكدًا من ذلك.
=> صحيح
هممم… لست متأكدًا مما حدث هنا إذن
غريب جدًا، إذا أضفت نقطة توقف داخل PostCreator (التي يتم استدعاؤها من مهمة التصدير) أحصل على نتيجة مشابهة لنتيجتك في البداية للتحميل:
secure: false,
access_control_post_id: 67115,
...
security_last_changed_at: Fri, 18 Mar 2022 04:14:42.292485000 UTC +00:00,
security_last_changed_reason: "no checks satisfied | source: upload creator"
ولكن بعد ذلك، بمجرد حدوث تحديث PostCreator لحالة الأمان، يصبح كل شيء على ما يرام:
secure: true,
access_control_post_id: 67115,
...
security_last_changed_at: Fri, 18 Mar 2022 04:14:55.645303000 UTC +00:00,
security_last_changed_reason: "access control post dictates security | source: post creator"
هل تُرجع Discourse.store.external? القيمة true لديك؟
def update_uploads_secure_status(source:)
if Discourse.store.external?
Jobs.enqueue(:update_post_uploads_secure_status, post_id: self.id, source: source)
end
end
نعم، لا أرى أي مهام قيد التشغيل أو مجدولة في sidekiq، لذا أفترض أنها فشلت أو لم يتم تشغيلها مطلقًا.
أنا مرتبك للغاية
هل هناك أي شيء في صفحة /logs الخاصة بك يبدو مرتبطًا بهذا؟ يبدو أن الطريقة الوحيدة التي يمكن أن يحدث بها هذا هي إذا كانت مهمة sidekiq update_post_uploads_secure_status تفشل أو تحدث بها أخطاء بطريقة ما.
كانت هناك بعض الأخطاء ولكنها كانت كلها متعلقة بمهمة CleanUpUploads. بعد مزيد من التحقيق، يبدو أن المهمة لم يتم تشغيلها أبدًا (لم تكن هناك وظائف فاشلة في اليومين الماضيين)
أنا آسف، لا يمكنني تكرار هذا، لذلك لا يوجد الكثير مما يمكننا فعله حيال ذلك في الوقت الحالي.
