Ho notato che le emoji si corrompono su un sito pubblico che gestisco. L’ACL è impostato su privato ed è contrassegnato come sicuro con la motivazione access control post dictates security | source: post creator.
L’esecuzione del task uploads:secure_upload_analyse_and_update risolve il problema, ma poi si ripresenta qualche giorno dopo. Questo è successo anche una volta con il logo del sito, ma non si è più verificato.
Ehi @Wolftallemo, questo è un problema piuttosto complicato quando le emoji personalizzate (o qualsiasi caricamento accessibile pubblicamente che potrebbe essere utilizzato in un post) e i caricamenti sicuri vengono combinati. Un po’ di tempo fa abbiamo iniziato a utilizzare una tabella UploadReference per vedere cosa è collegato a quale caricamento, tuttavia quando siamo migrati a questa tabella abbiamo impostato tutti i datetime di created_at allo stesso modo. La conseguenza è che quando verifichiamo se il primo utilizzo di un caricamento è pubblico o meno per motivi di sicurezza, a volte l’ordinamento è errato e utilizziamo la cosa sbagliata, poiché se entrambe le cose hanno esattamente lo stesso created_at, allora PostgreSQL fa semplicemente le sue cose:
La tua menzione di questo mi ha fatto riesaminare ancora una volta questo problema, e penso che possiamo gestirlo meglio ordinando su created_at ASC poi id ASC, quindi se ci sono conflitti, verrà utilizzato il record effettivo del primo utilizzo.
Se i problemi persistono dopo che questo sarà stato unito (cercherò di farlo unire oggi) e avrai caricato il tuo sito, allora potremo discutere ulteriori opzioni, ma ho il sospetto che questo sia il problema per te. Puoi confermarlo facendo questo e confrontando i risultati sul tuo sito:
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")
Il primo dovrebbe avere un Post come target_type, il secondo dovrebbe avere CustomEmoji come tipo di destinazione.
Ha ricominciato a succedere, e sembra essere sempre la stessa emoji.
Puoi eseguire le query che @martin ha condiviso nel post qui sopra?
Guardando i risultati sto ottenendo l’esatto contrario (il primo restituisce CustomEmoji e il secondo restituisce Post)
Interessante, quindi sta restituendo la cosa giusta. Per l’upload collegato, puoi pubblicare i valori di security_last_changed_reason e security_last_changed_at e vedere se access_control_post_id è compilato? Non dovrebbe contrassegnare quell’upload come sicuro quando il primo riferimento è l’emoji personalizzata. Prova anche questo:
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
E vedi quale record ti restituisce.
Ho ricevuto controllo di accesso post detta sicurezza | source: creatore del post con data Mer, 22 Mar 2023 09:13:10.341411000 UTC +00:00
Mi ha fornito un ID del post di controllo per un post in una categoria privata creato oltre tre anni fa e mai modificato.
Interessante, e l’emoji personalizzata è stata utilizzata in quel post? Cosa viene restituito quando esegui il codice di riferimento dell’upload sopra con quell’ID di upload? Sarebbe utile anche eseguire questo con il record di upload e pubblicare il risultato:
UploadSecurity.new(upload).should_be_secure_with_reason
È stato utilizzato in quel post
La query ha restituito quanto segue:
=> #<UploadReference:0x0000ffffa6846100
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 di destinazione punta a un post che non contiene affatto l’emoji.
La sicurezza del caricamento restituisce [true, "access control post dictates security"]
Questo è davvero inaspettato, l’esecuzione di questo dovrebbe darti tutti gli upload collegati al post tramite UploadReference:
UploadReference.where(
target_type: "Post",
target_id: 37246,
)
Se il post ha dei riferimenti ma non sembra avere alcun upload nell’interfaccia utente, allora forse c’è stato un problema di migrazione?
A quanto pare ho digitato l’ID sbagliato 
Sì, contiene l’emoji, anche se l’argomento padre è stato eliminato.
Heh, nessun problema. Quindi, se esegui di nuovo questo con l’upload corretto, cosa ottieni?
UploadSecurity.new(upload).should_be_secure_with_reason
E
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
Se proprio dobbiamo, potresti impostare la data e l’ora di creazione del record UploadReference di CustomEmoji a un momento precedente a qualsiasi altro record UploadReference per quell’upload, ma non dovresti esserne obbligato.
Avrei dovuto chiarire. L’ID di caricamento era corretto, l’ID del post no (che è il motivo per cui il post non conteneva l’emoji: quello che ho incollato qui era corretto, ma l’ho digitato male mentre cercavo di trovarlo)
Tutti gli altri comandi restituiscono ancora la stessa cosa
Se questo è il caso, allora c’è davvero qualche stranezza riguardo alle date, possibilmente causata dalla nostra migrazione automatica. Esegui questo:
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC, id ASC")
Per trovare il record UploadReference che dice target_type: "CustomEmoji", quindi fai:
UploadReference.find(ID).update!(created_at: UploadReference.find(752).created_at - 1.day))
Quindi esegui questo sull’upload problematico:
upload.update_secure_status
E dovrebbe essere risolto… penso davvero che questo sarà principalmente un problema con gli upload più vecchi da questa migrazione. Un’altra cosa che potresti essere in grado di fare è eliminare l’emoji personalizzata, ricaricarla, quindi eseguire:
Jobs.enqueue(:rebake_custom_emoji_posts, name: EMOJI_NAME)
L’aggiornamento della data sarà comunque più facile. Mi dispiace per il pasticcio!
Per ora l’emoji non è più sicura 
Immagino che scoprirò tra qualche giorno se ha funzionato o meno
Ehi @Wolftallemo 
Ha funzionato per te?
Ancora nulla si è rotto