2 ms·
1) Long UUID are generally considered safe if you don’t allow parties to list the contents of the bucket 2) You can encrypt the asset and include the key with t
by klohto 6y ago
1) Long UUID are generally considered safe if you don’t allow parties to list the contents of the bucket
2) You can encrypt the asset and include the key with the asset URL (mentioned in the article)
3) Use pre-signed URL (infra load, but smaller than you serving it)
4) Implement your logic in Lambda@Edge (AWS) and link it with CloudFront distribution. You can deny or allow access based on that (Auth, Tokens, etc.)
4) I would say is the best and the safest solution at really low cost. Followed by 1) at price/value ratio.
- heavenlyblue 6y agoWhat is a “short” UUID?
- jsjohnst 6y agoI don’t think GP intended to signify there’s long and short UUIDs, just used “long” to additionally describe UUIDs. I could be wrong, but site guidelines say to assume best intent in your replies.
- klohto 6y agoPretty much :) I don't know how would I classify a short UUID, but they should follow the same precautions as if it was a password composed only of lowercase alphanumeric chars. The longer you can afford, the better.
- henryfjordan 6y agoThere are variants of uuids that encode a MAC address and timestamp, reducing the randomness quite a bit. If you knew that info, generating a collision would be a lot easier (still impractical). Maybe that's what GP meant?