For an implementation, see this repository.
Signed URLs offer a way to sign a download URL for individual files as we've seen in the previous chapters. This is good when a user downloads an asset or an image and does not care about the exact URL used. In these cases, the URL is a passthrough value: the frontend gets it from the backend and uses that to insert the image or download a file.
But a signed URL means the URL is changed compared to what is stored. For example, if the image is stored in S3 at key images/abc.jpg, the signed URL will be images/abc.jpg?x-id=GetObject&... for S3 signed URLs, and images/abc.jpg?Policy=...&... for CloudFront ones. In the rare case when the client expects the URL of the file to be some specific value, using signed URLs break functionality.
A good example here is video content, more specifically segmented videos, such as HLS or MPEG-DASH. In these cases, the clients construct the video URLs based on a manifest file, thus the URLs must be unchanged.
For example, an MPEG-DASH manifest file defines segments like this:
<Representation
id="0"
mimeType="video/mp4"
codecs="avc1.4d401f"
bandwidth="800000"
width="1280"
height="720"
sar="1:1"
>
<SegmentTemplate
timescale="15360"
initialization="init-stream$RepresentationID$.m4s"
media="chunk-stream$RepresentationID$-$Number%05d$.m4s"
startNumber="1"
>
<SegmentTimeline>
<S t="0" d="122880" />
<S d="30720" />
</SegmentTimeline>
</SegmentTemplate>
</Representation>Notice the media="chunk-stream$RepresentationID$-$Number%05d$.m4s" part. This tells the player that the files are chunk-stream0-00001.m4s, chunk-stream0-00002.m4s, and so on, and during the video playback the browser will download the correct chunk and shows it to the user. Since the client can't attach the signatures by itself (the keys for that are only known to the backend), it can't download the chunks, breaking video playback.