nathank
10 Junio, 2026 03:14
1
Actualmente, al hacer clic en el enlace de un PDF cuando la vista previa del PDF está activa, se intenta descargar el archivo (lo cual no es deseado) en lugar de abrirlo en una nueva pestaña.
Esto ocurre en una autohospedaje simple (un solo contenedor, sin CDN, sin S3, con el tema Horizon).
Todo esto ya se abordó anteriormente:
david:
Esto debería estar resuelto desde SECURITY: Download allowlist for uploaded files · discourse/discourse@9c0642a · GitHub
Ahora contamos con una lógica centralizada para determinar qué archivos deben mostrarse «en línea». Esto significa que los PDF se muestran consistentemente en línea, mientras que algunos tipos de archivos menos seguros se sirven siempre como descargas. Estos cambios deberían funcionar en todos los tipos de almacenamiento de archivos (local y S3, con o sin CDN).
El motivo por el que esto es un problema es que muchos usuarios desean leer un PDF en línea en toda la ventana, ya que el iframe es bastante restrictivo. Descargar añade un paso innecesariamente molesto. Además, ya existe un botón de descarga en la barra de herramientas del visor de PDF dentro del iframe (al menos en Chrome).
2 Me gusta
Hemos sido inconsistentes con el tipo display dependiendo de si se usaba S3 o no. Esto debería solucionarse con
main ← fix-inline-safe-uploads-local-store
drafted 02:09PM - 10 Jun 26 UTC
Inline-safe uploads (images, PDFs, audio and video) served from the local
file s… tore were sent with `Content-Disposition: attachment`, so clicking a
PDF link downloaded the file instead of opening it in the browser. This was
inconsistent with the S3 store, which already serves these files inline via
`FileStore::S3Store.content_disposition_for`, and it left simple self-hosted
(single-container, no S3/CDN) sites unable to open PDFs inline.
The cause was in `UploadsController#send_file_local_upload`: it only set the
disposition to `attachment` for unsafe types, and to `inline` when `?inline=1`
was passed, leaving it unset otherwise. Rails' `send_file` defaults an unset
disposition to `attachment`, so inline-safe files fell through to a download.
This serves inline-safe files with `Content-Disposition: inline` by default,
mirroring the S3 store. The `attachment` disposition and the `sandbox;`
Content-Security-Policy header are now scoped to the files that are actually
forced to download: unsafe types (HTML, SVG, XML, ...) and explicit downloads
(`?dl=1`). The redundant `params[:inline]` branch is removed, since inline-safe
files are now served inline by default.
The `is_inline_safe?` allowlist is the trusted layer keeping this safe: it
serves only (non-SVG) images, PDFs, audio and video inline, all of which the
browser decodes as media rather than parsing as a document. This is the same
posture the S3 store has always had, since S3 cannot attach a per-object CSP.
A spec now locks that invariant by asserting no inline-safe extension maps to
a script-capable content type, so re-adding something like SVG or XML to the
allowlist fails CI instead of becoming a stored XSS.
The blanket `sandbox;` CSP cannot be kept on inline-safe responses: it forces
an opaque, script-disabled context that stops the browser's PDF viewer from
rendering the in-post preview. `X-Content-Type-Options: nosniff`, already
applied to every response by `Middleware::DefaultHeaders`, stays in place so a
misclassified file cannot be reinterpreted as executable HTML in our origin.
(cc @david )
El hecho de que al hacer clic en un archivo se abra automáticamente en otra pestaña es más bien una pregunta de #producto .
3 Me gusta