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

Ho dato un’occhiata allo storico e alla copertura dei test attuale per avere un’idea migliore di ciò che una possibile correzione dovrebbe preservare.

Il comportamento a uso singolo risale alla modifica di rafforzamento della sicurezza di marzo 2017:

Quel commit ha introdotto i token di download di backup inviati via e-mail e ha anche consumato immediatamente il token una volta che la richiesta di download era stata autorizzata.

La stessa sequenza esiste ancora nell’attuale 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

L’implementazione sottostante del token è ancora molto semplice:

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 memorizza un token Redis per utente con una scadenza di un giorno. È associato all’utente piuttosto che a un backup specifico.

Guardando lo storico di quel file, le modifiche dal 2017 sembrano essere state meccaniche/stilistiche piuttosto che modifiche al modello di autorizzazione.

Ciò rende indesiderabile il semplice rendere riutilizzabile il token via e-mail esistente: indebolirebbe la restrizione originale a uso singolo e il token stesso non è associato al backup specifico nell’URL.

I test delle richieste attuali si trovano qui:

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

Coprono un download iniziale valido, token non validi, ID di backup non validi/assenti e permessi, ma non sono riuscito a trovare copertura per un trasferimento interrotto seguito da una richiesta Range:.

Lo spec delle richieste API documenta anch’esso il percorso ordinario di download di nome file + token:

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

Una possibile direzione per la patch sembra quindi essere quella di preservare il token e-mail a uso singolo esistente per l’avvio del download del backup, fornendo al contempo un’autorizzazione di ripresa a breve scadenza per il backup locale già autorizzato.

Mi aspetto che tale autorizzazione di ripresa sia strettamente associata all’utente autenticato e al backup specifico e che consenta una successiva richiesta di intervallo di byte senza rendere generalmente riutilizzabile il token e-mail a uso singolo di un giorno per l’utente.

I comportamenti che mirerei a preservare/aggiungere sono:

la GET iniziale con un token e-mail valido rimane consentita;
un’altra GET completa ordinaria che utilizza il token e-mail consumato rimane rifiutata;
un nuovo tentativo di intervallo di byte per lo stesso backup da parte dello stesso amministratore autenticato può essere ripreso per un breve periodo limitato;
un tentativo di ripresa contro un altro backup rimane rifiutato;
un’autorizzazione di ripresa scaduta rimane rifiutata.

Non ho dato per scontato che questa sia necessariamente l’implementazione che i maintainer preferiranno, ma la superficie del codice/test sembra piuttosto contenuta.

Sono lieto di preparare una bozza di patch e test di regressione per la riproduzione di Range: di Safari se questo modello di sicurezza generale sembra ragionevole.

Ethsim2 · 31 Agosto 2026, 2:28pm

Ho appena preparato una PR per questo:

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.

L’implementazione preserva il token email a uso singolo esistente per iniziare il download, consentendo al contempo ai backup locali di creare un’autorizzazione di ripresa separata e limitata, vincolata a:

lo stesso amministratore autenticato;
lo stesso backup;
lo stesso valore del token originale; e
una richiesta successiva che includa un header Range.

Una seconda richiesta GET completa ordinaria utilizzando il token già consumato viene ancora rifiutata, così come una richiesta Range per un altro backup. I backup remoti/S3 mantengono il loro comportamento esistente.

Ho reso il periodo di ripresa un enum anziché una durata illimitata:

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

Il periodo di ripresa effettivo è inoltre limitato alla durata residua del token email originale al momento dell’inizio del download iniziale.

Il comportamento attuale di Discourse rimane l’impostazione predefinita (Disabled) per motivi di compatibilità, mentre 6 hours viene presentata come opzione consigliata quando i download riprendibili sono abilitati.

La PR chiede se i maintainer preferiscano mantenere l’impostazione predefinita che preserva la compatibilità, oppure rendere il valore riprendibile consigliato l’impostazione predefinita come parte della risoluzione di questa issue.

Ho anche aggiunto una copertura di regressione per il percorso di ripresa riuscito e per i principali confini di autorizzazione, inclusi:

il rifiuto persistente del riutilizzo ordinario del token;
il rifiuto persistente della ripresa tra backup diversi;
la disattivazione immediata della configurazione che impedisce ulteriori riprese;
il fatto che S3 non riceva un’autorizzazione di ripresa locale; e
il fatto che il download iniziale e la sua ripresa generino un’unica voce di audit per il download del backup.

La suite CI completa è superata e la PR è pronta per la revisione.

Sarebbe gradito un feedback sul modello di sicurezza, in particolare sulla raccomandazione di 6 ore e sull’impostazione predefinita.

Argomento		Risposte	Visualizzazioni
Downloads of the backups are not being initiated when clicking the link Support backups	9	344	Ottobre 5, 2025
Download backup - email link only Support	26	5966	Dicembre 30, 2023
Backup errors for download of image Support backups	3	122	Aprile 24, 2025
Downloading backup through the API always results in a 422 error Support	0	293	Febbraio 22, 2023
HTTP Range support missing, cannot resume file download Feature	1	703	Agosto 9, 2022

Argomenti correlati