3 ms·
Quick feedback – you've used the term "signed URL" over 50 times in the post without once explaining what it is or how it works.
by paxys 2y ago
Quick feedback – you've used the term "signed URL" over 50 times in the post without once explaining what it is or how it works.
- shortrounddev2 2y agoRather than allowing any object on a bucket to be downloaded by its raw URL (i.e: http://mycdn.io/abcdefg.jpeg http://mycdn.io/abcdefg.jpeg), the backend service needs to generate a "signed" url, which is a short lived URL that grants the user a single request against that resources (GET, POST, PUT, etc.) (i.e: http://mycdn.io/abcdefg.jpeg?signed={securerandomstring} http://mycdn.io/abcdefg.jpeg?signed={securerandomstring}) So you can only use the URL to download it once, and you need to go through the backend API to generate the presigned URL. This could result in your backend getting hammered but you can also use DDOS protection to prevent 10k requests a second from going through your backend Theyre also a good way to allow users to upload images to your CDN without having to actually upload that data to your web API backend; you just give the user a presigned PUT request URL and they get a one-time ticket to upload to your bucket
- taeric 2y agoWorth calling out that the big benefit is you basically lean on the service provider for streaming the data, without having to form a trust relationship between them and the receiver of the data. That is, the entire point is to not put more compute between the requester and the data. The absolute worst place to be would be to have compute that is streaming from the data provider, so that they can stream to the end user. Right?
- shortrounddev2 2y agoExactly. You can selectively gate access to the data but still have it served from a cdn
- ddorian43 2y agoIt's not a single time, but its with TTL.
- telotortium 2y agoUntil the author fixes the post, this is what they're talking about: https://cloud.google.com/storage/docs/access-control/signed-urls https://cloud.google.com/storage/docs/access-control/signed-.... Essentially, it ensures that a URL is invalid unless the server signs it with a secret key controlled by the server, which means that clients can't access your assets just by guessing the URL. In addition to signing the URL, the signature can contain metadata such as permissions and expiration time.
- riedel 2y agoIs there any advantage over JWT other than one can put the token into the URL itself (which is technically also possible with JWT I guess, with the downside that it will be probably exposed in logs, etc.)?
- kijin 2y agoSigned URLs work with dumb storage such as Amazon S3 and Google Cloud Storage. You might want to use JWT to authenticate someone before handing out a signed URL, though.
- inopinatus 2y agoThe signature is verified by the origin bucket/cdn endpoint, so it's in the format used by the applicable public cloud, without depending on any application-specific cookie or bearer values, and with CORS/CSP interactions you can easily reason about. Signature values could appear in the logs the cloud provider writes, but won't be in your application logs unless you, for example, specifically write out the Location of a 30x redirect (which would be relatively uncommon), and in any case the ephemerality makes them basically uninteresting.
- jacobr1 2y agoThese came out before JWTs gained broad adoption. They are accomplishing the same technical objective via a different implementation.
- dyogenez 2y agoOhh good catch. Just updated the post with a section mentioning what signed URLs are before jumping into the solution.