Empêcher les anonymes de télécharger des fichiers incompatibles avec le CDN

Soutien
1

J’ai un site où les fichiers mp4 renvoient des 404.

Ils ont authorized_extensions défini sur *. Le fichier se télécharge sans problème. Je le vois dans le système de fichiers. Les permissions sont correctes. file indique que c’est un fichier MP4. L’enregistrement dans rails semble correct :

[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>

mais y accéder renvoie un 404. Il y a eu quelques nouvelles fonctionnalités et corrections de bugs pour mp4 récemment, mais je viens de faire une mise à niveau et ça ne fonctionne toujours pas. Je ne sais pas où chercher d’autre.

2

Le problème est que la configuration nginx n’autorise que certains types de fichiers. Déplacement vers bug.

Dans discourse.conf, il y a cette section :

      # cela nous permet de contourner rails
      location ~* \.(gif|png|jpg|jpeg|bmp|tif|tiff|ico|webp)$ {
          add_header Access-Control-Allow-Origin *;
          try_files $uri =404;
      }

J’ai ajouté mp3 et mp4 aux types de fichiers (après webp, les mp4 fonctionnent maintenant) à discourse.conf à l’intérieur du conteneur. Je vois “bypass rails” dans discourse_docker config/nginx.sample.conf. Je ne vois pas comment cela arrive dans le template à l’intérieur de docker, donc je ne sais pas comment savoir quand cela s’est produit.

Ils ont * pour les types de fichiers autorisés. Je ne sais pas s’il existe une magie qui permettrait aux mp3/mp4 de fonctionner s’ils étaient énumérés dans les paramètres du site, mais je ne vois pas comment cela pourrait être.

3

Mais le téléchargement devrait simplement fonctionner s’il ne contourne pas Rails également.

Il y a une route pour cela

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 }

et la méthode show devrait simplement envoyer le fichier. La configuration nginx ne ferait que la rendre plus efficace en contournant Rails, mais ce n’est pas une exigence.

Oh… les authorized_extensions ne servent qu’à l’autorisation de téléchargement, pas au téléchargement (c’est-à-dire qu’une extension qui ne figure pas dans cette liste ne devrait pas empêcher le téléchargement d’un fichier).

Je ne parviens pas à reproduire cela sur les derniers tests réussis, vous pourriez donc le déplacer vers Support :wink:

EDIT J’ai googlé le site et il semble que vous ayez d’autres problèmes.

image
image1202×540 48.3 KB

Maintenant, quand je fais simplement un wget du fichier, cela fonctionne.

image
image979×207 29.7 KB

(EDIT 2 cela pourrait être parce que vous avez ajouté l’extension mp4 à la configuration nginx ? Pourtant, pour moi, cela fonctionne tout simplement)

1 « J'aime »
4

Merci ! Je vais regarder ça en premier. Je suppose que j’aurais dû essayer le mode sans échec !

Je suis assez confus par ce service worker.

Pas un bug.

5

Je ne comprends toujours pas ce message de Service Worker, mais j’ai désactivé \t\nprevent_anons_from_downloading_files et maintenant cela fonctionne. Il semble que le paramètre « prevent_anons » soit incompatible avec le CDN ?

6

Mais les téléchargements ne sont pas récupérés du CDN sur ce site ? Il fait juste référence à un emplacement sur www

image
image708×182 7.53 KB

1 « J'aime »
7

Alors je suis encore plus confus. Je suppose que ce message n’a pas été re-cuit après la définition du CDN.

Mais https://www.turiver.com/t/argentina-la-sociedad-perdida/117158/7909 est chargé depuis le CDN, et changer le paramètre l’a corrigé.

Je vois aussi un tas de 404 dans la console, mais c’est un site standard à deux conteneurs avec seulement ces 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

Et je pense que vous regardez https://www.turiver.com/t/argentina-la-sociedad-perdida/117158/8017 qui est chargé depuis le CDN quand je regarde, mais connecté et non connecté.