Não é possível baixar relatórios exportados quando a mídia segura está ativada

Bug
1

Os anexos de relatórios exportados (testei com visualizações de página consolidadas) não são marcados como seguros, apesar de o arquivo ter uma ACL privada, o que impede o download, pois o URL curto apontava para um link não assinado. Após executar a tarefa uploads:secure_upload_analyse_and_update do Rake, ele foi devidamente marcado como seguro (havia outras 3 postagens/5 uploads também encontrados, mas não consegui determinar quais eram).

1 curtida
4

Você pode esclarecer o que você quer dizer com “anexo de relatório exportado”? Captura de tela?

1 curtida
5

Desculpe por isso, estou me referindo ao arquivo ZIP vinculado no pm enviado, pois a exportação foi concluída.

image
image464×169 11.1 KB

1 curtida
7

Isso é estranho, se eu tentar isso em um site de mídia segura, o upload é corretamente marcado como seguro. Você pode mostrar o registro de upload assim depois de tentar novamente?

#<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"
>

Seu site exige login?

1 curtida
8

Não é necessário fazer login

#<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

Nossa configuração de site secure_media é validada apenas contra o AWS S3. Esse pode ser o problema.

1 curtida
10

Esta é a parte estranha:

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

Para mim, com login_required false e secure_media true nas configurações do meu site, eu recebo isso quando exporto um relatório e ele é enviado para mim por mensagem privada:

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

Isso faz sentido porque o criador da postagem para a mensagem privada tem o upload anexado e, nesse ponto, ele deve ser definido como secure: true. Você tem um access_control_post_id nesse registro de upload, mas ele não parece ter funcionado corretamente?

O que acontece se você fizer Post.find(214238).with_secure_media?

Eu não acho que isso deveria afetar, isso só afetaria os ACLs, eu acho.

1 curtida
11

Isso não se aplicaria a todos os uploads potencialmente seguros? Considerando que postagens feitas em tópicos privados e outras mensagens privadas não têm esse problema, não tenho certeza sobre isso.

12

=> true

Hmm… Não tenho certeza do que aconteceu aqui então

13

Tão estranho, se eu adicionar um breakpoint dentro de PostCreator (que é chamado do job de exportação) eu obtenho um resultado semelhante ao seu no início para o 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"

Mas então, assim que a atualização do status seguro de PostCreator ocorre, tudo fica bem:

 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? retorna true para você?

  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

Sim, não vejo nenhum job em execução ou agendado no sidekiq, então presumo que ele falhou ou nunca foi executado.

15

Estou tão confuso :thinking: Há algo em sua página /logs que pareça relacionado a isso? Parece que a única maneira de isso estar acontecendo é se esse job do sidekiq update_post_uploads_secure_status estiver falhando ou dando erro de alguma forma.

16

Houve alguns erros, mas todos estavam relacionados ao job CleanUpUploads. Após uma investigação mais aprofundada, parece que o job nunca foi executado (não houve jobs falhos nos últimos 2 dias).

19

Desculpe, não consigo reproduzir isso, então não há muito mais que possamos fazer com isso por enquanto.

1 curtida