nathank
Juin 10, 2026, 3:14
1
Actuellement, je constate que cliquer sur le lien PDF lorsque l’aperçu PDF est actif tente de télécharger le fichier (ce qui n’est pas souhaité) au lieu de l’ouvrir dans un nouvel onglet.
Cela se produit dans le cadre d’un auto-hébergement simple (conteneur unique, sans CDN, sans S3, thème Horizon).
Ce problème a déjà été abordé ici :
david:
Ce problème devrait être résolu depuis SECURITY: Download allowlist for uploaded files · discourse/discourse@9c0642a · GitHub
Nous disposons désormais d’une logique centralisée pour déterminer quels fichiers doivent être affichés « en ligne ». Cela signifie que les fichiers PDF sont systématiquement affichés en ligne, tandis que certains types de fichiers moins sûrs sont systématiquement proposés en téléchargement. Ces modifications devraient fonctionner avec tous les types de stockage de fichiers (local et S3, avec ou sans CDN).
La raison pour laquelle cela pose problème est que les utilisateurs souhaitent souvent lire un PDF affiché en ligne dans la fenêtre entière, car l’iframe est très restrictive. Le téléchargement ajoute une étape inutilement gênante. De plus, un bouton de téléchargement est déjà présent dans la barre d’outils du visualiseur PDF dans l’iframe (du moins dans Chrome).
2 « J'aime »
Nous n’étions pas cohérents avec le type display selon que vous utilisiez S3 ou non. Cela devrait être corrigé par
main ← fix-inline-safe-uploads-local-store
approved 05:17PM - 14 Jul 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, and
it left simple self-hosted (single-container, no S3/CDN) sites unable to open
PDFs inline.
`UploadsController#send_file_local_upload` 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.
Inline-safe files are now served with `Content-Disposition: inline` by
default, mirroring the S3 store, while unsafe types (HTML, SVG, XML, ...) and
explicit downloads (`?dl=1`) keep the `attachment` disposition. The redundant
`params[:inline]` branch is removed, since inline-safe files are now inline by
default.
The `Content-Security-Policy: sandbox;` header stays on **every** response as
defense-in-depth: if the `is_inline_safe?` allowlist is ever wrong, the
sandbox forces an opaque origin and disables script execution so a
misclassified file cannot run as a document in our origin. It does not
interfere with inline viewing — `sandbox` sandboxes scripts *inside* the
served file, not the browser's native rendering of it. Chrome's built-in PDF
viewer and Firefox's pdf.js both render sandboxed PDFs identically to
unsandboxed ones, and images/audio/video decode natively regardless.
A spec locks the allowlist 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.
(cc @david )
Le fait qu’un clic sur un fichier s’ouvre automatiquement dans un autre onglet relève davantage d’une question #produit .
3 « J'aime »
david
Juillet 14, 2026, 5:14
5
Le correctif n’a pas encore été fusionné