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.