Is there a better way to achieve fine-grained per-video access control while minimizing Workers requests?

[zein1016]

Question

Is there a better way to achieve fine-grained per-video access control while minimizing Workers requests?

Options I've considered:

1. R2 pre-signed URLs: Can't combine with edge caching (pre-signed URLs only work on accountid.r2.cloudflarestorage.com, caching requires custom domains)
2. Cloudflare Access: Requires public bucket + coarse bucket-level permissions (can't restrict per-video based on subscriptions)
3. HLS encryption (AES-128): Adds client CPU overhead, still need authenticated key endpoint

Requirements

• Per-video access control (user must be subscribed to specific creator)
• Edge caching for performance
• Support standard HLS players
• Private R2 storage

Is the current time-window token + Worker + edge cache approach the recommended solution? Or is there a pattern I'm missing?

---

Usage: ~14,500 Workers requests/day (well under free tier), just want to confirm this is best practice.

[MukundaKatta]

You're basically already at the right shape — signed short-lived tokens + Worker-mediated access on a custom domain, with the Cache API doing the heavy lifting. But there are a few levers that make it noticeably cheaper and/or more correct than the obvious implementations.

What actually belongs on each hop

Think in three layers:

Layer	Purpose	Not its job
R2 (private)	Origin for bytes	Access control
Worker (on custom domain)	Authorization + signed URL minting + cache key policy	Serving bytes for every segment
Cache API + cache-control	Serve 99% of segment requests without invoking your Worker	Enforcing per-user auth

The rule: a segment URL, once minted, is a bearer credential for a short window, and the edge cache keys on it. So the same segment fetched by ten subscribers gets one R2 read + one cached response at the colo, regardless of who's watching.

Concrete pattern

1. Gate the .m3u8 playlist, not each segment.

   • GET /play/{videoId}.m3u8 → Worker: authenticate user, check subscription, mint a short-lived HMAC token (e.g. 5 min), and return the playlist with each segment URL rewritten to include the token.
   • This is the only request you pay authorization cost on per-play. You cache the auth result on the subscription itself (KV with a 60s TTL) so repeated playlist fetches during a session are mostly free.

2. Segments go through a Worker that is mostly a cache hit.

   export default {
     async fetch(req: Request, env: Env, ctx: ExecutionContext) {
       const url = new URL(req.url)
       // Build a cache key that ignores the user-specific token for lookup,
       // but verifies the token before returning cached bytes.
       const cacheKey = new Request(`${url.origin}${url.pathname}`, req)
       const cache = caches.default
   
       // Verify token *before* cache read — cheap HMAC, no subrequest.
       if (!verifyToken(url.searchParams.get('t'), url.pathname, env.SIGNING_KEY)) {
         return new Response('forbidden', { status: 403 })
       }
   
       let res = await cache.match(cacheKey)
       if (res) return res
   
       // Miss — read from R2 via binding (no egress fee, no subrequest cost).
       const obj = await env.BUCKET.get(r2KeyFromPath(url.pathname))
       if (!obj) return new Response('not found', { status: 404 })
   
       res = new Response(obj.body, {
         headers: {
           'Content-Type': 'video/mp4',
           'Cache-Control': 'public, max-age=31536000, immutable',
           'ETag': obj.httpEtag,
         },
       })
       ctx.waitUntil(cache.put(cacheKey, res.clone()))
       return res
     },
   }

   Critical details:

   • Token is verified every request, but the cache key omits it. Two subscribers with two different tokens share one cache entry. This is the trick that makes the approach scale.
   • Segment responses are immutable with a long max-age — segment URLs are content-addressed (chunk numbers inside a per-video directory that's immutable once encoded), so caches can hold them effectively forever.
   • env.BUCKET is an R2 binding, not a fetch to *.r2.cloudflarestorage.com. Bindings don't count as subrequests and have no egress fee to the Worker.

3. Revocation. Signed-URL schemes are bad at "the user unsubscribed mid-stream." Options:

   • Short tokens (60–300 s) + the playlist endpoint re-checks subscription on refresh. This is what everyone actually does.
   • A denylist in KV keyed on userId + videoId that the verify step checks. Costs one KV read per segment — usually cacheable for the session, but adds subrequests.
   • If subscription changes are rare, the short-token approach is almost always right.

Where HLS encryption fits (and usually doesn't)

AES-128 HLS encryption gives you "the key endpoint is the real gate, segments are useless without it." It's architecturally appealing, but:

• Every player still hits your key endpoint, so you moved the auth request from segment-fetch to key-fetch. In practice this is more Worker requests, not fewer — the key is small but players re-fetch it aggressively.
• It doesn't protect against a subscriber sharing their key + segment URLs with a friend.
• It does protect against someone scraping the bucket directly, which signed URLs + private R2 already solve for you.

Skip it for access control. Keep it only if you need DRM-adjacent obfuscation (and at that point you're looking at Widevine/FairPlay, not AES-128).

Answering the literal question

Is the current time-window token + Worker + edge cache approach the recommended solution?

Yes. With the two refinements above — (a) gate on the playlist, not each segment; (b) key the cache on the path, not the token — this is the pattern Cloudflare Stream itself uses internally. At 14.5k requests/day you're nowhere near any limit; the optimizations are more about protecting future growth than current cost.

Is there a pattern I'm missing?

The one I haven't mentioned: if your videos are <100 MB and you're comfortable with a warmer tail, consider pre-emitting segments through a custom domain in front of R2 with a single bucket-scoped Worker, and skip HLS for short content. A single video/mp4 with Range requests is cached wonderfully by the CDN and avoids the per-segment auth fan-out entirely. HLS really only pays off for long content, adaptive bitrate, or live.