nathank
10.Июнь.2026 03:14:15
1
Я обнаружил, что при активном предпросмотре PDF-файла нажатие на ссылку PDF в настоящее время пытается загрузить файл (что нежелательно), вместо того чтобы открыть его в новой вкладке.
Это происходит при простой самостоятельной установке (один контейнер, без CDN, без S3).
Вся эта проблема уже обсуждалась здесь:
david:
Это должно быть исправлено начиная с SECURITY: Download allowlist for uploaded files · discourse/discourse@9c0642a · GitHub
Теперь у нас есть централизованная логика для определения того, какие файлы должны отображаться «встроенно». Это означает, что PDF-файлы последовательно отображаются встроенно, а некоторые менее безопасные типы файлов последовательно предоставляются для загрузки. Эти изменения должны работать со всеми типами хранилищ загружаемых файлов (локальное и S3, с CDN и без).
2 лайка
Мы действовали непоследовательно с типом display в зависимости от того, используете ли вы S3 или нет. Это должно быть исправлено в
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.
(копию @david )
Тот факт, что при клике на файл он открывается автоматически в новой вкладке, скорее относится к вопросу product
3 лайка
david
14.Июль.2026 17:14:32
5
Исправление пока не объединено