Impossibile scaricare i report esportati quando i media sicuri sono abilitati

Bug
1

Gli allegati dei report esportati (ho testato con viste consolidate della pagina) non sono contrassegnati come sicuri nonostante il file abbia un ACL privato, il che impedisce il download poiché l’URL breve puntava a un link non firmato. Dopo aver eseguito il task rake uploads:secure_upload_analyse_and_update, è stato correttamente contrassegnato come sicuro (c’erano altri 3 post/5 upload trovati ma non sono stato in grado di determinare quali fossero).

1 Mi Piace
4

Puoi chiarire cosa intendi per “allegato del report esportato”? Screenshot?

1 Mi Piace
5

Mi dispiace, mi riferisco al file ZIP collegato nel messaggio privato inviato poiché l’esportazione è terminata.

image
image464×169 11.1 KB

1 Mi Piace
7

È strano, se provo questo su un sito di media sicuro, l’upload viene correttamente contrassegnato come sicuro. Puoi mostrare il record di upload in questo modo dopo aver riprovato?

#<Upload:0x0000556ae80c5208
 id: 532362,
 user_id: 1436,
 original_filename: "consolidated-page-views-220318-031153-54.zip",
 filesize: 480,
 width: nil,
 height: nil,
 url: "//blah.zip",
 created_at: Fri, 18 Mar 2022 03:11:53.556489000 UTC +00:00,
 updated_at: Fri, 18 Mar 2022 03:11:53.842038000 UTC +00:00,
 sha1: "12345",
 origin: nil,
 retain_hours: nil,
 extension: "zip",
 thumbnail_width: nil,
 thumbnail_height: nil,
 etag: "12345",
 secure: true,
 access_control_post_id: 377702,
 original_sha1: "12345",
 verification_status: 1,
 animated: nil,
 security_last_changed_at: Fri, 18 Mar 2022 03:11:53.836860000 UTC +00:00,
 security_last_changed_reason: "login is required | source: post creator">

Il tuo sito richiede il login?

1 Mi Piace
8

Non è richiesto l’accesso

#<Upload:0x000055646d495a30
 id: 62749,
 user_id: 1,
 original_filename: "web-crawlers-220318-032906-26.zip",
 filesize: 3017,
 width: nil,
 height: nil,
 url:
  "//[nope].storage.googleapis.com/original/3X/6/7/679649f9c6d33541cf5f5d2c48c2ef514bde36a0.zip",
 created_at: Fri, 18 Mar 2022 03:29:07.114686000 UTC +00:00,
 updated_at: Fri, 18 Mar 2022 03:29:07.328592000 UTC +00:00,
 sha1: "679649f9c6d33541cf5f5d2c48c2ef514bde36a0",
 origin: nil,
 retain_hours: nil,
 extension: "zip",
 thumbnail_width: nil,
 thumbnail_height: nil,
 etag: "54f0df6d95a84d04877aa20f238c3b1e",
 secure: false,
 access_control_post_id: 214238,
 original_sha1: "5cc4f437505ae3a07bdd27bbe2653462de31db6d",
 verification_status: 1,
 animated: nil,
 security_last_changed_at: Fri, 18 Mar 2022 03:29:07.112534000 UTC +00:00,
 security_last_changed_reason: "no checks satisfied | source: upload creator">
9

La nostra impostazione del sito secure_media viene convalidata solo rispetto ad AWS S3. Questo potrebbe essere il problema.

1 Mi Piace
10

Questa è la parte strana:

security_last_changed_reason: "no checks satisfied | source: upload creator"

Per me, con login_required false e secure_media true nelle impostazioni del mio sito, ottengo questo quando esporto un report e mi viene inviato tramite PM:

security_last_changed_reason: "access control post dictates security | source: post creator"

Questo ha senso perché il creatore del post per il PM ha allegato l’upload e a quel punto dovrebbe essere impostato su secure: true. Hai un access_control_post_id su quel record di upload ma non sembra aver funzionato correttamente?

Cosa succede se esegui Post.find(214238).with_secure_media?

Non credo che dovrebbe influire, questo influirebbe solo sugli ACL, penso.

1 Mi Piace
11

Questo non si applicherebbe a tutti gli upload potenzialmente sicuri? Considerando che i post effettuati in argomenti privati e altri PM non hanno questo problema, non ne sono sicuro.

12

=> true

Hmm… Non sono sicuro di cosa sia successo qui allora

13

È così strano, se aggiungo un breakpoint all’interno di PostCreator (che viene chiamato dal job di esportazione) ottengo un risultato simile al tuo all’inizio per l’upload:

  secure: false,
  access_control_post_id: 67115,
...
  security_last_changed_at: Fri, 18 Mar 2022 04:14:42.292485000 UTC +00:00,
  security_last_changed_reason: "no checks satisfied | source: upload creator"

Ma poi, non appena avviene l’aggiornamento dello stato sicuro di PostCreator, tutto va bene:

 secure: true,
 access_control_post_id: 67115,
...
 security_last_changed_at: Fri, 18 Mar 2022 04:14:55.645303000 UTC +00:00,
 security_last_changed_reason: "access control post dictates security | source: post creator"

Discourse.store.external? restituisce true per te?

  def update_uploads_secure_status(source:)
    if Discourse.store.external?
      Jobs.enqueue(:update_post_uploads_secure_status, post_id: self.id, source: source)
    end
  end
14

Sì, non vedo processi in esecuzione o pianificati in sidekiq, quindi presumo che sia fallito o non sia mai stato eseguito.

15

Sono così confuso :thinking: C’è qualcosa nella tua pagina /logs che sembra correlato a questo? Sembra che l’unico modo in cui ciò potrebbe accadere sia se quel job sidekiq update_post_uploads_secure_status fallisse o generasse un errore in qualche modo.

16

Ci sono stati alcuni errori, ma erano tutti correlati al job CleanUpUploads. Indagando ulteriormente, sembra che il job non sia mai stato eseguito (non ci sono stati job falliti negli ultimi 2 giorni).

19

Mi dispiace, non sono in grado di riprodurlo, quindi non c’è molto altro che possiamo fare per ora.

1 Mi Piace