He estado viendo emojis que fallan en un sitio público que opero; el ACL está configurado como privado y está marcado como seguro con la razón access control post dictates security | source: post creator.
Ejecutar la tarea uploads:secure_upload_analyse_and_update soluciona el problema, pero luego vuelve a ocurrir unos días después. Esto también sucedió una vez con el logo del sitio, pero nunca volvió a ocurrir.
Hola @Wolftallemo , este es un problema un tanto complicado cuando los emojis personalizados (o cualquier carga accesible públicamente que pueda usarse en una publicación) y las cargas seguras se combinan. Hace un tiempo empezamos a usar una tabla UploadReference para ver qué está vinculado a qué carga, sin embargo, cuando migramos a esta tabla, establecimos todas las fechas y horas de created_at de la misma manera. La consecuencia de esto es que, cuando verificamos si el primer uso de una carga es público o no por motivos de seguridad, a veces el orden es incorrecto y usamos lo incorrecto, ya que si ambas cosas tienen exactamente el mismo created_at, entonces PostgreSQL simplemente hace lo suyo:
Tu mención de esto me hizo reexaminar esto una vez más, y creo que podemos manejar esto mejor ordenando por created_at ASC luego por id ASC, de modo que si hay alguno de estos conflictos, se use el registro real que fue primero.
Si los problemas persisten después de que esto se fusione (intentaré que se fusione hoy) y hayas cargado tu sitio, entonces podremos discutir más opciones, pero sospecho que este es el problema para ti. Puedes confirmarlo haciendo esto y comparando los resultados en tu sitio:
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")
El primero debería tener un Post como target_type, el segundo debería tener CustomEmoji como tipo de destino.
Volvió a suceder y parece ser el mismo emoji cada vez.
¿Puedes ejecutar las consultas que @martin compartió en la publicación anterior?
Estoy obteniendo exactamente lo contrario (el primero devuelve CustomEmoji y el segundo devuelve Post)
Interesante, entonces está devolviendo lo correcto. Para la carga enlazada, ¿puedes publicar los valores de security_last_changed_reason y security_last_changed_at y ver si access_control_post_id está relleno? No debería estar marcando esa carga como segura cuando la primera referencia es el emoji personalizado. Prueba esto también:
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
Y mira qué registro te da.
Tengo control de acceso post dicta seguridad | source: creador del post con fecha de mié, 22 mar 2023 09:13:10.341411000 UTC +00:00
Me dio un ID de control de post para un post en una categoría privada que se creó hace más de tres años y nunca se editó.
Interesante, ¿y se usó el emoji personalizado en esa publicación? ¿Qué se devuelve cuando ejecutas el código de referencia de carga anterior con ese ID de carga? Ejecutar esto con el registro de carga y publicar el resultado también sería útil:
UploadSecurity.new(upload).should_be_secure_with_reason
Se usó en esa publicación
La consulta devolvió lo siguiente:
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
>
El target_id apunta a una publicación que no contiene el emoji en absoluto.
La seguridad de la carga devuelve [true, "el control de acceso de la publicación dicta la seguridad"]
Eso es realmente inesperado, ejecutar esto debería darte todas las cargas vinculadas a la publicación a través de UploadReference:
UploadReference.where(
target_type: "Post",
target_id: 37246,
)
Si la publicación tiene referencias pero no parece tener ninguna carga en la interfaz de usuario, ¿entonces tal vez ha habido un problema de migración?
Resulta que escribí mal el id 
Sí, contiene el emoji, aunque el tema principal fue eliminado.
Je, no hay problema. Entonces, si ejecutas esto de nuevo con la carga correcta, ¿qué obtienes?
UploadSecurity.new(upload).should_be_secure_with_reason
Y
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
Si realmente necesitamos hacerlo, podrías simplemente establecer la fecha y hora de creación del registro UploadReference de CustomEmoji a una fecha anterior a cualquiera de los otros registros UploadReference para esa carga, pero no deberías tener que hacerlo.
Debería haberlo aclarado. El ID de carga era correcto, el ID de la publicación no lo era (que es como terminé con la publicación sin el emoji; el que pegué aquí era correcto, pero lo escribí mal al intentar encontrarlo).
Todos los demás comandos siguen devolviendo lo mismo.
Si este es el caso, entonces efectivamente hay algo extraño en las fechas, posiblemente causado por nuestra migración automática. Ejecuta esto:
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC, id ASC")
Para encontrar el registro de UploadReference que dice target_type: "CustomEmoji", luego haz:
UploadReference.find(ID).update!(created_at: UploadReference.find(752).created_at - 1.day))
Luego ejecuta esto en la carga problemática:
upload.update_secure_status
Y debería resolverse… Realmente creo que esto será principalmente un problema con cargas más antiguas desde esta migración. Otra cosa que podrías hacer es eliminar el emoji personalizado, volver a cargarlo y luego ejecutar:
Jobs.enqueue(:rebake_custom_emoji_posts, name: EMOJI_NAME)
La actualización de la fecha será más fácil, sin embargo. ¡Disculpa las molestias con esto!
Por ahora el emoji ya no es seguro 
Supongo que en unos días sabré si realmente funcionó o no.
Hola @Wolftallemo 
¿Te funcionó esto?
Nada se ha roto todavía