لقد لاحظت أن الرموز التعبيرية تتعطل في موقع عام أقوم بتشغيله، وتم تعيين التحكم في الوصول إلى خاص وتم تمييزه على أنه آمن بالسبب access control post dictates security | source: post creator.
يقوم تشغيل مهمة uploads:secure_upload_analyse_and_update بإصلاح المشكلة ولكنها تحدث مرة أخرى بعد بضعة أيام. حدث هذا أيضًا مع شعار الموقع مرة واحدة ولكنه لم يحدث مرة أخرى أبدًا.
مرحباً @Wolftallemo، هذه مشكلة صعبة بعض الشيء عندما يتم دمج الرموز التعبيرية المخصصة (أو أي تحميل متاح للعامة قد يُستخدم في منشور) مع التحميلات الآمنة. منذ فترة، بدأنا في استخدام جدول UploadReference لمعرفة ما هو مرتبط بأي تحميل، ولكن عند الانتقال إلى هذا الجدول، قمنا بتعيين جميع أوقات created_at لتكون متماثلة. نتيجة لذلك، عندما نتحقق مما إذا كان الاستخدام الأول للتحميل عامًا أم لا لأغراض أمنية، يكون الترتيب خاطئًا في بعض الأحيان ونستخدم شيئًا خاطئًا، لأنه إذا كان كلا العنصرين لهما نفس created_at بالضبط، فإن PostgreSQL يقوم بعمله الخاص:
ذكرك لهذا جعلني أعيد فحص هذا الأمر مرة أخرى، وأعتقد أنه يمكننا التعامل مع هذا بشكل أفضل من خلال الترتيب حسب created_at ASC ثم id ASC، لذلك إذا كانت هناك أي من هذه التعارضات، فيجب استخدام السجل الأول الحقيقي.
إذا استمرت المشاكل بعد دمج هذا (سأحاول دمجه اليوم) وقمت بتحميل موقعك، فيمكننا مناقشة خيارات أخرى، ولكن لدي شك في أن هذه هي المشكلة بالنسبة لك. يمكنك تأكيد ذلك عن طريق القيام بذلك ومقارنة النتائج على موقعك:
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC")
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC, id ASC")
يجب أن يحتوي الأول على Post كـ target_type، ويجب أن يحتوي الثاني على CustomEmoji كنوع الهدف.
لقد بدأ يحدث مرة أخرى، ويبدو أنه نفس الرمز التعبيري في كل مرة.
هل يمكنك تشغيل الاستعلامات التي شاركها @martin في المنشور أعلاه؟
بالنظر إلى النتائج، أحصل في الواقع على العكس تمامًا (الأول يُرجع CustomEmoji والثاني يُرجع Post)
من المثير للاهتمام، أنه يعيد الشيء الصحيح إذن. بالنسبة للتحميل المرتبط، هل يمكنك نشر قيم security_last_changed_reason و security_last_changed_at ومعرفة ما إذا كان access_control_post_id ممتلئًا؟ لا ينبغي أن يميز هذا التحميل بأنه آمن عندما يكون المرجع الأول هو الرموز التعبيرية المخصصة. جرب هذا أيضًا:
Upload.find(ID)
.upload_references
.joins(<<~SQL)
LEFT JOIN posts ON upload_references.target_type = 'Post' AND upload_references.target_id = posts.id
SQL
.where("posts.deleted_at IS NULL")
.order("upload_references.created_at ASC, upload_references.id ASC")
.first
وانظر ما هو السجل الذي يعطيك إياه.
لقد حصلت على access control post dictates security | source: post creator بتاريخ Wed, 22 Mar 2023 09:13:10.341411000 UTC +00:00
لقد أعطاني معرف مركز تحكم لمنشور في فئة خاصة تم إنشاؤه منذ أكثر من ثلاث سنوات ولم يتم تعديله مطلقًا.
مثير للاهتمام، وهل تم استخدام الرمز التعبيري المخصص في هذا المنشور؟ ماذا يتم إرجاعه عند تشغيل رمز مرجع التحميل أعلاه مع معرف التحميل هذا؟ سيكون تشغيل هذا مع سجل التحميل ونشر النتيجة مفيدًا أيضًا:
UploadSecurity.new(upload).should_be_secure_with_reason
تم استخدامه في هذا المنشور
أعادت الاستعلام النتائج التالية:
id: 752,
upload_id: 236,
target_type: "Post",
target_id: 37246,
created_at: Mon, 25 Nov 2019 22:24:50.002473000 UTC +00:00,
updated_at: Sun, 29 May 2022 08:13:24.844072000 UTC +00:00
>
يشير target id إلى منشور لا يحتوي على الرموز التعبيرية على الإطلاق.
تعيد أمان التحميل [true, "access control post dictates security"]
هذا غير متوقع حقًا، وتشغيل هذا يجب أن يمنحك جميع التحميلات المرتبطة بالمشاركة عبر UploadReference:
UploadReference.where(
target_type: "Post",
target_id: 37246,
)
إذا كانت المشاركة تحتوي على مراجع ولكن لا يبدو أنها تحتوي على أي تحميلات في واجهة المستخدم، فربما كانت هناك مشكلة في الترحيل؟
اتضح أنني أخطأت في كتابة المعرف 
نعم، يحتوي على الرمز التعبيري، على الرغم من حذف الموضوع الأصلي.
حسنًا، لا مشكلة. إذن، إذا قمت بتشغيل هذا مرة أخرى مع التحميل الصحيح، فماذا تحصل؟
UploadSecurity.new(upload).should_be_secure_with_reason
و
upload
.upload_references
.joins(<<~SQL)
LEFT JOIN posts ON upload_references.target_type = 'Post' AND upload_references.target_id = posts.id
SQL
.where("posts.deleted_at IS NULL")
.order("upload_references.created_at ASC, upload_references.id ASC")
.first
إذا احتجنا حقًا إلى ذلك، يمكنك ببساطة تعيين تاريخ ووقت سجل UploadReference الخاص بـ CustomEmoji ليكون أقدم من أي سجل UploadReference آخر لهذا التحميل، ولكن لا ينبغي عليك القيام بذلك.
كان يجب أن أوضح. معرف التحميل كان صحيحًا، ولكن معرف المنشور لم يكن كذلك (وهذه هي الطريقة التي انتهى بي الأمر بها مع المنشور الذي لا يحتوي على الرموز التعبيرية - الرمز الذي لصقته هنا كان صحيحًا، لكنني أخطأت في كتابته عند محاولة العثور عليه)
كل الأوامر الأخرى لا تزال تُرجع نفس الشيء
إذا كان هذا هو الحال، فهناك بالفعل بعض الغرابة حول التواريخ، ربما بسبب الترحيل التلقائي الخاص بنا. قم بتشغيل هذا:
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC, id ASC")
للعثور على سجل UploadReference الذي يقول target_type: "CustomEmoji"، ثم قم بما يلي:
UploadReference.find(ID).update!(created_at: UploadReference.find(752).created_at - 1.day))
ثم قم بتشغيل هذا على التحميل الإشكالي:
upload.update_secure_status
ويجب حل المشكلة… أعتقد حقًا أن هذه ستكون مشكلة في الغالب مع التحميلات القديمة منذ هذا الترحيل. شيء آخر قد تتمكن من القيام به هو حذف الرموز التعبيرية المخصصة، وإعادة تحميلها، ثم تشغيل:
Jobs.enqueue(:rebake_custom_emoji_posts, name: EMOJI_NAME)
تحديث التاريخ سيكون أسهل. آسف على هذه الإزعاج!
لم يعد الرموز التعبيرية آمنة بعد الآن 
أعتقد أنني سأكتشف ذلك بعد بضعة أيام ما إذا كانت قد نجحت بالفعل أم لا
مرحباً @Wolftallemo 
هل نجحت هذه معك؟
لم ينكسر شيء بعد