The implementation preserves the existing one-use emailed token for initiating the download, while allowing local backups to create a separate bounded resume authorization scoped to:
the same authenticated administrator;
the same backup;
the same original token value; and
a subsequent request carrying a Range header.
An ordinary second full GET using the consumed token is still rejected, as is a Range request for another backup. Remote/S3 backups retain their existing behaviour.
I made the resume period an enum rather than an unrestricted duration:
Disabled
1 hour
6 hours (recommended)
12 hours
Until the original email token expires
The effective resume period is also capped to the remaining lifetime of the original emailed token when the initial download begins.
The current Discourse behaviour remains the default (Disabled) for backwards compatibility, while 6 hours is presented as the recommended option when resumable downloads are enabled.
The PR asks whether maintainers would prefer to retain that compatibility-preserving default, or make the recommended resumable value the default as part of fixing this issue.
I’ve also added regression coverage for the successful resume path and the main authorization boundaries, including:
ordinary token reuse remaining rejected;
cross-backup resume remaining rejected;
disabling the setting immediately preventing further resume;
S3 not receiving a local resume grant; and
the initial download and its resume producing only one backup-download audit entry.
The full CI suite is passing and the PR is ready for review.
Feedback on the security model, and particularly on the recommendation of 6 hours and the default setting, would be welcome.