# 이메일 토큰이 이미 사용되었기 때문에 중단된 백업 다운로드를 재개할 수 없습니다
**URL:** https://meta.discourse.org/t/backup-download-cannot-resume-after-interruption-because-email-token-has-already-been-consumed/411277
**Category:** Self-hosting
**Tags:** backups, nginx, ios, install
**Created:** [8월 31, 2026, 9:38오전 UTC](https://meta.discourse.org/t/backup-download-cannot-resume-after-interruption-because-email-token-has-already-been-consumed/411277 "2026-08-31T09:38:41Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [8월 31, 2026, 9:38오전 UTC](https://meta.discourse.org/t/backup-download-cannot-resume-after-interruption-because-email-token-has-already-been-consumed/411277/1 "2026-08-31T09:38:42Z")
이전 [백업 다운로드 문제](https://meta.discourse.org/t/network-error-on-backup-download/388578)가 2026.01.0-latest에서 수정된 것으로 보입니다. 현재 발생하는 문제는 과거의 초기 다운로드 실패와는 별개의 문제로, **중단된 백업 다운로드를 복구하는 것** 과 관련된 것으로 생각됩니다.
이전 논의에서 제기된 가능성 중 하나는 일회성 백업 링크가 브라우저가 중단된 다운로드를 재개하는 것을 방해할 수 있다는 것이었습니다. 첫 번째 요청이 링크를 소모한 후, 후속 재개 요청은 더 이상 인증되지 않을 수 있습니다.
현재 Discourse에서 해당 동작을 정확히 재현할 수 있었습니다.
**재현 방법**
저는 다음 크기의 로컬 Discourse 백업을 다운로드 중이었습니다:
4,231,639,143 바이트
iOS의 Safari를 사용했습니다.
> **다운로드가 정상적으로 진행되고 있었습니다. 대략 다음과 같이 증가하는 것을 보여주는 스크린 레코딩이 있습니다:**
>
> [https://youtube.com/shorts/\_Pjc-kxJ1OE?feature=shared](https://youtube.com/shorts/_Pjc-kxJ1OE?feature=shared)
313.3 MB에서 317.8 MB
그 후 저는 약 15초 동안만 Safari에서 다른 곳으로 전환했습니다.
Safari로 돌아왔을 때, 다운로드가 대략 다음 지점에서 멈춰 있었습니다:
319.8 MB
그리고 Safari에 재시도 컨트롤이 표시되었습니다.
* * *
원본 요청에 대한 Caddy 액세스 로그는 다음과 같습니다:
```plaintext
GET /admin/backups/...
HTTP/3
Range: none
status: 200
Content-Length: 4231639143
size: 319864024
```
그 후 저는 Safari의 자체 재시도 컨트롤을 사용했습니다.
Safari는 진정한 HTTP 바이트 범위 요청을 보냈습니다:
```plaintext
GET /admin/backups/...
HTTP/3
Range: bytes=319799904-
status: 422
```
즉, Safari는 단순히 전체 다운로드를 다시 시도한 것이 아니었습니다. 이전 전송이 중단된 지점에서 기존 파일을 재개하려고 올바르게 시도하고 있었습니다.
Discourse는 해당 Range 요청을 422로 거부했습니다.
**현재 Discourse 코드**
현재 [Admin::BackupsController#show](https://github.com/discourse/discourse/blob/main/app/controllers/admin/backups_controller.rb)를 살펴보면, 순서는 실질적으로 다음과 같습니다:
```plaintext
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 커뮤니티에 호스팅된 보고 사항이 적어도 3건 있습니다:
> **구 보고 사항**
>
> **“Safari Background Downloads Failing After IOS 26 update” — 2025년 10월**
>
> [Security Verification](https://discussions.apple.com/thread/256160022)
>
> 해당 사용자는 iOS 26로 업그레이드 후 백그라운드에서 실행될 때 큰 Safari 다운로드가 실패한다고 보고했습니다. 또한 iPhone 15 Pro를 iOS 26으로 업그레이드하고 동일한 동작을 보고했습니다.
>
> **“Safari iOS Background Download Issue - Cancels on Minimize” — 2025년 12월**
>
> [Security Verification](https://discussions.apple.com/thread/256211824)
>
> iOS 26.1이 설치된 iPhone 15에서 보고되었습니다. 다운로드가 정상적으로 시작되지만 다른 앱으로 전환하거나 Safari를 최소화하면 취소됩니다.
**“Safari can’t complete a large download” — 2026년 4월**
> **[Security Verification](https://discussions.apple.com/verify-human/verify.html?next=%2Fthread%2F256284144)**
>
> Security verification page to protect against malicious bots.
iOS 26.4가 설치된 iPhone 17 Pro Max에서 보고되었습니다. 큰 다운로드가 reportedly 장치가 잠금된 직후 또는 셀룰러와 Wi-Fi 사이를 전환할 때 잠시 멈춥니다. 작성자는 특히 신호가 좋으며 동일한 다운로드가 PC, Mac, Android에서는 완료된다고 구체적으로 보고했습니다.
저는 해당 커뮤니티 보고 사항만으로는 Apple이 iOS 회귀(regression)를 확인했다고 단정할 수 없다고 생각합니다.
그러나 그것들은 제 스크린 레코딩과 일치합니다: 백업이 정상적으로 다운로드되고 있었고, 저는 잠시 Safari에서 다른 곳으로 전환했으며, 돌아왔을 때 전송이 중단되어 있었습니다.
중단이 발생한 이유와 무관하게, Discourse 측의 중요한 지점은 다음과 같습니다:
```plaintext
큰 백업 전송이 중단됨
↓
브라우저가 표준 기반 Range 재개를 시도
↓
백업 토큰이 이미 소모됨
↓
재개 요청이 422 수신
```
**서버 측 관찰 사항**
이것은 현재 nginx/sendfile 경로와 관련된 일반적인 문제로 보이지 않습니다.
동일한 수 기가바이트 백업 경로는 성공적으로 완료되었습니다:
- Firefox/Linux에서 HTTP/3를 통해; 그리고
- 동일한 iPhone에서 Wi-Fi를 사용하여 HTTP/3를 통해.
현재 nginx도 바이트 범위 지원을 광고하고 있습니다.
따라서 HTTP/3, Caddy 또는 nginx가 본질적으로 백업을 전달할 수 없다는 것을 제안하는 것은 아닙니다.
이 특정 재현 사례에서, 원본 전송은 약 320 MB 후에 중단되었고, Safari는 이후 유효해 보이는 Range 요청을 보냈으며, 그 두 번째 요청은 Discourse에 의해 거부되었습니다.
이미 권한이 부여된 백업 다운로드가 중단된 전송 후 동일한 인증된 관리자가 동일한 파일을 재개할 수 있도록 하는 단기 메커니즘이 존재하는 것이 합리적일까요?
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [8월 31, 2026, 10:52오전 UTC](https://meta.discourse.org/t/backup-download-cannot-resume-after-interruption-because-email-token-has-already-been-consumed/411277/2 "2026-08-31T10:52:50Z")
히스토리와 현재 테스트 커버리지를 살펴보고, 가능한 수정 사항이 무엇을 보존해야 하는지 파악했습니다.
1회용 동작은 2017년 3월의 보안 강화 변경 사항으로 거슬러 올라갑니다:
>
>
> \- send email to logged in admin when they press the "download" button
> \- show pop…-up that email was sent
> \- create email template
> \- require a valid token to download backup
해당 커밋은 이메일로 전송되는 백업 다운로드 토큰을 도입했으며, 다운로드 요청이 승인되는 즉시 토큰을 소모하도록 했습니다.
현재 `Admin::BackupsController#show`에도 동일한 순서가 유지되고 있습니다:
>
기반이 되는 토큰 구현도 여전히 매우 단순합니다:
>
`EmailBackupToken`은 1일 만료 기간을 가진 사용자당 하나의 Redis 토큰을 저장합니다. 이는 특정 백업에 묶여 있지 않고 사용자 범위(user-scoped)로 설정되어 있습니다.
해당 파일의 히스토리를 살펴본 결과, 2017년 이후의 변경 사항은 인가 모델의 변경이 아닌 기계적/스타일 변경으로 보입니다.
따라서 기존 이메일 토큰을 재사용 가능하도록 두는 것은 바람직하지 않아 보입니다. 이는 원래의 1회용 제한을 약화시킬 뿐만 아니라, 토큰 자체가 URL의 특정 백업에 범위 지정되어 있지 않기 때문입니다.
현재 요청 테스트는 여기에 있습니다:
>
이 테스트들은 초기 유효한 다운로드, 잘못된 토큰, 유효하지 않거나 누락된 백업 ID 및 권한을 다루지만, 중단된 전송 후 `Range:` 요청에 대한 커버리지는 찾지 못했습니다.
API 요청 스펙도 마찬가지로 일반적인 파일명 + 토큰 다운로드 경로를 문서화하고 있습니다:
>
따라서 가능한 패치 방향은 기존 1회용 이메일 토큰을 백업 다운로드 **시작** 에 유지하는 한편, 이미 인가된 로컬 백업에 대해 별도의 단기 재개(resume) 인가를 제공하는 것으로 보입니다.
이러한 재개 인가는 인증된 사용자와 특정 백업에 좁게 범위 지정되고, 원래의 1일 사용자 전체 이메일 토큰을 일반적으로 재사용 가능하게 만들지 않으면서 후속 바이트 범위(byte-range) 요청을 허용할 것으로 기대됩니다.
저희가 보존/추가하려는 동작은 다음과 같습니다:
- 유효한 이메일 토큰이 포함된 초기 `GET`은 여전히 허용됩니다;
- 소모된 이메일 토큰을 사용한 또 다른 일반 전체 `GET`은 여전히 거부됩니다;
- 동일한 인증된 관리자가 동일한 백업에 대해 바이트 범위 재시도를 수행하면 짧은 제한된 기간 동안 재개할 수 있습니다;
- 다른 백업에 대한 재개 시도는 여전히 거부됩니다;
- 만료된 재개 인가는 여전히 거부됩니다.
이것이 유지보수자들이 선호할 구현 방식인지에 대해서는 가정하지 않았습니다만, 코드/테스트 범위는 비교적 제한적으로 보입니다.
이 일반적인 보안 모델이 합리적이라고 생각된다면, Safari `Range:` 재현을 위한 초안 패치와 회귀 테스트를 작성하는 데 기꺼이 참여하겠습니다.
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [8월 31, 2026, 2:28오후 UTC](https://meta.discourse.org/t/backup-download-cannot-resume-after-interruption-because-email-token-has-already-been-consumed/411277/3 "2026-08-31T14:28:37Z")
이와 관련하여 PR을 작성했습니다:
>
>
> \## 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:
>
> \
>
> The available values are deliberately bounded, with the compatibility-preserving default disabled and 6 hours identified as the recommended enabled option:
>
> \
>
> \### 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.
이 구현은 다운로드 **시작** 을 위해 기존에 사용되던 일회성 이메일 토큰을 유지하면서, 로컬 백업에 대해 다음 요소로 범위가 제한된 별도의 재개(resume) 인가를 생성할 수 있도록 합니다.
- 동일한 인증된 관리자;
- 동일한 백업;
- 동일한 원래 토큰 값; 그리고
- `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에는 로컬 재개 인가가 부여되지 않음; 그리고
- 초기 다운로드와 그 재개는 백업 다운로드 감사 항목(audit entry)을 하나만 생성함.
전체 CI 스위트가 통과하고 있으며, PR은 리뷰를 받을 준비가 되었습니다.
보안 모델, 특히 6시간 권장 사항과 기본 설정에 대한 피드백을 환영합니다.
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [9월 15, 2026, 2:47오후 UTC](https://meta.discourse.org/t/backup-download-cannot-resume-after-interruption-because-email-token-has-already-been-consumed/411277/4 "2026-09-15T14:47:03Z")
오늘 다시 한 번, 중단된 백업 다운로드를 재개할 수 있는 기능이 왜 유용한지를 보여주는 실제 사례를 경험했습니다. 이번에는 위에서 언급한 Safari 백그라운드 중단 재현 사례와는 다른 원인이었습니다.
저는 여행 중 iCabMobile 브라우저를 사용하여 셀룰러 데이터와 Speedify VPN 연결을 통해 iPhone에서 약 4GB 크기의 로컬 백업 파일을 다운로드하고 있었습니다.
이번에는 브라우저가 활성 상태로 유지되었습니다. 실패의 원인은 전화기가 잠기거나 브라우저가 백그라운드에서 일시중지된 것이 아니었습니다.
다운로드는 정상적으로 진행되어 대략 다음 지점까지 도달했습니다:
```plaintext
2.0 / 4.0 GB
2.4 / 4.0 GB
3.3 / 4.0 GB
3.4 / 4.0 GB
```
그 과정에서 상당한 처리량 저하가 발생했습니다. 한 시점에서 브라우저의 예상 남은 시간이 몇 분에서 1시간 이상으로 갑자기 증가했으며, 이후 전송이 복구되었습니다.
결국 대략 다음 지점까지 도달했습니다:
```plaintext
3.5 / 4.0 GB
```
그리고 iCab은 다음과 같이 보고했습니다:
```plaintext
The request timed out.
```
> **중단된 다운로드의 스크린샷**
>
> **14:34 - iCab은 전송이 3.3 / 4.0 GB에 있음을 표시하지만, 예상 남은 시간이 갑자기 01:07:55로 증가했습니다.**
>
> 
>
> * * *
>
> **14:34 - 거의 같은 시점의 Speedify는 셀룰러 다운로드 트래픽이 428.7 Kbps로까지 감소한 것을 보여줍니다.**
>
> 
>
> * * *
>
> **14:38 - iCab은 대략 3.5 / 4.0 GB에 도달한 후 요청이 시간 초과되었다고 보고합니다.**
>
> 
>
> * * *
>
> **14:38 - Speedify는 실패 발생 직전 거의 2시간 동안 연결된 이전 VPN 세션을 여전히 표시하고 있습니다.**
>
> 
>
> * * *
>
> **14:44 - Speedify 연결 지속 시간이 4:37로 리셋되어, 실패 후 VPN 터널이 재연결되었음을 나타냅니다.**
>
> 
따라서 Speedify 스크린샷은 VPN 터널이 이후에 재연결되었음을 나타냅니다: 실패 발생 직전에는 자체 호스팅 서버에 거의 2시간 동안 연결되어 있었으나, 14:44에는 연결 지속 시간이 `4:37`로만 표시되었습니다.
따라서 이것은 원래 재현 사례의 iOS 백그라운드 다운로드 동작이 아니라, 진정한 의미의 모바일/VPN 연결 중단으로 보입니다.
저는 아직 이 특정 시도에 대한 서버 로그를 확인하지 않았으므로, iCab이 이 시간 초과 후 `Range` 요청을 definitely 발급했다고 주장하지는 않습니다. 이전의 Safari 재현 사례는 이미 `Range: bytes=...-` 요청이 `422`를 수신하는 경우를 직접 입증했습니다.
이 사건이 저에게 보여준 것은, 이미 인증된 다운로드를 재개할 수 있도록 허용하는 것의 실용적 가치입니다. 4GB 백업 중 3.5GB가 전송된 후 발생하는 일시적인 셀룰러/VPN 중단은 이상적으로는 누락된 부분만 재전송해야 함을 의미해야 하며, 수 기가바이트짜리 다운로드를 처음부터 다시 시작해야 할 위험을 감수해야 함을 의미해서는 안 됩니다.
이것은 중단된 원래의 원인, 즉 iOS가 전송을 일시중지하여 연결이 끊기거나, 셀룰러 핸드오버로 인해 일시적인 장애가 발생하거나, VPN 터널이 재연결되는 경우와도 무관합니다. 브라우저가 표준 기반 바이트 범위 재개를 시도하는 순간, Discourse 측의 문제는 동일합니다.
저는 현재 프로덕션 인스턴스를 현재 업스트림 백업 다운로드 동작으로 유지하고 있으며, PR #43041의 병합되지 않은 인증 변경 사항을 로컬에 적용하지 않고 있으므로, 이것은 기존 일회용 토큰 동작에 대해 관찰된 것입니다.