メールトークンが既に消費されているため、中断後のバックアップダウンロード再開ができません

Ethsim2 · 2026 年 8 月 31 日午前 9:38

2026.01.0-latest で修正されたような類似の問題を思い出しました。したがって、これは旧来の初期ダウンロード失敗ではなく、中断されたバックアップダウンロードからの復旧に関わる別の現在進行中の問題だと考えられます。

一度限りのバックアップリンクが、ブラウザによる中断されたダウンロードの再開を妨げていると考えるのは妥当ですが、単一のリンクでバックアップを2回ダウンロードすることはできません。そのため、一度失敗すると、ダウンロードの再開は Discourse 自身によってキャンセルされている可能性があります。

現在、この動作を現在の Discourse で正確に再現することができました。

再現手順

Safari (iOS) を使用して、以下のローカル Discourse バックアップをダウンロードしていました：

4,231,639,143 バイト

「ダウンロードは正常に進行していました。以下の値から増加している様子のスクリーンレコーディングがあります：」

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

313.3 MB から 317.8 MB へ

その後、Safari から約15秒間だけ離れました。

Safari に戻ると、ダウンロードは約以下の位置で停止していました：

319.8 MB

そして 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

つまり、初期の認証済みリクエストは、数 GB に及ぶ転送が実際に完了する前に、メールトークンを消費してしまいます。

その転送がその後中断された場合、Safari は例えば次のようなリクエストを行います：

Range: bytes=319799904-

しかし、そのリクエストは再び /admin/backups/… を通るため、メールトークンはすでに削除されています。

これが、私が捕捉した 422 を説明しているようです。

認証済みセッションに加えてバックアップトークンも必要とされるため、既存のトークンを無期限に再利用可能にするよう提案しているわけではありません。

むしろ、同じ認証済み管理者が、すでに認可された同じバックアップダウンロードを再開するための、何らかの範囲を限定された方法があるべきではないかと考えています。

例えば、同じユーザーとバックアップに関連付けられた短命なダウンロード認可などが考えられますが、メンテナー側により良い処理方法があるかもしれません。

なぜ iOS で再現しやすくなっているのか

この問題を顕在化した中断は、最近の iOS バージョンのユーザーからの報告と似ているようです。

Apple Community に少なくとも3つの報告が投稿されています：

古い報告

「Safari Background Downloads Failing After IOS 26 update」 — 2025年10月

Safari Background Downloads Failing After… - Apple Community

ユーザーは、iOS 26 にアップグレードした後、バックグラウンドで実行中に大きな Safari ダウンロードが失敗すると報告しています。また、iPhone 15 Pro を iOS 26 にアップグレードし、同じ動作を報告しています。

「Safari iOS Background Download Issue - Cancels on Minimize」 — 2025年12月

Safari iOS Background Download Issue - Ca… - Apple Community

iOS 26.1 を実行する iPhone 15 で報告されています。ダウンロードは正常に開始されますが、別のアプリに切り替えたり Safari を最小化したりするとキャンセルされます。

「Safari can’t complete a large download」 — 2026年4月

iOS 26.4 を実行する iPhone 17 Pro Max で報告されています。大きなダウンロードは、デバイスをロックした直後、またはモバイル通信と Wi-Fi を切り替えた際に、 reportedly 一時停止するとのことです。著者は特に信号が良好であり、同じダウンロードは PC、Mac、Android では完了すると述べています。

これらのコミュニティ報告だけでは、Apple が iOS のリグレッションを確認したとは言えないと思います。

しかし、それらは私のスクリーンレコーディングと整合しています：バックアップは正常にダウンロードされており、私は一時的に Safari から離れ、戻った時点で転送が中断になっていたのです。

中断が発生した理由に関わらず、Discourse 側の重要なポイントは以下の通りです：

large backup transfer is interrupted

        ↓

browser attempts standards-based Range resume

        ↓

backup token has already been consumed

        ↓

resume receives 422

サーバーサイドの観察

これは現在の nginx/sendfile パスにおける一般的な問題ではないようです。

同じ数 GB のバックアップパスは、以下で正常に完了しています：

HTTP/3 を通じた Firefox/Linux から；および
同じ iPhone から Wi-Fi を使用した HTTP/3 を通じて。

現在の nginx もバイト範囲サポートを宣伝しています。

したがって、HTTP/3、Caddy、または nginx が本質的にバックアップを配信できないと提案しているわけではありません。

この特定の再現において、元の転送は約 320 MB で中断され、その後 Safari は有効なように見える Range リクエストを行い、その2番目のリクエストが Discourse によって拒否されました。

すでに認可されたバックアップダウンロードに対して、中断された転送後に同じファイルを同じ認証済み管理者が再開できるようにする、短命なメカニズムを持つのは理にかなっているでしょうか？

Ethsim2 · 2026 年 8 月 31 日午前 10:52

履歴と現在のテストカバレッジを確認し、修正時に何を保持すべきかをより深く理解しようとしました。

この使い捨ての挙動は、2017年3月のセキュリティ強化の変更から来ています：

このコミットは、メールで送付されるバックアップダウンロードトークンを導入し、ダウンロードリクエストが認可された時点でトークンを即座に消費するようにしました。

現在の 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 は、ユーザーごとに1つのRedisトークンを保存し、有効期限は1日です。これは特定のバックアップに紐付けられるのではなく、ユーザースコープで管理されています。

このファイルの履歴を確認したところ、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

これらは、最初の有効なダウンロード、無効なトークン、無効または欠落しているバックアップID、および権限をカバーしていますが、中断された転送後の 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

したがって、可能なパッチの方向性は、バックアップダウンロードの開始には既存の使い捨てメールトークンを保持しつつ、すでに認可されたローカルバックアップに対して、別個の短命なレジューム認可を提供することのように思われます。

そのようなレジューム認可は、認証済みユーザーと特定のバックアップに厳密にスコープされ、元の1日間のユーザー全体で有効なメールトークンを一般的に再利用可能にすることなく、後続のバイトレンジリクエストを許可するものになると予想されます。

保持・追加しようとする挙動は以下の通りです：

有効なメールトークンによる最初の GET は引き続き許可される；
消費済みのメールトークンによる別の通常の完全 GET は引き続き拒否される；
同じ認証済み管理者による同じバックアップのバイトレンジ再試行は、短い限定された期間内にレジュームできる；
他のバックアップに対するレジューム試行は引き続き拒否される；
期限切れのレジューム認可は引き続き拒否される。

これが必ずしもメンテイナーが好む実装であるとは仮定していませんが、コード/テストの範囲は比較的限定されているように見えます。

もしこの一般的なセキュリティモデルが合理的に思えるのであれば、Safariの Range: 再現のためのドラフトパッチと回帰テストを作成することに問題ありません。

Ethsim2 · 2026 年 8 月 31 日午後 2:28

この件について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 ヘッダーを含む後続のリクエスト。

消費済みのトークンを使用した通常の2回目の完全な GET は引き続き拒否されます。また、他のバックアップに対する Range リクエストも拒否されます。リモート/S3バックアップは既存の動作を維持します。

リジューム期間を無制限の期間ではなく、列挙型（enum）として定義しました:

Disabled
1 hour
6 hours (recommended)
12 hours
Until the original email token expires

有効なリジューム期間は、初期ダウンロードが開始された時点で、元のメール送信トークンの残存有効期間に制限されます。

後方互換性のために、現在のDiscourseの動作（Disabled）がデフォルトのまま維持されています。一方、リジューム可能なダウンロードが有効な場合、6 hours が推奨オプションとして提示されます。

このPRでは、この互換性を維持するデフォルトを維持すべきか、それともこの問題を修正する一環として、推奨されるリジューム可能な値をデフォルトとするべきかをメンテナーに尋ねています。

また、成功したリジュームパスと主な認可境界（以下を含む）に対する回帰テストカバレッジを追加しました:

通常のトークンの再利用が引き続き拒否されること;
バックアップをまたぐリジュームが引き続き拒否されること;
設定を無効にすると、直ちにさらなるリジュームが防止されること;
S3にローカルリジューム認可が与えられないこと; および
初期ダウンロードとそのリジュームが、バックアップダウンロードの監査エントリを1つだけ生成すること。

完全なCIスイートはパスしており、PRはレビュー準備完了です。

セキュリティモデル、特に6時間の推奨値とデフォルト設定に関するフィードバックをお待ちしています。

トピック		返信	表示
Downloads of the backups are not being initiated when clicking the link Support backups	9	344	2025 年 10 月 5 日
Download backup - email link only Support	26	5966	2023 年 12 月 30 日
Backup errors for download of image Support backups	3	122	2025 年 4 月 24 日
Downloading backup through the API always results in a 422 error Support	0	293	2023 年 2 月 22 日
HTTP Range support missing, cannot resume file download Feature	1	703	2022 年 8 月 9 日

関連トピック