Загрузка резервной копии не может быть возобновлена после прерывания, так как токен электронной почты уже использован

Ethsim2 · 31.Август.2026 09:38:42

Я помню о подобной проблеме, которая, по всей видимости, была исправлена в версии 2026.01.0-latest, поэтому я считаю, что это отдельная актуальная проблема, связанная с восстановлением после прерванной загрузки резервной копии, а не со старой ошибкой при первоначальной загрузке.

Логично предположить, что одноразовая ссылка для резервного копирования может мешать браузеру возобновлять прерванную загрузку, но загрузить резервную копию дважды по одной ссылке невозможно. Таким образом, когда загрузка прерывается один раз, возобновление, вероятно, отменяется самим Discourse.

Мне удалось воспроизвести именно это поведение в текущей версии Discourse.

Воспроизведение

Я загружал локальную резервную копию Discourse размером:

4 231 639 143 байта

с помощью Safari на iOS.

Загрузка шла нормально. У меня есть запись экрана, показывающая увеличение с примерно:

https://youtube.com/shorts/_Pjc-kxJ1OE?feature=shared

313,3 МБ до 317,8 МБ

Затем я переключился с Safari примерно на 15 секунд.

Когда я вернулся в Safari, загрузка остановилась на отметке примерно:

319,8 МБ

и Safari отобразил элемент управления для повторной попытки.

В журнале доступа Caddy для исходного запроса видно:

GET /admin/backups/...

HTTP/3

Range: none

status: 200

Content-Length: 4231639143

size: 319864024

Затем я использовал собственный элемент управления повторной попытки в Safari.

Safari отправил реальный запрос HTTP на диапазон байтов:

GET /admin/backups/...

HTTP/3

Range: bytes=319799904-

status: 422

То есть Safari не просто пытался выполнить полную загрузку заново. Он корректно пытался возобновить загрузку существующего файла примерно с того места, где остановилась предыдущая передача.

Discourse отклонил этот запрос Range с кодом 422.

Текущий код Discourse

Если посмотреть на текущий Admin::BackupsController#show, последовательность действий выглядит следующим образом:

EmailBackupToken.compare(current_user.id, token)

        ↓

find backup

        ↓

EmailBackupToken.del(current_user.id)

        ↓

send_file

Таким образом, первоначальный аутентифицированный запрос потребляет токен электронной почты до того, как передача данных в несколько гигабайт действительно завершится.

Если эта передача впоследствии прерывается, Safari отправляет другой запрос, например:

Range: bytes=319799904-

но этот запрос снова проходит через /admin/backups/…, а токен электронной почты уже был удален.

Похоже, это объясняет код 422, который я зафиксировал.

Для этого по-прежнему требуется как аутентифицированная сессия, так и токен резервной копии, поэтому я не предлагаю просто сделать существующий токен неограниченно многоразовым.

Скорее, я задаюсь вопросом, не должно ли существовать какой-то ограниченный способ, позволяющий тому же аутентифицированному администратору возобновить загрузку той же уже одобренной резервной копии.

Например, это могло бы быть кратковременное разрешение на загрузку, связанное с тем же пользователем и резервной копией, хотя у разработчиков может быть лучший способ обработки этого вопроса.

Почему это стало легче воспроизвести на iOS

Прерывание, которое выявило эту проблему, также похоже на отчеты пользователей последних версий iOS.

В сообществе Apple размещено как минимум три отчета:

более старые отчеты

«Неудачные фоновые загрузки в Safari после обновления IOS 26» — октябрь 2025 г.

Safari Background Downloads Failing After… - Apple Community

Пользователь сообщает о неудачных крупных загрузках в Safari при работе в фоновом режиме после обновления до iOS 26. Он также обновил iPhone 15 Pro до iOS 26 и сообщил о том же поведении.

«Проблема фоновой загрузки в Safari iOS — отмена при сворачивании» — декабрь 2025 г.

Safari iOS Background Download Issue - Ca… - Apple Community

Сообщено на iPhone 15 с iOS 26.1. Загрузки начинаются нормально, но отменяются после переключения на другое приложение или сворачивания Safari.

«Safari не может завершить большую загрузку» — апрель 2026 г.

Сообщено на iPhone 17 Pro Max с iOS 26.4. По сообщениям, большие загрузки приостанавливаются вскоре после блокировки устройства, переключения между Safari или перехода с сотовой сети на Wi-Fi. Автор специально указывает на хороший сигнал и говорит, что те же загрузки завершаются на ПК, Mac и Android.

Я не думаю, что этих отчетов сообщества достаточно, чтобы утверждать, что Apple подтвердила регрессию в iOS.

Однако они согласуются с моей записью экрана: резервная копия загружалась нормально, я ненадолго переключился с Safari, и когда я вернулся, передача была прервана.

Важный момент со стороны Discourse не зависит от причины прерывания:

передача большой резервной копии прервана

        ↓

браузер пытается возобновить загрузку с использованием стандарта Range

        ↓

токен резервной копии уже был использован

        ↓

возобновление получает код 422

Наблюдения на стороне сервера

Похоже, это не является общей проблемой с текущим путем nginx/sendfile.

Тот же путь загрузки резервной копии в несколько ГБ успешно завершался:

из Firefox/Linux по HTTP/3; и
с того же iPhone по Wi-Fi с использованием HTTP/3.

Текущий nginx также заявляет о поддержке диапазонов байтов.

Поэтому я не утверждаю, что HTTP/3, Caddy или nginx внутренне неспособны доставить резервную копию.

В этом конкретном случае воспроизведения исходная передача была прервана после примерно 320 МБ, Safari впоследствии отправил корректный запрос Range, и этот второй запрос был отклонен Discourse.

Имело бы смысл предусмотреть какой-либо кратковременный механизм для уже одобренной загрузки резервной копии, позволяющий тому же аутентифицированному администратору возобновить загрузку того же файла после прерванной передачи?

Ethsim2 · 31.Август.2026 10:52:50

Я изучил историю изменений и текущее покрытие тестами, чтобы лучше понять, что необходимо сохранить при возможном исправлении.

Поведение «одноразового» использования восходит к изменению, направленному на повышение безопасности, от марта 2017 года:

В этом коммите были введены токены для загрузки резервных копий, отправляемые по электронной почте, а также реализовано немедленное расходование токена сразу после того, как запрос на загрузку был авторизован.

Та же последовательность действий сохраняется и в текущей реализации Admin::BackupsController#show:

github.com/discourse/discourse

app/controllers/admin/backups_controller.rb

main


      
          if !EmailBackupToken.compare(current_user.id, params.fetch(:token))
            @error = I18n.t("download_backup_mailer.no_token")
            return render layout: "no_ember", status: :unprocessable_entity, formats: [:html]
          end
          
          store = BackupRestore::BackupStore.create
          
          if backup = store.file(params.fetch(:id), include_download_source: true)
            EmailBackupToken.del(current_user.id)
            StaffActionLogger.new(current_user).log_backup_download(backup)
          
            if store.remote?
              redirect_to backup.source, allow_other_host: true
            else
              headers["Content-Length"] = File.size(backup.source).to_s
              send_file backup.source

Базовая реализация токенов также остается очень простой:

github.com/discourse/discourse

lib/email_backup_token.rb

main

# frozen_string_literal: true

class EmailBackupToken
  def self.key(user_id)
    "email-backup-token:#{user_id}"
  end

  def self.generate
    SecureRandom.hex
  end

  def self.set(user_id)
    token = generate
    Discourse.redis.setex key(user_id), 1.day.to_i, token
    token
  end

  def self.get(user_id)
    Discourse.redis.get key(user_id)
  end

This file has been truncated. show original

EmailBackupToken хранит один токен в Redis на каждого пользователя с сроком действия один день. Он привязан к пользователю, а не к конкретной резервной копии.

Изучив историю этого файла, я обнаружил, что изменения с 2017 года носят механический или стилистический характер, а не затрагивают модель авторизации.

Это делает нежелательным простое оставление существующего токена, отправленного по электронной почте, многоразовым: это ослабило бы первоначальное ограничение на одноразовое использование, а сам токен не привязан к конкретной резервной копии в URL.

Текущие тесты запросов находятся здесь:

github.com/discourse/discourse

spec/requests/admin/backups_controller_spec.rb

main


      
          describe "#show" do
            context "when logged in as an admin" do
              before { sign_in(admin) }
          
              it "uses send_file to transmit the backup" do
                token = EmailBackupToken.set(admin.id)
                create_backup_files(backup_filename)
          
                expect do
                  get "/admin/backups/#{backup_filename}.json", params: { token: token }
                end.to change { UserHistory.where(action: UserHistory.actions[:backup_download]).count }.by(
                  1,
                )
          
                expect(response.headers["Content-Length"]).to eq("11")
                expect(response.headers["Content-Disposition"]).to match(/attachment; filename/)
              end
          
              it "returns 422 when token is bad" do
                get "/admin/backups/#{backup_filename}.json", params: { token: "bad_value" }

This file has been truncated. show original

Они покрывают начальную корректную загрузку, недействительные токены, недействительные/отсутствующие идентификаторы резервных копий и разрешения, но я не смог найти покрытие для прерванной передачи, за которой следует запрос с заголовком Range:.

Спецификация запросов API также документирует обычный путь загрузки с использованием имени файла и токена:

github.com/discourse/discourse

spec/requests/api/backups_spec.rb

main


      
          
          get "Download backup" do
            tags "Backups"
            operationId "downloadBackup"
            consumes "application/json"
            expected_request_schema = nil
            parameter name: :filename, in: :path, type: :string, required: true
            parameter name: :token, in: :query, type: :string, required: true
          
            produces "application/json"
            response "200", "success response" do
              expected_response_schema = nil
          
              let(:filename) { backup_filename }
              let(:token) { EmailBackupToken.set(admin.id) }
          
              it_behaves_like "a JSON endpoint", 200 do
                let(:expected_response_schema) { expected_response_schema }
                let(:expected_request_schema) { expected_request_schema }
              end

This file has been truncated. show original

Таким образом, возможным направлением для патча кажется сохранение существующего одноразового токена по электронной почте для инициации загрузки резервной копии, при этом предоставляется отдельное кратковременное разрешение на возобновление для уже авторизованной локальной резервной копии.

Я ожидаю, что такое разрешение на возобновление будет иметь узкий охват, привязано к аутентифицированному пользователю и конкретной резервной копии, и позволит последующий запрос диапазона байтов, не делая исходный одноразовый токен по электронной почте, действующий в течение дня, общедоступным для повторного использования.

Поведения, которые я намерен сохранить/добавить:

начальная GET-запрос с действительным токеном по электронной почте по-прежнему разрешен;
другой обычный полный GET-запрос с использованием уже израсходованного токена по электронной почте по-прежнему отклоняется;
повторная попытка запроса диапазона байтов для той же резервной копии тем же аутентифицированным администратором может быть возобновлена в течение короткого ограниченного периода;
попытка возобновления для другой резервной копии по-прежнему отклоняется;
просроченное разрешение на возобновление по-прежнему отклоняется.

Я не предполагаю, что это обязательно будет реализацией, предпочтительной для мейнтейнеров, но область кода и тестов кажется достаточно ограниченной.

Я готов подготовить черновой патч и регрессионные тесты для воспроизведения проблемы с заголовком Range: в Safari, если эта общая модель безопасности кажется разумной.

Ethsim2 · 31.Август.2026 14:28:37

Я подготовил PR по этому вопросу:

github.com/discourse/discourse

FIX: Allow local backup downloads to resume (#43041)

main ← Ethsim12:fix-backup-download-resume

opened 12:34PM - 31 Aug 26 UTC

Ethsim12

+379 -4

## Summary Allows interrupted **local** backup downloads to resume with an HT…TP `Range` request after the one-use emailed backup token has been consumed. This addresses the case reported on Meta where a multi-GB local backup download was interrupted and the browser retried with `Range`, but the retry received `422` because `EmailBackupToken.del` had already consumed the token: https://meta.discourse.org/t/backup-download-cannot-resume-after-interruption-because-email-token-has-already-been-consumed/411277 ## Approach The existing emailed token remains the only way to initiate a backup download. When resumable local downloads are enabled, the first authorized **local** download creates a narrower resume grant which is scoped to: * the same authenticated administrator * the same backup * the same original emailed token value * requests carrying a `Range` header * a bounded expiry window The original `EmailBackupToken` is still consumed after the initial request. Ordinary reuse of that token for another full download remains rejected, and the resume grant cannot be used for a different backup or user. Remote/S3 backup downloads keep their existing presigned-URL redirect behavior and do not receive a local resume grant. A resumed request is treated as a continuation of the same authorized download, so it does not create a second `backup_download` staff action entry. ## Resume window setting Adds `backup_download_resume_window` as an enum rather than an unrestricted numeric duration, to avoid an administrator accidentally configuring an excessively long authorization window. Options are: * `disabled` * `1_hour` * `6_hours` — shown as **6 hours (recommended)** in the admin UI * `12_hours` * `until_email_token_expires` The effective resume TTL is capped to the remaining lifetime of the original emailed token when the initial download begins. The setting integrates with the existing backup settings and is only applicable to local storage: <img width="960" height="850" alt="Backup download resume window shown beneath the local backup location setting" src="https://github.com/user-attachments/assets/abbbdf04-e2f5-4d7d-b66a-1c73caddd583" /> The available values are deliberately bounded, with the compatibility-preserving default disabled and 6 hours identified as the recommended enabled option: <img width="341" height="426" alt="Backup download resume window enum showing Disabled, 1 hour, 6 hours recommended, 12 hours, and until the original email token expires" src="https://github.com/user-attachments/assets/4dd3dd5c-50e0-4df3-ac6e-9732b7878227" /> ### Default vs recommended value This PR intentionally distinguishes the **default** from the **recommended enabled option**. The current Discourse behavior is equivalent to `disabled`: once the emailed token is consumed by the initial request, a subsequent `Range` retry is rejected. To preserve existing behavior for current sites, this PR therefore keeps `disabled` as the default. For admins who choose to enable resumable local downloads, `6_hours` is labelled as the recommended enum option. There is precedent for preserving existing behavior when introducing an enum setting in #36014: the previously hard-coded calendar view remained the default value of the new enum setting. **Maintainer question:** given the concrete interrupted-download case in the linked Meta topic, would you prefer the default to remain `disabled` for backwards compatibility, or should the recommended `6_hours` option become the default as part of fixing the issue? By “recommended” here I mean the admin-facing recommendation attached to one enum option, not a separate setting or an unrestricted duration value. ## Tests Added coverage for: * default/disabled behavior remaining unchanged * successful same-backup `Range` resume when enabled * rejection of ordinary token reuse * rejection of cross-backup resume * immediate revocation when the setting is disabled * no local resume grant for S3 backups * one audit entry across the initial download and resume * resume-token user/backup scoping and Redis expiry * enum validation and TTL capping Local focused test run: `94 examples, 0 failures` Ruby, YAML, and i18n linters also pass.

Реализация сохраняет существующий одноразовый токен из письма для инициирования загрузки, но позволяет локальным резервным копиям создавать отдельный ограниченный токен возобновления, привязанный к:

тому же аутентифицированному администратору;
той же резервной копии;
тому же исходному значению токена; и
последующему запросу с заголовком Range.

Обычное повторное полное GET с использованным токеном по-прежнему отклоняется, как и запрос Range для другой резервной копии. Резервные копии в Remote/S3 сохраняют существующее поведение.

Я сделал период возобновления перечислением (enum), а не неограниченной длительностью:

Disabled (Отключено)
1 hour (1 час)
6 hours (recommended) (6 часов (рекомендуется))
12 hours (12 часов)
Until the original email token expires (До истечения срока действия исходного токена из письма)

Эффективный период возобновления также ограничивается оставшимся временем жизни исходного токена из письма на момент начала начальной загрузки.

Текущее поведение Discourse остаётся значением по умолчанию (Disabled) для обратной совместимости, тогда как 6 hours (6 часов) предлагается как рекомендуемый вариант при включении возобновляемых загрузок.

В PR спрашивается, предпочитают ли разработчики сохранить это значение по умолчанию, сохраняющее совместимость, или сделать рекомендуемое значение для возобновляемых загрузок значением по умолчанию в рамках исправления этой проблемы.

Я также добавил регрессионное покрытие для успешного пути возобновления и основных границ авторизации, включая:

повторное использование обычного токена по-прежнему отклоняется;
возобновление для другой резервной копии по-прежнему отклоняется;
отключение настройки немедленно предотвращает дальнейшее возобновление;
S3 не получает локальный токен возобновления; и
начальная загрузка и её возобновление создают только одну запись в журнале аудита загрузок резервных копий.

Полный набор тестов CI проходит успешно, и PR готов к ревью.

Буду рад получить обратную связь по модели безопасности, а в частности по рекомендации в 6 часов и значению по умолчанию.

Тема		Ответов	Просм.
Downloads of the backups are not being initiated when clicking the link Support backups	9	344	05.10.2025
Download backup - email link only Support	26	5966	30.12.2023
Backup errors for download of image Support backups	3	122	24.04.2025
Downloading backup through the API always results in a 422 error Support	0	293	22.02.2023
HTTP Range support missing, cannot resume file download Feature	1	703	09.08.2022

Связанные темы