Download gating
The five conditions that must all hold before a file is served.
Downloads are authorised on every request. There are no pre-signed URLs and no public paths — the file is streamed only after all five of these hold.
The five rules#
- The subscription belongs to the requesting user. Enforced by an authorisation policy, so an unrelated subscription’s ID in the URL is rejected.
- The subscription is active. Canceled, paused, and past-due subscriptions cannot download. Anything else returns 403.
- The version belongs to the subscribed product. A subscription to product A can never reach a file belonging to product B. Returns 404.
- The version was released before the update window closed. If the release date is after the subscription’s update expiry, it is not included. Returns 403.
- The file exists on disk. A version record whose archive is missing returns 404 rather than an error page.
What that means for a lapsed customer#
They keep working software and keep every build they already downloaded. What they lose is access to releases published after their window closed. Renewing pushes the expiry forward and everything released in the meantime becomes available again.
Download records#
Every served download records the subscription, version, user, IP address, user agent, and timestamp. Useful for support (“which build are they actually running?”) and for spotting a key being shared far beyond its domain limit.
Records are pruned on a schedule — 90 days by default, configurable in Settings.
Throttling#
Downloads are rate limited per customer, 10 per minute by default. It is high enough that nobody legitimate notices and low enough to stop a script pulling your entire release history in a loop.
Downloading through the API#
Your software can fetch a build itself with the license key rather than sending the customer to the panel:
POST /api/v1/license/downloadThe same five rules apply. See the API reference.