Für ein vollständig privates Forum (ohne anonymen Zugriff) erscheint mir das Fehlen einer sicheren Medienoption in der Standardkonfiguration des lokalen Speichers als ein riesiger Fehler. Es würde mich nicht wundern, wenn viele Betreiber privater Foren nicht wissen, dass alle Anhänge ihrer Beiträge öffentlich zugänglich sind (wenn man die URL kennt). Wenn der Text meines Beitrags nicht anonym abgerufen werden kann, würde ich intuitiv annehmen, dass auch die Anhänge des Beitrags nicht zugänglich sind.
Lohnt es sich, ein Issue einzureichen, um zu prüfen, welche Unterstützung es dafür geben würde? Gibt es bereits eines? Dieses eine Problem ist derzeit ein Ausschlusskriterium für unsere kleine, finanzschwache Gruppe, die versucht, Discourse in einer Umgebung zu betreiben, in der wir die Hosting-Hardware bereits besitzen und nicht für Cloud-Speicher bezahlen möchten (insbesondere zu den Preisen von AWS S3), nur um sicherzustellen, dass unsere Medien nicht anonym einsehbar sind.
Außerdem entschuldigen Sie bitte die mögliche Naivität dieser Frage. Es gibt doch bereits Unterstützung für separate Buckets für Uploads und Backups, oder? Wäre es schwierig, ein drittes Bucket für sichere Uploads zu unterstützen? Öffentliche Uploads landen im öffentlichen Bucket, sichere Uploads im sicheren Bucket, und es werden keine individuellen Objekt-ACLs benötigt. Und wenn sich der Sicherheitsstatus eines Objekts ändert, könnte es einfach zwischen den Buckets verschoben werden?
Ich denke, das ist ziemlich viel Arbeit. Mindestens einen Arbeitstag, aber vielleicht eine Woche?
Cdck-Hosting, das die Entwicklung finanziert, nutzt S3 für Uploads, daher sind nur selbst gehostete Seiten ohne Budget für S3 interessiert, bei denen lediglich eine Anmeldung erforderlich ist.
Wenn Ihre Nutzer Links zu Ihren Assets teilen, könnten sie diese genauso gut herunterladen, um sie weiterzugeben. Das scheint kein großes Problem zu sein.
Ich bin doch nicht verrückt, wenn ich finde, es ist seltsam, dass Post-Text geschützt ist, aber Anhänge nicht, oder?
Es gibt jedoch einen großen Unterschied zwischen absichtlichem und versehentlichem Teilen. Offensichtlich gibt es keine echte Möglichkeit, das Erstere zu verhindern. Aber Letzteres kann bereits jetzt einfach passieren, weil die Menschen die zugrunde liegende Technik nicht verstehen. Denk an E-Mail-Benachrichtigungen für Posts, die Links zu angehängten Bildern enthalten, die unabsichtlich an Nicht-Mitglieder weitergeleitet werden. Eine Option, Anhänge in E-Mails zu schwärzen, die nicht an die sichere Medienfunktion gekoppelt ist, könnte dort eine gute Alternative sein.
Selbst wenn Menschen Anhang-Links absichtlich teilen, haben sie möglicherweise einfach vergessen, dass sie aus einer geschützten Kategorie stammen. Aber in einer idealen Welt sollte der Anhang-Link für jeden ohne Zugriff auf diese Kategorie wertlos sein.
Ein aktueller oder zukünftiger Fehler in einer der S3-Implementierungen könnte potenziell auch eine anonyme Enumeration der Ressourcen in einem Bucket oder die Möglichkeit zum Raten und Brute-Force von Objekt-URLs ermöglichen. In einer idealen Welt würde ich meinen On-Prem-S3-Interface vom restlichen Internet abschotten wollen, sodass nur der Discourse-Server direkt darauf zugreifen kann.
Nicht verrückt. Sichere Uploads für Nicht-S3-Setups zu implementieren, ist definitiv etwas, wogegen ich nichts habe. Es ist nur so, dass wir keinen dringenden Bedarf oder Druck haben, dieses Feature zu entwickeln, und die Änderung ist nicht trivial.
Wir haben gelegentlich Praktikanten und Auditions-Projekte; dies ist definitiv eine Art von Projekt, das in eine dieser Kategorien passen könnte.
Ich habe einen kleinen Hack, der meiner Meinung nach sichere Uploads für loginpflichtige Seiten ermöglichen würde.
Grundsätzlich richten Sie Authentication Based on Subrequest Result | NGINX Documentation für Uploads ein. Das einzige Problem ist, dass ich keine URL finde, die bei aktiviertem Login-Erfordernis einen 403/401-Statuscode zurückgibt. Wenn also jemand versucht, einen Upload aufzurufen, ohne eingeloggt zu sein, erhält dieser einen 500-Fehler. Dies würde nur passieren, wenn jemand eine Upload-URL hätte und versucht, sie aufzurufen, ohne angemeldet zu sein, was also nicht allzu schlimm erscheint.
Es sieht ungefähr so aus:
# JP
location = /auth {
internal;
proxy_pass http://discourse/categories;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
# END JP
location ~ ^/uploads/ {
auth_request /auth; #$JP
# HINWEIS: Es ist wirklich nervig, dass wir Header nicht einfach auf der obersten Ebene definieren
# und sie dann erben können.
#
Wir haben keine Pläne, eine separate Bucket-Funktionalität für sichere Uploads zu implementieren, und wir planen auch nicht, sichere Uploads mit nicht-S3-Umgebungen oder Umgebungen ohne ACLs kompatibel zu machen. Falls in Zukunft eine ausreichende Nachfrage besteht, die es für uns sinnvoll macht, Zeit und Ressourcen in diese Arbeit zu investieren, könnten wir dies prüfen.
Warum wird https://hashhackersforum.s3.us-east-2.amazonaws.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc anstelle von https://forum.cdn.hashhackers.com/optimized/2X/3/3204e85df407adfce19e105308248aee8b3b3f57_2_690x424.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU5WBGG5Z7FNHQEIS%2F20210415%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20210415T025617Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=15c9118929ccd9c24a9594ab02a47e900269b9d921d41679a317e29d6174c2bc verwendet, obwohl ich die CDN-URL korrekt eingegeben habe?
Es stört mich nicht, diese Meldung zu ignorieren, aber da „Secure Media“ aktiviert ist, kann keine CDN verwendet werden. Diese Meldung sollte auf Seiten mit aktiviertem secure_media wahrscheinlich nicht angezeigt werden.
Nach dem Upgrade auf die Version 2.8.0.beta1 funktionieren meine Badges mit authentifizierten S3-URLs nicht mehr. Vor dem Upgrade war alles in Ordnung.
Ich habe die Tabelle uploads überprüft, und der Wert für die Spalte secure ist true.
Ah… noch ein weiterer Ort, der sichere Uploads durchführt, die es nicht sein sollten. Abzeichen sollten nicht als sicher markiert werden, da sie im Wesentlichen öffentliche Bilder sind, ähnlich wie Avatare, Kategorien-Logos und andere Elemente. Ich muss eine Korrektur vornehmen, um sicherzustellen, dass Abzeichenbilder nicht als sicher markiert werden, sowie ein Migrations-Skript, das diejenigen korrigiert, die bereits als sicher markiert sind.
Ich bin überrascht, dass dies bei dir überhaupt funktioniert hat. In Version 2.8.0 hätte nichts dies beeinflussen sollen.
vielen Dank für deine Antwort. Das ist mein erstes Mal mit Ruby, und ich bin begeistert, wie klar diese Sprache sein kann. Nach einigen Stunden Debugging glaube ich, dass ich herausgefunden habe, wo ich suchen muss. Ich habe wohl das Gegenteil von dem gemacht, was du gesagt hast Ich habe einige Zeilen im Badge-Modell eingefügt, und jetzt können die Bilder geladen werden. Ich sehe auch, dass es dort eine Flagge for_site_setting gibt. Ich vermute, dass sie diese Information nutzt, um die ACL für Objekte auf S3 anzupassen, und setze den Wert für diese Spalte auf false.
app/models/badge.rb
def image_url
if image_upload_id.present?
return upload_cdn_path(image_upload.url) if !image_upload.url.include?(SiteSetting.Upload.absolute_base_url)
uri = URI.parse(image_upload.url)
Rails.application.routes.url_for(
controller: "uploads",
action: "show_secure",
path: uri.path[1..-1],
only_path: true
)
end
end
Ich werde mir ansehen, was sich im nächsten Upgrade ändert, um mehr darüber zu erfahren.
Könntest du mir sagen, welche Version die beste für den Produktiveinsatz ist?
Vielen Dank!
Ich hoffe, ich kann in Zukunft mehr zur Codebasis beitragen.
Die Änderung, die du am Badge-Modell vorgenommen hast, wird mit Sicherheit funktionieren, und es ist großartig, dass du das beim ersten Mal, als du Ruby verwendet hast, bereits hinbekommen hast! Ich werde trotzdem den Kernfehler beheben, bei dem Badges fälschlicherweise als sicher markiert werden.
Unser Branch tests-passed ist die beste Version für den Einsatz in der Produktion, da dort alle neuesten Fehlerkorrekturen sofort verfügbar sind. Manche bevorzugen jedoch den Beta-Branch, der etwa alle paar Wochen Korrekturen und Änderungen erhält.
Ich gebe dir Bescheid, sobald die Korrektur für die fälschliche Markierung von Badges als sicher abgeschlossen ist.
…aber ich frage mich, ob das Problem mit deinem Kommentar hier zusammenhängt?
Ist es unterstützt, dass Benutzer Avatare hochladen, wenn die sichere Medien-Upload-Funktion aktiviert ist? Derzeit erhalte ich einen Fehler, aber ich frage mich, ob das daran liegt, dass Avatare in denselben Bucket hochgeladen werden, in dem der öffentliche Zugriff nicht erlaubt ist…
1 „Gefällt mir“
Canapin
(Coin-coin le Canapin)
Hat dieses Thema aufgeteilt,
126
Ich habe “sichere Medien” und zugehörige Einstellungen kürzlich in “sichere Uploads” umbenannt, da sie sich nicht nur auf Bilder/Videos usw. beziehen und jeder sie sowieso allgemein als sichere Uploads bezeichnet. Der relevante Core-Commit ist hier:
Der Eröffnungsbeitrag dieses Themas wurde nun aktualisiert, um dies widerzuspiegeln.
Ich habe einige Zeilen im Badge-Modell eingefügt, und jetzt können die Bilder geladen werden. Ich sehe auch, dass es dort eine Flagge for_site_setting gibt. Ich vermute, dass sie diese Information nutzt, um die ACL für Objekte auf S3 anzupassen, und setze den Wert für diese Spalte auf false.