Signed URLs and TTL

Every file in boveDAM is delivered through a signed URL — a temporary, authenticated link that grants access to a single asset for a limited window. This page explains what signed URLs are, why boveDAM uses them, and what happens when one expires.

What a signed URL is

A signed URL is a regular HTTPS URL with additional query parameters that act as a cryptographic proof of authorization. When boveDAM generates a signed URL, it takes the target file path and the current timestamp, and creates a SHA-256 HMAC signature using a secret key that only boveDAM's servers hold.

The signature is embedded in the URL itself. When the URL is requested, the storage layer verifies:

1. The signature matches the file path — the URL cannot be repurposed for a different file
2. The URL has not exceeded its time-to-live — it was generated within the last 5 minutes

If either check fails, the request is rejected with a 403 Forbidden response. No file data is returned.

Why 5 minutes?

The 5-minute TTL is calibrated to balance usability and security:

• Long enough to complete a download. Even a large file on a slow connection can typically be downloaded within the 5-minute window once the URL is generated. The clock starts when you click the asset in the portal, not when the download finishes.
• Short enough to prevent casual sharing. A URL copied from a network inspector, browser history, or download manager will expire before most people have a chance to forward it.

Longer TTLs — hours or days — would undermine the portal as an access control boundary. If a client could share a raw file URL that works for 24 hours, there would be no reason for their colleagues to request portal access. boveDAM's model is that access is granted at the portal level and revoked at the portal level.

If a download fails because the URL expired mid-transfer (unusual, but possible on very large files or very slow connections), simply clicking the asset again in the portal generates a fresh signed URL.

Expiry behavior

When a signed URL expires, any request to that URL — in a browser, a download manager, or a direct HTTP client — returns:

HTTP 403 Forbidden

The URL is not redirected, updated, or given a grace period. It simply stops working. The file itself is unaffected — it remains in the portal and a new signed URL can be generated at any time by accessing the asset normally through the portal.

Implications for link sharing

Because signed URLs expire within minutes, they cannot be used as permanent file links. This is by design, but it has some practical implications to be aware of:

• Network inspector copies: If a developer or technically savvy client copies an asset URL from their browser's network inspector tab, that URL will expire within 5 minutes of when the portal page loaded.
• Download manager resume: Some download managers save the URL and resume from it later. A paused download that resumes after the TTL window will fail. Restarting the download from the portal generates a new URL.
• Programmatic access: If you are building an integration that needs to reference boveDAM assets, use the portal API to fetch fresh signed URLs on demand rather than caching them.

Signed URLs on public portals

Even portals that are publicly accessible (no login required) still use signed URLs for file delivery. "Public" means anyone can view the portal and its asset listing without authenticating — but the files themselves are never served from a permanent, unprotected URL.

This ensures that even if a public portal URL is indexed by a search engine or shared widely, the underlying files remain protected by the same TTL mechanism.

See also: How storage works · Deletion and retention