Prevent anons from downloading files incompatible with CDN

Product Support

AI-generated summary

pfaffman reported that MP4 files uploaded to their Discourse site were returning 404 errors despite correct permissions, valid file records, and authorized_extensions set to *. Initially suspecting an nginx config issue that only allowed specific file types (e.g., images), they manually added mp4 and mp3 to the config, which resolved the issue temporarily. RGJ clarified that downloads should still work via Rails even if nginx doesn’t bypass it, and noted that authorized_extensions only affects uploads, not downloads. After testing, RGJ found the file downloadable via wget, suggesting the issue might be client-side or related to configuration changes. pfaffman later discovered that disabling the setting prevent_anons_from_downloading_files resolved the problem, hinting at incompatibility between this setting and CDN usage. However, RGJ observed that uploads weren’t actually being served from the CDN, but from the site’s own domain (www.turiver.com), raising questions about CDN configuration or post rebaking. pfaffman confirmed the CDN was serving some content (e.g., posts), and the fix persisted across logged-in and anonymous users, despite ongoing 404s in the console. The site runs a standard two-container setup with common plugins. The issue was ultimately resolved by adjusting site settings, not code or nginx, and is likely related to CDN interaction with anonymous download restrictions.

1

I have a site where mp4 files are returning 404s.

They have authorized_extensions set to *. The file uploads just fine. I see it in the filesystem. The permissions are right. file says that it’s an MP4 file. The record in rails looks OK:

[1] pry(main)> u=Upload.find(196082)
=> #<Upload:0x00005601a1b56348
 id: 196082,
 user_id: 1,
 original_filename: "PXL_20220617_184736219.mp4",
 filesize: 9328093,
 width: nil,
 height: nil,
 url: "/uploads/default/original/3X/5/6/5679d94dfce852f780afa5fcb7f1a29d810cc8fc.mp4",
 created_at: Fri, 17 Jun 2022 18:53:41.130790000 UTC +00:00,
 updated_at: Fri, 17 Jun 2022 18:53:41.176664000 UTC +00:00,
 sha1: "5679d94dfce852f780afa5fcb7f1a29d810cc8fc",
 origin: nil,
 retain_hours: nil,
 extension: "mp4",
 thumbnail_width: nil,
 thumbnail_height: nil,
 etag: nil,
 secure: false,
 access_control_post_id: nil,
 original_sha1: nil,
 verification_status: 1,
 animated: nil,
 security_last_changed_at: nil,
 security_last_changed_reason: nil>

but accessing it returns a 404. There were a couple of new features and bug fixes for mp4 recently, but I just ran an upgrade and it’s still not working. I don’t know where else to look.

2

The problem is that the nginx config is allowing only certain file types. Moving this to bug.

In discourse.conf is this stanza:

      # this allows us to bypass rails
      location ~* \.(gif|png|jpg|jpeg|bmp|tif|tiff|ico|webp)$ {
          add_header Access-Control-Allow-Origin *;
          try_files $uri =404;
      }

I added mp3 and mp4 to the file types (after webp and mp4s now work) to the discourse.conf inside the container. I see “bypass rails” in discourse_docker config/nginx.sample.conf. I don’t see how it gets into the template inside docker, so I don’t know how to figure out when this happened.

They have * in for allowed file types. I don’t know if there is some magic that would allow the mp3/mp4 to work if they were enumerated in the site settings, but I don’t see how that could be.

3

But the download should just work if it does not bypass Rails as well.

There is a route for it

get "uploads/:site/original/:tree:sha(.:extension)" => "uploads#show", constraints: { site: /\w+/, tree: /([a-z0-9]+\/)+/i, sha: /\h{40}/, extension: /[a-z0-9\._]+/i }

and the show method should just send the file. The nginx config would only make it more efficient by bypassing rails, but this is not a requirement.

Oh.. the authorized_extensions are only for upload authorization, not for downloads (i.e. an extension not being in that list should not prevent a file from being downloaded).

I’m unable to repro this on latest tests-passed so you might want to move it back to Support :wink:

EDIT I googled the site and it seems you have other problems.

image
image1202×540 48.3 KB

Now when I simply wget the file, it works.

image
image979×207 29.7 KB

(EDIT 2 this could be because you added the mp4 extension to the nginx config? Still, for me it just works out of the box)

4

Thanks! I’ll take a look at that first thing. I guess I should have tried safe mode!

I’m quite confused by that service worker.

Not a bug.

5

I still don’t understand that Service Worker message, but I turned off prevent_anons_from_downloading_files and now it’s working. It seems that the “prevent_anons” setting is incompatible with CDN?

6

But the uploads are not being retrieved from the CDN on that site? It just refers to a location on www

image
image708×182 7.53 KB

7

Then I’m all the more confused. I suppose that post didn’t get rebaked after the CDN got defined.

But https://www.turiver.com/t/argentina-la-sociedad-perdida/117158/7909 is getting loaded from the CDN, and changing the setting did fix it.

I also see a bunch of 404s in the console, but it’s a standard two-container site with only these plugins:

          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-akismet.git
          - git clone https://github.com/discourse/discourse-spoiler-alert.git
          - git clone https://github.com/discourse/discourse-chat-integration.git
          - git clone https://github.com/discourse/discourse-solved.git
          - git clone https://github.com/discourse/discourse-cakeday.git
          - git clone https://github.com/discourse/discourse-data-explorer.git
          - git clone https://github.com/discourse/discourse-checklist.git
          - git clone https://github.com/discourse/discourse-canned-replies.git
          - git clone https://github.com/discourse/discourse-chat

And I think you’re looking at https://www.turiver.com/t/argentina-la-sociedad-perdida/117158/8017 which is pulling from the CDN when I look, but logged in and not logged in.