Skip to content
Rendorix

Signed URLs

Rendorix is meant to be used in public pages: <img>, srcset, and CDNs. You cannot hide a transformation URL the way you hide a private API key—anything the browser can request can be copied. Signed URLs are how you allow unauthenticated GET traffic while still controlling who can manufacture those requests. Implementation details (HMAC shape, field order) live under Security.

Why sign URLs

Section titled “Why sign URLs”
  • No open transform API — Without signing, anyone could try arbitrary width/quality/asset combinations and burn your Lambda and egress budget.
  • Time-bounded access — A signature is tied to an expiry (TTL), so stolen links stop working after a window you choose.
  • Issuance stays server-side — The HMAC secret never ships to the browser; only your app backend, build, or edge that you control can sign.

Signing is complementary to presets: presets define what transforms exist; signing defines which requests the edge will honor for a given time.

What is in the URL

Section titled “What is in the URL”
  • Path — Identifies the original (S3 key or mapped path) the worker loads.
  • Transform — Often w, h, f, q in the official @rendorix/client stack (values come from resolving a named preset in code, not from a p= query on the wire). Some deployments use a different encoding (e.g. literal p=hero); the important part is that transform intent is covered by the signature.
  • Expiry — exp (Unix seconds in the default client) after which the link is invalid (Expiration).
  • Signature — s: HMAC over a canonical string so tampering invalidates the request (Security).

The edge recomputes the expected signature; mismatch or late clock on expiry → 403.

Public vs. protected use cases

Section titled “Public vs. protected use cases”
ScenarioPattern
Marketing site, blog, product gridShort-lived signed URLs generated at render or build; images are public but mints are not.
In-app content behind loginStill often signed URLs: the page is protected, the image URL can still be leaked from devtools—signing + exp limits blast radius.
Truly private mediaRendorix is not a DRM system; for strict control you may need auth at edge, separate buckets, or non-URL delivery models.

Common pitfalls

Section titled “Common pitfalls”
  • Canonicalization drift — Signing code and the edge must agree on exact byte order of fields, encoding, and which parameters participate. One extra space in the spec → mysterious 403s (HMAC signing).
  • Over-long expiry — A signed URL in HTML can be saved and replayed until exp; keep lifetimes as short as your cache strategy allows.
  • Caching the wrong thing — If the cache key ignores part of the signed bundle, you could serve the wrong image; keys must include all varying inputs (Caching).
  • Signing in the client — Never embed the secret in frontend bundles or mobile apps. Use a server (or short-lived token exchange) to issue URLs.
Section titled “Related reading”