Ich habe gesehen, dass Emojis auf einer öffentlichen Website, die ich betreibe, fehlerhaft sind. Die Zugriffskontrolle ist auf „privat“ gesetzt und als „sicher“ markiert, mit dem Grund access control post dictates security | source: post creator.
Das Ausführen der Aufgabe uploads:secure_upload_analyse_and_update behebt das Problem, aber dann tritt es einige Tage später erneut auf. Dies geschah auch einmal mit dem Website-Logo, trat aber nie wieder auf.
Hallo @Wolftallemo , das ist ein ziemlich kniffliges Problem, wenn benutzerdefinierte Emojis (oder jeder öffentlich zugängliche Upload, der in einem Beitrag verwendet werden kann) und sichere Uploads kombiniert werden. Vor einiger Zeit haben wir eine UploadReference-Tabelle verwendet, um zu sehen, was mit was verknüpft ist. Als wir jedoch zu dieser Tabelle migriert haben, haben wir alle created_at-Datumsangaben auf dasselbe gesetzt. Die Folge davon ist, dass, wenn wir zu Sicherheitszwecken prüfen, ob die erste Verwendung eines Uploads öffentlich ist oder nicht, manchmal die Reihenfolge falsch ist und wir das Falsche verwenden, da PostgreSQL bei exakt demselben created_at sein eigenes Ding macht:
Ihre Erwähnung hat mich veranlasst, dies noch einmal zu untersuchen, und ich denke, wir können dies besser handhaben, indem wir zuerst nach created_at ASC und dann nach id ASC sortieren. Wenn es also Konflikte gibt, sollte der tatsächliche erste Datensatz verwendet werden.
Wenn die Probleme nach dem Mergen dieses Pull Requests (ich werde versuchen, ihn heute zu mergen) weiterhin bestehen und Sie Ihre Website hochgeladen haben, können wir weitere Optionen besprechen. Ich habe jedoch den Verdacht, dass dies das Problem bei Ihnen ist. Sie können dies bestätigen, indem Sie Folgendes tun und die Ergebnisse auf Ihrer Website vergleichen:
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")
Der erste sollte einen Post als target_type haben, der zweite sollte das CustomEmoji als Zieltyp haben.
Es passierte wieder, und es scheint jedes Mal dasselbe Emoji zu sein.
Können Sie die von @martin im obigen Beitrag geteilten Abfragen ausführen?
Ich erhalte tatsächlich das genaue Gegenteil (erst gibt es CustomEmoji und dann Post)
Interessant, dann gibt es das richtige Ergebnis zurück. Können Sie für den verknüpften Upload die Werte security_last_changed_reason und security_last_changed_at posten und sehen, ob access_control_post_id ausgefüllt ist? Es sollte diesen Upload nicht als sicher markieren, wenn die erste Referenz das benutzerdefinierte Emoji ist. Versuchen Sie auch Folgendes:
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
Und sehen Sie, welchen Datensatz es Ihnen gibt.
Ich habe Zugriffskontrolle Post diktiert Sicherheit | Quelle: Post-Ersteller mit dem Datum Mi, 22. März 2023 09:13:10.341411000 UTC +00:00 erhalten.
Es gab mir eine Kontrollposten-ID für einen Beitrag in einer privaten Kategorie, der vor über drei Jahren erstellt und nie bearbeitet wurde.
Interessant, und wurde das benutzerdefinierte Emoji in diesem Beitrag verwendet? Was wird zurückgegeben, wenn Sie den obigen Upload-Referenzcode mit dieser Upload-ID ausführen? Das Ausführen mit dem Upload-Datensatz und das Posten des Ergebnisses wäre ebenfalls hilfreich:
UploadSecurity.new(upload).should_be_secure_with_reason
Es wurde in diesem Beitrag verwendet
Die Abfrage gab Folgendes zurück:
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
>
Die Ziel-ID verweist auf einen Beitrag, der das Emoji überhaupt nicht enthält.
Upload-Sicherheit gibt [true, "access control post dictates security"] zurück
Das ist wirklich unerwartet. Wenn Sie dies ausführen, sollten Sie alle Uploads erhalten, die über UploadReference mit dem Beitrag verknüpft sind:
UploadReference.where(
target_type: "Post",
target_id: 37246,
)
Wenn der Beitrag Referenzen hat, aber in der Benutzeroberfläche keine Uploads zu haben scheint, gab es möglicherweise ein Migrationsproblem?
Turns out I typed the id wrong 
Ja, es enthält das Emoji, obwohl das übergeordnete Thema gelöscht wurde.
Heh, kein Problem. Was erhältst du also, wenn du das hier mit dem korrekten Upload erneut ausführst?
UploadSecurity.new(upload).should_be_secure_with_reason
Und
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
Wenn wir es wirklich müssen, könntest du einfach das created_at-Datum und die Uhrzeit des UploadReference-Eintrags von CustomEmoji auf einen früheren Zeitpunkt als alle anderen UploadReference-Einträge für diesen Upload setzen, aber das solltest du eigentlich nicht tun müssen.
Ich hätte das klarstellen sollen. Die Upload-ID war korrekt, die Post-ID nicht (was dazu führte, dass der Post das Emoji nicht enthielt – der, den ich hier eingefügt habe, war korrekt, aber ich habe ihn falsch eingegeben, als ich versuchte, ihn zu finden).
Alle anderen Befehle geben immer noch dasselbe zurück.
Wenn dies der Fall ist, gibt es tatsächlich einige Merkwürdigkeiten bei den Daten, die möglicherweise durch unsere automatische Migration verursacht wurden. Führen Sie Folgendes aus:
CustomEmoji.find_by(name: "success").upload.upload_references.order("created_at ASC, id ASC")
Um den UploadReference-Datensatz zu finden, der target_type: "CustomEmoji" angibt, führen Sie dann Folgendes aus:
UploadReference.find(ID).update!(created_at: UploadReference.find(752).created_at - 1.day))
Führen Sie dann Folgendes für den problematischen Upload aus:
upload.update_secure_status
Und es sollte behoben sein… Ich glaube wirklich, dass dies hauptsächlich ein Problem mit älteren Uploads seit dieser Migration sein wird. Eine andere Sache, die Sie tun könnten, ist, das benutzerdefinierte Emoji zu löschen, es erneut hochzuladen und dann Folgendes auszuführen:
Jobs.enqueue(:rebake_custom_emoji_posts, name: EMOJI_NAME)
Die Aktualisierung des Datums wird jedoch einfacher sein. Entschuldigung für die Umstände!
Für den Moment ist das Emoji nicht mehr sicher 
Ich werde in ein paar Tagen erfahren, ob es tatsächlich funktioniert hat oder nicht.
Hey @Wolftallemo 
Hat das für dich funktioniert?
Noch ist nichts kaputtgegangen