A implementação preserva o token de e-mail de uso único existente para iniciar o download, permitindo que backups locais criem uma autorização de retomada separada e limitada, escopada para:
o mesmo administrador autenticado;
o mesmo backup;
o mesmo valor de token original; e
uma solicitação subsequente que contenha um cabeçalho Range.
Um segundo GET completo comum usando o token consumido ainda é rejeitado, assim como uma solicitação Range para outro backup. Backups remotos/S3 mantêm seu comportamento existente.
Tornei o período de retomada um enum em vez de uma duração ilimitada:
Disabled (Desativado)
1 hour (1 hora)
6 hours (recommended) (6 horas (recomendado))
12 hours (12 horas)
Until the original email token expires (Até a expiração do token de e-mail original)
O período de retomada efetivo também é limitado à vida útil restante do token de e-mail original quando o download inicial começa.
O comportamento atual do Discourse permanece como padrão (Disabled) por compatibilidade reversa, enquanto 6 hours (6 horas) é apresentado como a opção recomendada quando os downloads retomáveis estão habilitados.
O PR pergunta se os mantenedores prefeririam reter esse padrão que preserva a compatibilidade ou fazer com que o valor de retomada recomendado se torne o padrão como parte da correção deste problema.
Também adicionei cobertura de regressão para o caminho de retomada bem-sucedido e para os principais limites de autorização, incluindo:
rejeição contínua do reuso comum do token;
rejeição contínua da retomada entre backups;
desativação da configuração impedindo imediatamente novas retomadas;
S3 não recebendo uma concessão de retomada local; e
o download inicial e sua retomada gerando apenas uma entrada de auditoria de download de backup.
A suíte completa de CI está passando e o PR está pronto para revisão.
Feedback sobre o modelo de segurança, e particularmente sobre a recomendação de 6 horas e a configuração padrão, seria bem-vindo.