3 ms·

Sounds good! Yeah, my concerns are more related to public buckets, I suppose, and those aren't out. I have some more thoughts on those: - Will adding the cach

Sounds good! Yeah, my concerns are more related to public buckets, I suppose, and those aren't out. I have some more thoughts on those: - Will adding the cache in front of a public bucket come with the necessary ToS updates to allow serving the media content in the bucket? - It would be nice if there could be some kind of timed authorization for downloads (like a signed token in a header or something?) that does not count towards class B charges if it fails. Currently you can implement this with a worker, but it actually still causes a charge to run the worker, so is mostly ineffective.

vlovich123 4y ago
Just to be clear. Putting cache in front of a public bucket has a lot of technical challenges. I don't know when that will become a thing but presumably when it does we'd figure out what the ToS changes would look like. > that does not count towards class B charges if it fails What does failure mean in this context?
- fjfbsufhdvfy 4y ago
  Failed to verify the token, as in the user did not have valid authorization to download the file. Something like this would really help cutting down on unwanted bot requests as each valid request could be traced back to a user and abusive users could be banned. But if the "failed" requests still cause a charge on your account, this wouldn't really work as intended. Just trying to think of reliable ways to defend against bot downloading causing massive charges, but also without letting them take down the entire site by triggering something like a billing cap. Hostile world out there...
  - vlovich123 4y ago
    If you gave the user an invalid token (as in R2 can reject it because the token isn't valid), we certainly wouldn't bill (after all, that would be a trivial way someone could launch billing attacks on your account). Now if you gave them a token that validates from our end, then I'm not sure how we'd solve that. I think what you're thinking of is maybe some kind of external IAM integration where you could add an additional authentication layer to whitelabel R2 (but then you're back to the problem where you'd be running a worker to validate the account-level logic and paying for that request). I think the solution is bot fight protection services from Cloudflare. There's a bunch in there also to allow well-behaved bots to have access and lets you control what those look like.

vlovich123 4y ago

Just to be clear. Putting cache in front of a public bucket has a lot of technical challenges. I don't know when that will become a thing but presumably when it does we'd figure out what the ToS changes would look like. > that does not count towards class B charges if it fails What does failure mean in this context?

fjfbsufhdvfy 4y ago
Failed to verify the token, as in the user did not have valid authorization to download the file. Something like this would really help cutting down on unwanted bot requests as each valid request could be traced back to a user and abusive users could be banned. But if the "failed" requests still cause a charge on your account, this wouldn't really work as intended. Just trying to think of reliable ways to defend against bot downloading causing massive charges, but also without letting them take down the entire site by triggering something like a billing cap. Hostile world out there...
- vlovich123 4y ago
  If you gave the user an invalid token (as in R2 can reject it because the token isn't valid), we certainly wouldn't bill (after all, that would be a trivial way someone could launch billing attacks on your account). Now if you gave them a token that validates from our end, then I'm not sure how we'd solve that. I think what you're thinking of is maybe some kind of external IAM integration where you could add an additional authentication layer to whitelabel R2 (but then you're back to the problem where you'd be running a worker to validate the account-level logic and paying for that request). I think the solution is bot fight protection services from Cloudflare. There's a bunch in there also to allow well-behaved bots to have access and lets you control what those look like.