# Secure media uploads expire

**URL:** https://meta.discourse.org/t/secure-media-uploads-expire/140894
**Category:** Bug
**Created:** [6 בפברואר,‏ 2020,‏ 5:21pm UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894 "2020-02-06T17:21:52Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [6 בפברואר,‏ 2020,‏ 5:21pm UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/1 "2020-02-06T17:21:52Z")

</div>

We have a client having issues with secure media uploads.  
This client is running a docker based Discourse ([official install](https://meta.discourse.org/t/142537?silent=true)) with AWS S3 and secure media enabled.

The forum has a number of mp3 and m4a sound files.

Discourse automatically embeds a nice player like this:

![image](https://global.discourse-cdn.com/meta/original/3X/8/9/89fe0eef77eba02e0260f23e5fafec109fdc6e75.png)

Problem: the sound files do not work reliably. Sometimes they do not play.

I cannot reproduce this 100% reliable, I think because of caching, but it seems that the download is postponed until the play button is pressed. That sounds logical and good.

But it doesn’t play nice with secure media uploads - if you leave a page open for a while and press the play button after a minute or so, the sound file does not (always) play. At that point, AWS returns a `403 Expired` error. It looks like the request is not signed at the moment the file is requested, but earlier. The error message clearly states that the request expired in the past.

I suspect this has to do with the delay, but I am not 100% sure. Fact is that this is happening to sound files only (i.e. not to embedded images which are always downloaded immediately).

Yes, server time is correct.

I can repro on a fresh install running latest beta. Just put two sound files in a topic and mess around a bit.

 ![onTEiAwZWE](https://global.discourse-cdn.com/meta/original/3X/1/c/1c2a41e795877ac387a43de890fd5e3153473676.gif)

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [6 בפברואר,‏ 2020,‏ 5:28pm UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/2 "2020-02-06T17:28:38Z")

</div>

That may be because of how browsers work with audio and video tags and the default value of `preload`. Are the files specially long? AFAIK browsers will download using byte ranges on demand.

---

<div class="post-metadata">

### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [6 בפברואר,‏ 2020,‏ 6:28pm UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/3 "2020-02-06T18:28:10Z")

</div>

No, they’re not long, the files are just a few ( \< 5) megabytes and they’re not being downloaded in ranges.

What do you mean by 'the default value of `preload` ?

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [6 בפברואר,‏ 2020,‏ 10:39pm UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/5 "2020-02-06T22:39:32Z")

</div>

> [@RGJ](#):
>
> What do you mean by 'the default value of `preload` ?

If you have a `<audio>` or `<video>` tag, setting an attribute of `preload=auto` on it will hint the browser to download it all on page load, so you wouldn’t have this problem with the signed s3 url expiring.

As with those things always go, sites started to abuse this attribute and it isn’t always blindly followed anymore, but is a hint the browser will consider.

---

<div class="post-metadata">

### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [6 בפברואר,‏ 2020,‏ 10:51pm UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/6 "2020-02-06T22:51:00Z")

</div>

There is no explicit `<audio>` tag, it is generated automatically by Discourse when the audio file is being inserted. Without a `preload` attribute.

The part I don’t get: if the `/secure-media-uploads` route is generating the signed URL, why does it matter how much time there is between the page load and the route getting hit? After all, it is generating the signed route and then _immediately_ redirecting to that. But somehow, it does seem to matter. It seems like something is being cached or something?

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [6 בפברואר,‏ 2020,‏ 11:28pm UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/7 "2020-02-06T23:28:55Z")

</div>

> [@RGJ](#):
>
> There is no explicit `<audio>` tag, it is generated automatically by Discourse when the audio file is being inserted. Without a `preload` attribute.

There is in the generated HTML from the post markdown, and that is what I’m talking about. I’d say it makes sense to add that attribute when the setting is enabled.

> [@RGJ](#):
>
> why does it matter how much time there is between the page load and the route getting hit?

I believe the whole of point of the feature is exactly that. Have URLs that can’t be shared elsewhere for the uploads, and the only way to have that is using URLs that expire.

---

<div class="post-metadata">

### Author: ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [7 בפברואר,‏ 2020,‏ 5:16am UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/9 "2020-02-07T05:16:28Z")

</div>

> [@Falco](#):
>
> Have URLs that can’t be shared elsewhere for the uploads, and the only way to have that is using URLs that expire.

Yes, I understand that. And the expire timer starts counting at the moment the `/secure-media-uploads` route is called, and not when the page is being loaded.

Still, it _seems_ to matter if the page was loaded long before the route is hit. And then it breaks, _somehow_. I just don’t get why this is happening.

---

<div class="post-metadata">

### Author: ![martin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/martin/32/491371_2.png) [@martin](https://meta.discourse.org/u/martin)
#### Post date: [11 בפברואר,‏ 2020,‏ 2:19am UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/17 "2020-02-11T02:19:33Z")

</div>

This has now been fixed here [FIX: Disable preloading audio + video when secure media enabled (#8922) · discourse/discourse@7ff58f1 · GitHub](https://github.com/discourse/discourse/commit/7ff58f17877cd5b5ce6e96def47aa7719e843977) @RGJ. The problem was happening because browsers send an initial request to audio + video files to get metadata for the file e.g. duration. However because of the secure presigned URL, this initial request started the 15 second expiry countdown, so when users went to play audio + video after that time period we got the 403 error from AWS.

We now disable preloading on video + audio when secure media is enabled. Existing posts with audio + video will need to have their HTML rebuilt to see the change.

---

<div class="post-metadata">

### Author: ![martin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/martin/32/491371_2.png) [@martin](https://meta.discourse.org/u/martin)
#### Post date: [10 במרץ,‏ 2020,‏ 8:33am UTC](https://meta.discourse.org/t/secure-media-uploads-expire/140894/18 "2020-03-10T08:33:19Z")

</div>


