Il download del backup non può essere ripreso dopo un'interruzione perché il token email è già stato consumato

Ethsim2 · 31 Agosto 2026, 9:38am

Ricordo un problema simile che sembra essere stato risolto in 2026.01.0-latest, quindi credo che si tratti di un problema attuale e distinto, legato al ripristino di un download di backup interrotto, piuttosto che al vecchio errore di download iniziale.

È plausibile pensare che il link di backup a tempo limitato possa impedire al browser di riprendere un download interrotto, ma non è possibile scaricare un backup due volte con un singolo link. Quindi, quando fallisce una volta, la ripresa del download viene probabilmente annullata da Discourse stesso.

Sono ora riuscito a riprodurre esattamente quel comportamento sull’attuale versione di Discourse.

Riproduzione

Stavo scaricando un backup locale di Discourse di:

4.231.639.143 byte

utilizzando Safari su iOS.

Il download stava procedendo normalmente. Ho una registrazione dello schermo che mostra l'aumento da circa:

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

313,3 MB a 317,8 MB

Ho poi lasciato Safari per circa 15 secondi.

Quando sono tornato su Safari, il download si era fermato a circa:

319,8 MB

e Safari mostrava il controllo per il nuovo tentativo.

Il log di accesso di Caddy per la richiesta originale mostra:

GET /admin/backups/...

HTTP/3

Range: none

status: 200

Content-Length: 4231639143

size: 319864024

Ho poi utilizzato il controllo di nuovo tentativo di Safari stesso.

Safari ha effettuato una vera richiesta HTTP byte-range:

GET /admin/backups/...

HTTP/3

Range: bytes=319799904-

status: 422

Quindi Safari non stava semplicemente tentando un altro download completo. Stava correttamente cercando di riprendere il file esistente all’incirca nel punto in cui la precedente trasmissione si era interrotta.

Discourse ha rifiutato quella richiesta Range con 422.

Codice attuale di Discourse

Guardando l’attuale Admin::BackupsController#show, la sequenza è efficacemente:

EmailBackupToken.compare(current_user.id, token)

        ↓

find backup

        ↓

EmailBackupToken.del(current_user.id)

        ↓

send_file

Quindi la richiesta autenticata iniziale consuma il token email prima che la trasmissione di diversi gigabyte sia effettivamente completata.

Se quella trasmissione viene successivamente interrotta, Safari effettua un’altra richiesta come:

Range: bytes=319799904-

ma quella richiesta passa di nuovo attraverso /admin/backups/… e il token email è già stato eliminato.

Sembra che questo spieghi il 422 che ho catturato.

La sessione autenticata è ancora richiesta oltre al token di backup, quindi non sto suggerendo di rendere semplicemente riutilizzabile indefinitamente il token esistente.

Piuttosto, mi sto chiedendo se ci dovrebbe essere un modo limitato per lo stesso amministratore autenticato di riprendere lo stesso download di backup già autorizzato.

Ad esempio, potrebbe essere un’autorizzazione di download a breve durata associata allo stesso utente e backup, anche se i manutentori potrebbero avere un modo migliore per gestire questo.

Perché questo sta diventando più facile da riprodurre su iOS

L’interruzione che ha esposto questo problema sembra anche simile ai resoconti degli utenti di versioni recenti di iOS.

Ci sono almeno tre resoconti ospitati su Apple Community:

resoconti più vecchi

“Safari Background Downloads Failing After IOS 26 update” — Ottobre 2025

Safari Background Downloads Failing After… - Apple Community

L’utente riporta che i download più grandi di Safari falliscono quando vengono eseguiti in background dopo l’aggiornamento a iOS 26. Hanno anche aggiornato un iPhone 15 Pro a iOS 26 e riportato lo stesso comportamento.

“Safari iOS Background Download Issue - Cancels on Minimize” — Dicembre 2025

Safari iOS Background Download Issue - Ca… - Apple Community

Riportato su un iPhone 15 con iOS 26.1. I download iniziano normalmente ma vengono annullati dopo il passaggio a un’altra app o la minimizzazione di Safari.

“Safari can’t complete a large download” — Aprile 2026

Riportato su un iPhone 17 Pro Max con iOS 26.4. I download di grandi dimensioni si fermano brevemente dopo aver bloccato il dispositivo, lasciando Safari, o passando tra cellulare e Wi-Fi. L’autore riporta specificamente un buon segnale e dice che gli stessi download si completano su PC, Mac e Android.

Non credo che quei resoconti della comunità siano sufficienti per dire che Apple ha confermato una regressione di iOS.

Tuttavia, sono coerenti con la mia registrazione dello schermo: il backup stava scaricando normalmente, sono passato brevemente da Safari e quando sono tornato la trasmissione era diventata interrotta.

Il punto importante sul lato Discourse è indipendente dalla causa dell’interruzione:

la trasmissione del backup di grandi dimensioni è interrotta

        ↓

il browser tenta una ripresa Range basata sugli standard

        ↓

il token di backup è già stato consumato

        ↓

la ripresa riceve 422

Osservazioni lato server

Questo non sembra essere un problema generale con l’attuale percorso nginx/sendfile.

Lo stesso percorso di backup multi-GB ha completato con successo:

da Firefox/Linux tramite HTTP/3; e
dallo stesso iPhone tramite Wi-Fi usando HTTP/3.

L’attuale nginx pubblicizza anche il supporto per byte-range.

Quindi non sto suggerendo che HTTP/3, Caddy o nginx siano intrinsecamente incapaci di fornire il backup.

In questa particolare riproduzione, la trasmissione originale è stata interrotta dopo circa 320 MB, Safari ha successivamente effettuato una richiesta Range apparentemente valida, e quella seconda richiesta è stata rifiutata da Discourse.

Avrebbe senso che un download di backup già autorizzato avesse un meccanismo a breve durata che consenta allo stesso amministratore autenticato di riprendere quello stesso file dopo una trasmissione interrotta?

Ethsim2 · 31 Agosto 2026, 10:52am

I had a look through the history and current test coverage to get a better idea of what a possible fix would need to preserve.

The one-use behaviour dates back to the March 2017 security-hardening change:

That commit introduced emailed backup-download tokens and also consumed the token immediately once the download request had been authorized.

The same ordering still exists in current 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

The underlying token implementation is also still very simple:

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 stores one Redis token per user with a one-day expiry. It is user-scoped rather than being tied to a particular backup.

Looking through that file’s history, the changes since 2017 appear to have been mechanical/style changes rather than changes to the authorization model.

That makes simply leaving the existing emailed token reusable seem undesirable: it would weaken the original one-use restriction, and the token itself is not scoped to the particular backup in the URL.

The current request tests are here:

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

They cover an initial valid download, invalid tokens, invalid/missing backup IDs and permissions, but I couldn’t find coverage for an interrupted transfer followed by a Range: request.

The API request spec likewise documents the ordinary filename + token download path:

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

A possible patch direction therefore seems to be to preserve the existing one-use email token for initiating the backup download, while providing a separate short-lived resume authorization for the already-authorized local backup.

I would expect such a resume authorization to be narrowly scoped to the authenticated user and specific backup, and to permit a subsequent byte-range request without making the original one-day user-wide email token generally reusable.

The behaviours I’d aim to preserve/add are:

initial GET with a valid emailed token remains allowed;
another ordinary full GET using the consumed email token remains rejected;
a byte-range retry for the same backup by the same authenticated admin can be resumed for a short bounded period;
a resume attempt against another backup remains rejected;
an expired resume authorization remains rejected.

I haven’t assumed that this is necessarily the implementation maintainers will prefer, but the code/test surface appears fairly contained.

I’m happy to put together a draft patch and regression tests for the Safari Range: reproduction if this general security model sounds reasonable.

Argomento		Risposte	Visualizzazioni
Network error on backup download Bug backups	31	946	Gennaio 4, 2026
Backup errors for download of image Support backups	3	110	Aprile 24, 2025
Downloads of the backups are not being initiated when clicking the link Support backups	9	331	Ottobre 5, 2025
Backup link send to mail failed to download Support	4	1716	Gennaio 5, 2018
Downloading backup through the API always results in a 422 error Support	0	290	Febbraio 22, 2023

Il download del backup non può essere ripreso dopo un'interruzione perché il token email è già stato consumato

Argomenti correlati