J’ai vu des emojis se corrompre sur un site public que j’exploite. Le contrôle d’accès est défini sur privé et est marqué comme sécurisé avec la raison access control post dictates security | source: post creator.
L’exécution de la tâche uploads:secure_upload_analyse_and_update résout le problème, mais il se reproduit quelques jours plus tard. Cela s’est également produit une fois avec le logo du site, mais ne s’est plus jamais reproduit.
Salut @Wolftallemo , c’est un problème un peu délicat lorsque les emojis personnalisés (ou tout téléchargement accessible publiquement qui peut être utilisé dans un message) et les téléchargements sécurisés sont combinés. Il y a quelque temps, nous avons commencé à utiliser une table UploadReference pour voir ce qui est lié à quel téléchargement, cependant, lorsque nous avons migré vers cette table, nous avons défini toutes les dates/heures created_at de la même manière. La conséquence est que lorsque nous vérifions si la première utilisation d’un téléchargement est publique ou non à des fins de sécurité, l’ordre est parfois incorrect et nous utilisons la mauvaise chose, car si les deux éléments ont exactement le même created_at, alors PostgreSQL fait sa propre chose :
Votre mention de cela m’a fait réexaminer cela une fois de plus, et je pense que nous pouvons mieux gérer cela en ordonnant par created_at ASC puis par id ASC, donc s’il y a des conflits, le véritable premier enregistrement devrait être utilisé.
Si les problèmes persistent après la fusion de ceci (j’essaierai de la faire fusionner aujourd’hui) et que vous avez téléchargé votre site, nous pourrons discuter d’autres options, mais je soupçonne que c’est le problème pour vous. Vous pouvez le confirmer en faisant ceci et en comparant les résultats sur votre site :
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")
Le premier devrait avoir un Post comme target_type, le second devrait avoir le CustomEmoji comme type de cible.
Cela a recommencé, et il semble que ce soit toujours le même emoji.
Pouvez-vous exécuter les requêtes partagées par @martin dans le message ci-dessus ?
En regardant les résultats, j’obtiens en fait le contraire (le premier renvoie CustomEmoji et le second renvoie Post)
Intéressant, il renvoie donc la bonne chose. Pour le téléversement lié, pouvez-vous publier les valeurs security_last_changed_reason et security_last_changed_at et voir si access_control_post_id est renseigné ? Il ne devrait pas marquer ce téléversement comme sécurisé lorsque la première référence est l’emoji personnalisé. Essayez ceci aussi :
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
Et voyez quel enregistrement il vous donne.
J’ai obtenu access control post dictates security | source: post creator avec la date du Mer, 22 mars 2023 09:13:10.341411000 UTC +00:00
Cela m’a donné un identifiant de contrôle de publication pour une publication dans une catégorie privée qui a été créée il y a plus de trois ans et n’a jamais été modifiée.
Intéressant, et l’emoji personnalisé a-t-il été utilisé dans cette publication ? Que renvoie l’exécution du code de référence de téléchargement ci-dessus avec cet identifiant de téléchargement ? L’exécution de ceci avec l’enregistrement de téléchargement et la publication du résultat serait également utile :
UploadSecurity.new(upload).should_be_secure_with_reason
Il a été utilisé dans ce post
La requête a retourné ce qui suit :
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
>
L’id cible pointe vers un post qui ne contient pas du tout l’emoji.
La sécurité de l’upload retourne [true, "access control post dictates security"]
C’est vraiment inattendu, l’exécution de ceci devrait vous donner toutes les téléversements liés au message via UploadReference :
UploadReference.where(
target_type: "Post",
target_id: 37246,
)
Si le message a des références mais ne semble pas avoir de téléversements dans l’interface utilisateur, alors il y a peut-être eu un problème de migration ?
Il s’avère que j’ai mal tapé l’identifiant 
Oui, il contient l’emoji, bien que le sujet parent ait été supprimé.
Heh, pas de problème. Alors, si vous exécutez ceci à nouveau avec le bon upload, qu’obtenez-vous ?
UploadSecurity.new(upload).should_be_secure_with_reason
Et
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 nous en avons vraiment besoin, vous pourriez simplement définir la date et l’heure de création de l’enregistrement UploadReference de CustomEmoji à une date antérieure à tous les autres enregistrements UploadReference pour cet upload, mais vous ne devriez pas avoir à le faire.
J’aurais dû clarifier. L’identifiant de téléchargement était correct, l’identifiant de publication ne l’était pas (c’est ainsi que je me suis retrouvé avec la publication ne contenant pas l’emoji - celle que j’ai collée ici était correcte, mais je l’ai mal tapée en essayant de la trouver)\n\nToutes les autres commandes renvoient toujours la même chose
Si tel est le cas, il y a effectivement des bizarreries autour des dates, potentiellement causées par notre migration automatique. Exécutez ceci :
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC, id ASC")
Pour trouver l’enregistrement UploadReference qui indique target_type: "CustomEmoji", puis faites :
UploadReference.find(ID).update!(created_at: UploadReference.find(752).created_at - 1.day))
Ensuite, exécutez ceci sur le téléversement problématique :
upload.update_secure_status
Et cela devrait être résolu… Je pense vraiment que ce sera surtout un problème avec les anciens téléversements depuis cette migration. Une autre chose que vous pourriez faire est de supprimer l’emoji personnalisé, de le re-téléverser, puis d’exécuter :
Jobs.enqueue(:rebake_custom_emoji_posts, name: EMOJI_NAME)
La mise à jour de la date sera cependant plus facile. Désolé pour ce désagrément !
Pour l’instant, l’emoji n’est plus sécurisé 
Je suppose que je découvrirai dans quelques jours si cela a réellement fonctionné ou non.
Salut @Wolftallemo 
Est-ce que cela a fonctionné pour vous ?
Rien ne s’est encore cassé