Anons vom Herunterladen von Dateien abhalten, die mit CDN inkompatibel sind

Unterstützung
1

Ich habe eine Website, auf der MP4-Dateien 404er zurückgeben.

Sie haben authorized_extensions auf * gesetzt. Der Upload funktioniert einwandfrei. Ich sehe ihn im Dateisystem. Die Berechtigungen sind in Ordnung. file sagt, dass es eine MP4-Datei ist. Der Eintrag in Rails sieht in Ordnung aus:

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

aber der Zugriff darauf gibt einen 404er zurück. Es gab kürzlich ein paar neue Funktionen und Fehlerbehebungen für MP4, aber ich habe gerade ein Upgrade durchgeführt und es funktioniert immer noch nicht. Ich weiß nicht, wo ich sonst noch suchen soll.

2

Das Problem ist, dass die Nginx-Konfiguration nur bestimmte Dateitypen zulässt. Dies wird als Fehler eingestuft.

In discourse.conf befindet sich dieser Abschnitt:

      # 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;
      }

Ich habe mp3 und mp4 zu den Dateitypen hinzugefügt (nach webp und mp4s funktionieren jetzt) zur discourse.conf innerhalb des Containers. Ich sehe “bypass rails” in discourse_docker config/nginx.sample.conf. Ich sehe nicht, wie es in die Vorlage innerhalb von Docker gelangt, daher weiß ich nicht, wie ich herausfinden kann, wann dies geschah.

Sie haben * für erlaubte Dateitypen. Ich weiß nicht, ob es irgendeinen Zauber gibt, der es den mp3/mp4 ermöglichen würde zu funktionieren, wenn sie in den Website-Einstellungen aufgeführt wären, aber ich sehe nicht, wie das möglich sein könnte.

3

Aber der Download sollte einfach funktionieren, wenn er Rails nicht umgeht.

Es gibt eine Route dafür:

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 }

und die Show-Methode sollte einfach die Datei senden. Die nginx-Konfiguration würde es nur effizienter machen, indem sie Rails umgeht, aber das ist keine Voraussetzung.

Oh.. die authorized_extensions sind nur für die Upload-Autorisierung, nicht für Downloads (d.h. eine Erweiterung, die nicht in dieser Liste steht, sollte einen Download nicht verhindern).

Ich kann das auf den neuesten getesteten Versionen nicht reproduzieren, daher sollten Sie es vielleicht zurück zu Support verschieben :wink:

EDIT Ich habe die Seite gegoogelt und es scheint, dass Sie andere Probleme haben.

image
image1202×540 48.3 KB

Jetzt, wenn ich die Datei einfach mit wget herunterlade, funktioniert sie.

image
image979×207 29.7 KB

(EDIT 2 Das könnte daran liegen, dass Sie die mp4-Erweiterung zur nginx-Konfiguration hinzugefügt haben? Aber für mich funktioniert es einfach so.)

1 „Gefällt mir“
4

Danke! Ich werde mir das als Erstes ansehen. Ich hätte wohl den abgesicherten Modus ausprobieren sollen!

Ich bin ziemlich verwirrt von diesem Service Worker.

Kein Fehler.

5

Ich verstehe diese Service Worker-Nachricht immer noch nicht, aber ich habe prevent_anons_from_downloading_files deaktiviert und jetzt funktioniert es. Es scheint, dass die Einstellung „prevent_anons“ mit CDN inkompatibel ist?

6

Aber die Uploads werden auf dieser Website nicht vom CDN abgerufen? Es verweist nur auf einen Speicherort auf www

image
image708×182 7.53 KB

1 „Gefällt mir“
7

[quote=“Richard - Communiteq, post:6, topic:230513, username:RGJ”]aber die Uploads werden nicht vom CDN auf dieser Seite abgerufen? Es wird nur auf einen Speicherort auf www verwiesen.
[/quote]
Dann bin ich umso verwirrter. Ich nehme an, dieser Beitrag wurde nach der Definition des CDN nicht neu gebacken.

Aber https://www.turiver.com/t/argentina-la-sociedad-perdida/117158/7909 wird vom CDN geladen, und die Änderung der Einstellung hat es behoben.

Ich sehe auch eine Reihe von 404s in der Konsole, aber es ist eine Standard-Zwei-Container-Site mit nur diesen 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

Und ich denke, Sie schauen sich https://www.turiver.com/t/argentina-la-sociedad-perdida/117158/8017 an, das vom CDN geladen wird, wenn ich es mir ansehe, sowohl angemeldet als auch abgemeldet.