تعذر استئناف تنزيل النسخة الاحتياطية بعد الانقطاع لأن رمز البريد الإلكتروني تم استهلاكه بالفعل

Ethsim2 · 31 أغسطس 2026، 9:38ص

تذكرت مشكلة مشابهة يبدو أنها تم إصلاحها في إصدار 2026.01.0-latest، لذا أعتقد أن هذه مشكلة حالية منفصلة تتعلق بالاسترداد من تنزيل نسخة احتياطية انقطع، وليس فشل التنزيل الأولي القديم.

من المعقول التفكير في أن رابط النسخة الاحتياطية الذي يُستخدم مرة واحدة قد يمنع المتصفح من استئناف التنزيل المنقطع، لكنك لا تستطيع تنزيل نسخة احتياطية مرتين باستخدام رابط واحد. لذا، عندما يفشل التنزيل مرة واحدة، على الأرجح يتم إلغاء استئناف التنزيل بواسطة Discourse نفسه.

لقد تمكنت الآن من إعادة إنتاج هذا السلوك بالضبط على إصدار Discourse الحالي.

إعادة الإنتاج

كنت أقوم بتنزيل نسخة احتياطية محلية لـ Discourse بحجم:

4,231,639,143 بايت

باستخدام Safari على iOS.

كان التنزيل يتم بشكل طبيعي. لدي تسجيل شاشة يُظهر زيادته من حوالي:

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

313.3 ميغابايت إلى 317.8 ميغابايت

ثم انتقلت من Safari لمدة حوالي 15 ثانية فقط.

عندما عدت إلى Safari، كان التنزيل قد توقف عند حوالي:

319.8 ميغابايت

وعرض 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

لذا، فإن الطلب المصادق عليه الأولي يستهلك رمز البريد الإلكتروني قبل أن يكتمل نقل البيانات الضخم (عدة جيجابايت) فعلياً.

إذا انقطع ذلك النقل لاحقاً، يقوم Safari بإصدار طلب آخر مثل:

Range: bytes=319799904-

لكن هذا الطلب يمر عبر /admin/backups/… مرة أخرى، وقد تم حذف رمز البريد الإلكتروني بالفعل.

يبدو أن هذا يفسر رمز الخطأ 422 الذي تم التقاطه.

لا يزال مطلوباً وجود جلسة مصادقة بالإضافة إلى رمز النسخة الاحتياطية، لذا لا أقترح ببساطة جعل الرمز الحالي قابلاً لإعادة الاستخدام بشكل غير محدود.

بدلاً من ذلك، أتساءل عما إذا كان ينبغي وجود طريقة محددة النطاق تسمح لنفس المسؤول المصادق عليه باستئناف تنزيل نفس النسخة الاحتياطية المصرح بها مسبقاً.

على سبيل المثال، قد يكون ذلك تفويض تنزيل قصير العمر مرتبطاً بنفس المستخدم والنسخة الاحتياطية، على الرغم من أن المطورين قد يكون لديهم طريقة أفضل للتعامل مع هذا.

لماذا أصبح من الأسهل إعادة إنتاج هذا على iOS

يبدو أن الانقطاع الذي كشف عن هذه المشكلة مشابه أيضاً لتقارير المستخدمين من إصدارات iOS الحديثة.

هناك على الأقل ثلاثة تقارير مستضافة على مجتمع Apple:

تقارير أقدم

«فشل التنزيلات في الخلفية في Safari بعد تحديث IOS 26» — أكتوبر 2025

Safari Background Downloads Failing After… - Apple Community

يُبلغ المستخدم عن فشل تنزيلات Safari الكبيرة عند تشغيلها في الخلفية بعد الترقية إلى iOS 26. كما قام بترقية iPhone 15 Pro إلى iOS 26 وأبلغ عن نفس السلوك.

«مشكلة تنزيل الخلفية في Safari iOS - الإلغاء عند التصغير» — ديسمبر 2025

Safari iOS Background Download Issue - Ca… - Apple Community

تم الإبلاغ عنها على iPhone 15 يعمل بنظام iOS 26.1. تبدأ التنزيلات بشكل طبيعي لكنها تُلغى بعد التحويل إلى تطبيق آخر أو تصغير Safari.

«لا يمكن لـ Safari إكمال تنزيل كبير» — أبريل 2026

تم الإبلاغ عنها على iPhone 17 Pro Max يعمل بنظام iOS 26.4. يُزعم أن التنزيلات الكبيرة تتوقف مؤقتاً بعد قفل الجهاز بفترة وجيزة، أو عند التبديل بين الشبكة الخلوية و Wi-Fi. يذكر المؤلف تحديداً وجود إشارة جيدة ويقول إن نفس التنزيلات تكتمل على أجهزة الكمبيوتر، Mac، وأندرويد.

لا أعتقد أن تلك التقارير المجتمعية كافية للقول إن Apple أكدت وجود تراجع (Regression) في iOS.

ومع ذلك، فهي متسقة مع تسجيل الشاشة الخاص بي: كانت النسخة الاحتياطية قيد التنزيل بشكل طبيعي، انتقلت بعيداً عن Safari لفترة وجيزة، وعندما عدت أصبح النقل منقطعاً.

النقطة المهمة من جانب Discourse مستقلة عن سبب حدوث الانقطاع:

انقطاع نقل النسخة الاحتياطية الكبيرة

        ↓

يحاول المتصفح استئناف النطاق (Range) المعتمد على المعايير

        ↓

تم استهلاك رمز النسخة الاحتياطية بالفعل

        ↓

يتلقى الاستئناف رمز 422

ملاحظات من جانب الخادم

لا يبدو أن هذا مشكلة عامة في مسار nginx/sendfile الحالي.

تم إكمال نفس مسار النسخة الاحتياطية الضخم (عدة جيجابايت) بنجاح:

من Firefox/Linux عبر HTTP/3؛ و
من نفس iPhone عبر Wi-Fi باستخدام HTTP/3.

يعلن nginx الحالي أيضاً عن دعم نطاقات البايت (byte-range).

لذا، لا أقترح أن HTTP/3 أو Caddy أو nginx غير قادرة جوهرياً على تسليم النسخة الاحتياطية.

في إعادة الإنتاج هذه على وجه الخصوص، انقطع النقل الأصلي بعد حوالي 320 ميغابايت، ثم أصدر Safari طلب نطاق (Range) يبدو صالحاً، وتم رفض ذلك الطلب الثاني بواسطة Discourse.

هل من المعقول أن يكون لتنزيل نسخة احتياطية مصرح بها مسبقاً آلية قصيرة العمر تسمح لنفس المسؤول المصادق عليه باستئناف نفس ذلك الملف بعد انقطاع النقل؟

Ethsim2 · 31 أغسطس 2026، 10:52ص

راجعت سجلّات التطوير وتغطية الاختبارات الحالية للحصول على فكرة أوضح عما ينبغي الحفاظ عليه في أي إصلاح محتمل.

تعود سلوكية الاستخدام الواحد إلى تغيير تعزيز الأمان الذي تم في مارس 2017:

أدخل هذا الالتزام رموز تنزيل احتياطي عبر البريد الإلكتروني، كما استهلك الرمز فورًا بمجرد توثيق طلب التنزيل.

لا يزال الترتيب نفسه قائمًا في 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 رمز Redis واحدًا لكل مستخدم مع انتهاء صلاحية بعد يوم واحد. إنها مرتبطة بالمستخدم بدلاً من أن تكون مرتبطة بنسخة احتياطية محددة.

عند النظر في تاريخ هذا الملف، يبدو أن التغييرات منذ عام 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

تغطي هذه الاختبارات تنزيلًا صالحًا أوليًا، ورموزًا غير صالحة، ومعرفات نسخ احتياطية غير صالحة/ناقصة والصلاحيات، لكنني لم أجد تغطية لطلب 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

لذلك يبدو أن اتجاهًا محتملًا للإصلاح هو الحفاظ على رمز البريد الإلكتروني للاستخدام الواحد الحالي لبدء تنزيل النسخة الاحتياطية، مع توفير تفويض استئناف قصير العمر للنسخة الاحتياطية المحلية التي تم تفويضها بالفعل.

أتوقع أن يكون تفويض الاستئناف هذا محددًا بدقة للمستخدم الموثق والنسخة الاحتياطية المحددة، وأن يسمح بطلب نطاق بايت لاحقًا دون جعل رمز البريد الإلكتروني اليومي العام للمستخدم قابلًا لإعادة الاستخدام بشكل عام.

السلوكيات التي سأهدف إلى الحفاظ عليها/إضافتها هي:

يبقى طلب GET الأولي برمز البريد الإلكتروني الصالح مسموحًا به؛
يبقى رفض أي GET كامل عادي آخر باستخدام رمز البريد الإلكتروني المستهلك؛
يمكن استئناف إعادة محاولة نطاق بايت لنفس النسخة الاحتياطية من قبل نفس المسؤول الموثق لفترة محدودة قصيرة؛
يبقى رفض محاولة استئناف ضد نسخة احتياطية أخرى؛
يبقى رفض تفويض استئناف منتهي الصلاحية.

لم أفترض أن هذا هو بالضرورة التنفيذ الذي سيميله المسؤولون عن المشروع، لكن نطاق الكود/الاختبارات يبدو محدودًا إلى حد ما.

أنا سعيد بوضع مسودة إصلاح واختبارات انحدار لإعادة إنتاج سلوك Range: في Safari إذا بدا نموذج الأمان العام هذا معقولًا.

Ethsim2 · 31 أغسطس 2026، 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.

لا يزال يتم رفض طلب GET كامل ثانوي عادي باستخدام الرمز المستهلك، وكذلك يتم رفض طلب Range لنسخة احتياطية أخرى. تحتفظ النسخ الاحتياطية البعيدة/لـ S3 بسلوكها الحالي.

جعلت فترة الاستئناف قائمة (enum) بدلاً من مدة غير محدودة:

معطل (Disabled)
ساعة واحدة
6 ساعات (موصى به)
12 ساعة
حتى انتهاء صلاحية رمز البريد الإلكتروني الأصلي

يتم أيضًا تحديد فترة الاستئناف الفعلية بحد أقصى يعادل العمر المتبقي لرمز البريد الإلكتروني الأصلي عند بدء التنزيل الأولي.

يبقى سلوك Discourse الحالي هو الافتراضي (معطل) من أجل التوافق مع الإصدارات السابقة، بينما يتم تقديم خيار 6 ساعات كخيار موصى به عند تمكين التنزيلات القابلة للاستئناف.

يسأل طلب السحب (PR) عما إذا كان المحافظون يفضلون الاحتفاظ بهذا الإعداد الافتراضي الذي يحافظ على التوافق، أم يجعلون القيمة القابلة للاستئناف الموصى بها هي الإعداد الافتراضي كجزء من معالجة هذه المشكلة.

كما أضفت تغطية للرجوع (regression coverage) لمسار الاستئناف الناجح وحدود التفويض الرئيسية، بما في ذلك:

بقاء رفض إعادة استخدام الرمز العادي؛
بقاء رفض الاستئناف عبر نسخ احتياطية مختلفة؛
منع تعطيل الإعداد بشكل فوري من الاستئناف الإضافي؛
عدم حصول S3 على إذن استئناف محلي؛ و
إنتاج التنزيل الأولي واستئنافه لسجل تدقيق تنزيل نسخة احتياطية واحدة فقط.

تمر حزمة CI الكاملة، وطلب السحب (PR) جاهز للمراجعة.

سيكون من المرحب به تقديم ملاحظات حول نموذج الأمان، ولا سيما حول التوصية بـ 6 ساعات والإعداد الافتراضي.

الموضوع		الردود	مرات العرض
Downloads of the backups are not being initiated when clicking the link Support backups	9	344	5 أكتوبر 2025
Download backup - email link only Support	26	5966	30 ديسمبر 2023
Backup errors for download of image Support backups	3	122	24 أبريل 2025
Downloading backup through the API always results in a 422 error Support	0	293	22 فبراير 2023
HTTP Range support missing, cannot resume file download Feature	1	703	9 أغسطس 2022

الموضوعات ذات الصلة