No se pueden descargar los informes exportados cuando los medios seguros están habilitados

Error
1

Los archivos adjuntos de los informes exportados (probé con vistas consolidadas de páginas) no están marcados como seguros a pesar de que el archivo tiene una ACL privada, lo que impide la descarga ya que la URL corta apuntaba a un enlace no firmado. Después de ejecutar la tarea uploads:secure_upload_analyse_and_update de Rake, se marcó correctamente como seguro (también se encontraron otras 3 publicaciones/5 cargas, pero no pude determinar cuáles eran).

1 me gusta
4

¿Puedes aclarar a qué te refieres con “archivo adjunto de informe exportado”? ¿Captura de pantalla?

1 me gusta
5

Disculpa, me refiero al archivo ZIP enlazado en el mensaje privado enviado, ya que la exportación ha finalizado.

image
image464×169 11.1 KB

1 me gusta
7

Esto es extraño, si lo intento en un sitio de medios seguros, la carga se marca correctamente como segura. ¿Puede mostrar el registro de carga de esta manera después de intentarlo de nuevo?

#<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: "se requiere inicio de sesión | source: creador de la publicación"
>

¿Se requiere el inicio de sesión en su sitio?

1 me gusta
8

No se requiere inicio de sesión

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

Nuestra configuración del sitio secure_media solo se valida contra AWS S3. Ese podría ser el problema.

1 me gusta
10

Esta es la parte extraña:

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

Para mí, con login_required false y secure_media true en la configuración de mi sitio, obtengo esto cuando exporto un informe y se me envía por mensaje privado:

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

Esto tiene sentido porque el creador de la publicación para el mensaje privado tiene el archivo adjunto, y en ese momento debería establecerse en secure: true. Tienes un access_control_post_id en ese registro de carga, pero ¿no parece haber funcionado correctamente?

¿Qué sucede si haces Post.find(214238).with_secure_media?

No creo que eso deba afectarlo, creo que esto solo afectaría a las ACL.

1 me gusta
11

¿No se aplicaría esto a todas las cargas potencialmente seguras? Teniendo en cuenta que las publicaciones realizadas en temas privados y otros mensajes privados no tienen este problema, no estoy seguro de ello.

12

=> true

Hmm… No estoy seguro de lo que pasó aquí entonces

13

Qué extraño, si agrego un punto de interrupción dentro de PostCreator (que es llamado por el trabajo de exportación) obtengo un resultado similar al tuyo al principio para la carga:

  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"

Pero luego, tan pronto como ocurre la actualización del estado seguro de PostCreator, todo está bien:

 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? te devuelve true?

  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í, no veo ningún trabajo en ejecución o programado en Sidekiq, así que supongo que falló o nunca se ejecutó.

15

Estoy muy confundido :thinking: ¿Hay algo en tu página de /logs que parezca relacionado con esto? Parece que la única forma en que esto podría estar sucediendo es si ese trabajo de sidekiq update_post_uploads_secure_status está fallando o cometiendo un error de alguna manera.

16

Hubo algunos errores, pero todos estaban relacionados con el trabajo CleanUpUploads. Tras una investigación más profunda, parece que el trabajo nunca se ejecutó (no hubo trabajos fallidos en los últimos 2 días).

19

Lo siento, no puedo reproducir esto, así que no hay mucho más que podamos hacer con esto por ahora.

1 me gusta