Backup/file downloads fail with 404 when the client re-requests the signed URL (browser download scanners, antivirus, download managers)

[SkyRaax]

Summary

Backup and file download URLs generated by the Panel are single-use. Any client that requests the same signed URL more than once receives:

HTTP 404  {"error":"The requested resource was not found on this server."}

on the second request, which aborts the download. Anything that causes a second/parallel/retried request to the URL hits this, e.g.:

• Chromium's Safe Browsing "download protection" — a built-in Chromium/Google feature (same code in Chrome, Brave and other Chromium browsers; Brave just routes it through its own privacy proxy). With it enabled, the client ends up issuing a second request to the signed URL (empirically; see repro below).
• Antivirus software that re-fetches / re-opens the URL.
• Download managers or parallel-download / range requests that open a second connection.
• A transient reconnect near the end of a large download — there is no HTTP Range/resume support, so the client re-requests from the start.

⚠️ It is size / duration dependent

A small backup will very likely download fine and will not reproduce this. The bug only shows up once the download runs long enough for the client to touch the URL a second time (a re-check, an extra connection, or a reconnect). A fast/short download finishes on its first request before anything re-requests the URL — so if you test with a 1–2 GB file you may wrongly conclude the report is invalid.

Concrete data point from a real deployment (fast connection, ~500 Mbit/s):

Backup size	Result
~2.7 GB	downloads fine
~8.9 GB	runs to ~full size, then fails at the very end with the 404 above

Please test with a sufficiently large backup (big enough that the transfer takes at least tens of seconds), not a small one.

Root cause

getDownloadBackup and getDownloadFile in router/router_download.go require token.IsUniqueRequest():

if _, ok := manager.Get(token.ServerUuid); !ok || !token.IsUniqueRequest() || !token.HasScope(tokens.BackupDownload) {
    c.AbortWithStatusJSON(http.StatusNotFound, gin.H{"error": "The requested resource was not found on this server."})
    return
}

IsUniqueRequest() → TokenStore.IsValidToken() (router/tokens/token_store.go) records the token's unique_id on first use and returns false for any later use for 60 minutes:

func (t *TokenStore) IsValidToken(token string) bool {
    t.Lock()
    defer t.Unlock()
    _, exists := t.cache.Get(token)
    if !exists {
        t.cache.Add(token, "", time.Minute*60)
    }
    return !exists
}

The handlers also stream the whole file with no HTTP Range support, so an interrupted download cannot resume and the client must re-request the (now-spent) URL. The 404 above is emitted by exactly this !token.IsUniqueRequest() branch (server exists and scope matches), so whenever a user hits it, a second request to the one-time URL provably occurred.

Reproduction

A) Real-world (Brave) — Chromium Safe Browsing download protection is the trigger:

1. In the Panel, download a large backup (here: ~8.9 GB) in a Chromium browser with Safe Browsing / download protection enabled (Brave in this case) → the download runs, reaches ~full size, then fails at the very end (browser reports the download failed / an error page shows {"error":"The requested resource was not found on this server."}).
2. Disable the download check (brave://settings/security → turn off Safe Browsing / the automatic download-file check) and retry the same backup → it now completes immediately, every time. Before disabling it, it failed every time; after, it worked directly.
3. A ~2.7 GB backup downloads fine either way (it finishes before anything re-touches the URL).

With the download check on, the client issues a second request to the single-use signed URL; that second request hits the spent token → 404 → the download breaks right at the end. (Safe Browsing is a Chromium feature, so this is expected to affect Chrome and other Chromium browsers too, not just Brave.)

B) Minimal, size-independent proof of the single-use behaviour — request one freshly-minted signed URL twice:

GET .../download/backup?token=<A>   ->  200  (streams the full file)
GET .../download/backup?token=<A>   ->  404  {"error":"The requested resource was not found on this server."}
GET .../download/backup?token=<B>   ->  200  (a fresh token works again)

The file itself streams correctly and completely in a single clean request (verified for the 8.9 GB backup over both LAN and the public internet), so the server/storage is healthy — the failure is purely the single-use check being hit by a second request.

Note on consistency

The S3 backup adapter returns a presigned URL that is reusable within its TTL. The local (daemon) download path being single-use is stricter and inconsistent, and is what breaks these common clients.

Environment

• wings v1.0.0-beta22 (behaviour unchanged on main)
• Panel v1.0.0-beta35
• Client: Brave 1.92.134 (Chromium 150), Windows 11 (brave.exe version 150.1.92.134). The trigger is Chromium's Safe Browsing download protection (Brave routes it through its own proxy, but it's the standard Chromium feature) — enabling it triggers the failure, disabling it is the workaround. Expected to reproduce on other Chromium browsers (Chrome, etc.) with Safe Browsing download protection enabled.

Proposed fix

Rely on the signed token's expiry + scope + server match for download authorization and allow reuse until expiry — i.e. drop the one-time-use check for the two download routes, keeping it for uploads. Downloads are idempotent GETs and the URL is already short-lived and scoped. (Optionally, add HTTP Range support for resumable downloads as a follow-up.)

A PR implementing the minimal version of this is linked below.

[SkyRaax]

this also needs further investigations.
could also be a client issue