Why not use Oauth 2.0 to control access to the resource? Seems like the perfect use case fit for such a stratagem.
On 10/31/12 1:35 PM, "Leif Hedstrom" <[email protected]> wrote: >On 10/31/12 9:45 AM, John Allspaw wrote: >> Hey all - >> Is there anyone doing logic in ATS to support single-use URLs? >> >> Example: I have an mp3. I want exactly one person (i.e. client >> download) to get at it, and no more. If the download doesn't complete, >> I'm willing to risk that, no more than one download. >> >> Has anyone approached this problem within ATS, or always just handled >> the logic in the origin server? Presumably the object in cache has a >> reference count associated with it that we can check if >1 than deny? > >But this would always be a cache miss then ? Or is the idea that the >same user can fetch it multiple times ? If it's the former, why not >always go to origin, and make it non cacheable? If the object is the >same, but unique URLs for each user, I'd take a slightly different >approach: > >1) Generate cryptographically signed URLs, personalized, such that it's >only valid from one client IP (or user cookie or whatever). > >2) Validate the URL, if not valid for this particular user + URL combo, >deny the request > >3) Extract the "content" portion of the URL, and use that as the cache >key. > > >The cache doesn't keep any "ref count" on disk (you knew that ;), it >does have an LRU for the in memory cache. An object that only gets one >hit, but is cacheable, would get written to disk, but would not be in >RAM cache. > >Cheers, > >-- Leif >
