Skip to content
Rendorix

Expiration

Every signed Rendorix URL should include an expiry—often a Unix timestamp in a query field like exp. After that time, the edge must refuse the request, even if everything else looks plausible. Check the time window in a well-defined order alongside HMAC verification (your implementation should document whether exp is validated before or after the MAC, as long as both run before S3/Lambda work).

Expiry limits how long a captured link (logs, shared HTML, chat) stays valid for new GETs. It does not by itself revoke bytes already sitting in a browser or CDN cache—HTTP caching is a separate control.

Expiration parameter(s)

Section titled “Expiration parameter(s)”
  • Common pattern — exp=1715000000 using seconds since the Unix epoch in UTC. Document clearly whether you use seconds or milliseconds; mixing them up is a common production bug.
  • Signed payload — Include the same exp value in the canonical string for HMAC so an attacker cannot extend or strip expiry without invalidating the signature.

Clock skew and time zones

Section titled “Clock skew and time zones”
  • Validators and signers should use NTP-synced clocks. AWS service time is usually reliable; misconfigured on-prem signers are a typical source of skew.
  • End-user device time does not matter for edge-side expiry checks—only server clocks do.

You may allow a small grace window (a few seconds) around exp to absorb minor skew; keep the window tight so “slightly expired” links are not replayed for a long time.

Client and CDN behavior at expiry

Section titled “Client and CDN behavior at expiry”
  • A new request with an expired URL should receive 403 from the edge after your checks.
  • Long-lived browser tabs may still show HTML that references an old src. If the user triggers a refetch of an expired URL, the image request fails until the page is refreshed with fresh signed URLs (or your app fetches new URLs from an API).
  • CloudFront may cache 200 responses with its own TTL. Stale cache behavior depends on cache keys (including the signed query) and Cache-Control; align TTL concepts with your product expectations.

Renewing and refreshing URLs

Section titled “Renewing and refreshing URLs”
  • SSR — Re-render or call an API that returns new signed URLs when sessions or content change.
  • Static — Rebuild with new signed strings, or use long enough exp to match how long a page may sit open or be cached as HTML (Static rendering).
  • UX — On image load failure, fetch a new signed URL from your backend; never mint signatures in the browser.
Section titled “Related reading”