Es ist im Beispiel-Konfigurationsblock für Vultr im Originalbeitrag festgelegt. Kopieren und fügen Sie ihn in Ihre app.yml ein und passen Sie die erforderlichen Felder an.
Danke, diesen Teil habe ich übersehen:
Das läuft bei mir nicht so reibungslos, entschuldige bitte meine vielen Antworten.
Wenn ich das oben Genannte tue, sollte ich dann die S3- und Backup-Einstellungen im Admin-Bereich ignorieren?
Oder sollten die Einstellungen im Admin-Bereich ebenfalls konfiguriert werden?
Du musst einfach nur diesen Leitfaden im OP befolgen, und du erhältst eine funktionsfähige Objektspeicherkonfiguration.
Das Setzen dieser Variablen macht sie für die UX unzugänglich. Sie müssen sie wie hier beschrieben und nicht über die UX festlegen.
Ich denke, es funktioniert (meistens?) jetzt, aber ist diese Content-Security-Policy script-src sicher?
Ich nutze AWS für zwei S3-Buckets (für Uploads und Backups) sowie zwei CloudFront-CDNs (für Dateien und Assets). Wenn ich eigene CNAMEs für die CloudFront-CDNs verwende, erhalte ich beim Laden von Discourse zahlreiche script-src-Netzwerkfehler im Browser. Sobald ich diese Einträge in meine CSP aufgenommen habe, treten keine Fehler mehr auf.
Sind das die URLs, die du in den Umgebungsvariablen aus dem Eröffnungspost angegeben hast? Und verwenden sie HTTPS?
Ja, ich erhalte keine script-src-Warnungen, wenn ich die beiden d23whatever.cloudfront.net-URLs in die Umgebungsvariablen eintrage. Sobald ich jedoch meine benutzerdefinierten URLs, also community-cdn.mydomain und files-cdn.mydomain, in die Umgebungsvariablen eintrage, treten diese script-src-Warnungen auf. Offensichtlich löst das Stripe-JS-Skript weiterhin diese Warnung aus, obwohl es in meiner Content-Security-Policy unter script-src enthalten ist.
Ich habe S3-Uploads und Objektspeicher wie hier im OP beschrieben eingerichtet, jedoch ohne CDN.
Für die Variable DISCOURSE_S3_CDN_URL habe ich Folgendes:
https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com
Alles scheint in Ordnung zu sein, einschließlich Backups. Allerdings erscheint in der Konsole dieser Fehler, wenn eine Antwort auf einen Beitrag gestartet wird:
Die Request-URL im Fehler ist tatsächlich eine Zeichenkette aus zwei URLs, was die Ursache zu sein scheint?
https://mydiscourse.com/t/uploads-test-for-s3/79/https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com/assets/markdown-it-bundle-a7328b73d3e7b030770eab70f10bdb0af655b3d8fa929bc49f1ad04c4cdaa198.br.js
Ein CDN ist zwingend erforderlich, damit es korrekt funktioniert.
Ich befinde mich ebenfalls in dieser Situation mit einem konfigurierten Objektspeicher (minio), aber ohne CDN. Könnte dies ein Anwendungsfall sein, der unterstützt werden könnte?
Nach allem, was ich bisher in meinen Tests sehe, gibt es nur bei der JavaScript-Datei markdown-it-bundle Probleme, da sie auf die falsche URL verweist: DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Das scheint tatsächlich ein Fehler zu sein. Wenn ich die Variable DISCOURSE_CDN_URL setze, verweist sie immer noch auf die falsche URL in der Form DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Sie sollte auf DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js verweisen.
Andere JavaScript-Assets verweisen auf die richtige URL.
Ich vermute, basierend auf dem, was Sie sagen, dass ich weitere Probleme haben werde, die ich noch nicht identifiziert habe. Können Sie mir vielleicht mehr Informationen darüber geben, was schiefgehen könnte?
Wenn ich es richtig verstehe, befinden sich die JavaScript-Assets im Objektspeicher, und die Stylesheets sollten über ein CDN geliefert werden. Könnten die Stylesheets ohne CDN wie gewohnt von der Anwendung geliefert werden? (Nach allem, was ich sehe, ist das der Fall.)
Vielen Dank für Ihre Hilfe.
Dies ist laut dem OP kein unterstützter Anwendungsfall:
Hallo zusammen,
ich habe einen neuen Discourse-Server mit Lightsail eingerichtet und dabei diese Anleitung für S3-Uploads und -Backups verwendet: Dateien und Bilder in S3 hochladen
Nach der Einrichtung erhielt ich beim Hochladen eines Bildes die Fehlermeldung „Der Bucket erlaubt keine ACLs“.
Hier ist meine Richtlinie für S3:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:GetObjectVersionTagging",
"s3:CreateBucket",
"s3:GetObjectAcl",
"s3:GetBucketObjectLockConfiguration",
"s3:PutLifecycleConfiguration",
"s3:GetObjectVersionAcl",
"s3:PutObjectTagging",
"s3:DeleteObject",
"s3:DeleteObjectTagging",
"s3:GetBucketPolicyStatus",
"s3:GetObjectRetention",
"s3:GetBucketWebsite",
"s3:ListJobs",
"s3:DeleteObjectVersionTagging",
"s3:GetObjectLegalHold",
"s3:GetBucketNotification",
"s3:PutBucketCORS",
"s3:GetReplicationConfiguration",
"s3:ListMultipartUploadParts",
"s3:PutObject",
"s3:GetObject",
"s3:DescribeJob",
"s3:PutObjectVersionAcl",
"s3:GetAnalyticsConfiguration",
"s3:GetObjectVersionForReplication",
"s3:GetLifecycleConfiguration",
"s3:GetAccessPoint",
"s3:GetInventoryConfiguration",
"s3:GetBucketTagging",
"s3:GetBucketLogging",
"s3:ListBucketVersions",
"s3:ReplicateTags",
"s3:ListBucket",
"s3:GetAccelerateConfiguration",
"s3:GetBucketPolicy",
"s3:GetEncryptionConfiguration",
"s3:GetObjectVersionTorrent",
"s3:AbortMultipartUpload",
"s3:PutBucketTagging",
"s3:GetBucketRequestPayment",
"s3:GetAccessPointPolicyStatus",
"s3:GetObjectTagging",
"s3:GetMetricsConfiguration",
"s3:PutObjectAcl",
"s3:GetBucketPublicAccessBlock",
"s3:ListBucketMultipartUploads",
"s3:ListAccessPoints",
"s3:PutObjectVersionTagging",
"s3:GetBucketVersioning",
"s3:GetBucketAcl",
"s3:GetObjectTorrent",
"s3:GetAccountPublicAccessBlock",
"s3:ListAllMyBuckets",
"s3:GetBucketCORS",
"s3:GetBucketLocation",
"s3:GetAccessPointPolicy",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::mybucket-upload",
"arn:aws:s3:::mybucket-upload/*",
"arn:aws:s3:::mybucket-backup",
"arn:aws:s3:::mybucket-backup/*"
]
}
]
}
Und hier ist meine öffentliche Zugriffskonfiguration für den S3-Bucket:
Könnte mir jemand bei der Lösung dieses Problems helfen?
Vielen Dank
Viele Grüße,
Quang
Sollte meine Staging-Website denselben S3-Bucket wie meine Produktions-Website verwenden?
Nein, das wäre sehr unsicher und könnte Dateien löschen, die in der anderen Umgebung noch vorhanden sein sollten, und Dateien aus der anderen Umgebung ändern (was zu fehlenden oder falschen Dateien usw. führen könnte).
Sowohl die Buckets als auch die Anmeldeinformationen sollten unterschiedlich sein (und die Staging-Anmeldeinformationen sollten keinen Zugriff auf den Produktions-Bucket haben, insbesondere in Bezug auf Schreib- und Löschvorgänge).
Vielleicht gibt es eine Möglichkeit, Pfade mit unterschiedlichen Anmeldeinformationen für jeden Pfad zu verwenden, aber die Wahrscheinlichkeit, sich ins eigene Fleisch zu schneiden, ist hoch, daher rate ich zur Verwendung separater Buckets.
Müssen DISCOURSE_CDN_URL und DISCOURSE_S3_CDN_URL ebenfalls getrennt sein?
Ich nehme es an, denn wenn Ihre Staging- und Produktionsdomänen/-URLs unterschiedlich sind (was der Fall ist, oder?), dann muss DISCOURSE_CDN_URL (die auf den CDN-Anbieter verweist, der auf Ihre Website-Domäne verweist) für Staging und Produktion unterschiedlich sein. Die gleiche Logik gilt für DISCOURSE_S3_CDN_URL (da verschiedene Buckets unterschiedliche URLs haben sollten).
Hallo zusammen, ich bin ziemlich neu bei S3 und bin mir nicht ganz sicher, wie ich das formulieren soll, aber ich werde mein Bestes geben. Ich bin gerade auf S3 für Uploads und Backups umgestiegen und habe Discourse Connect verwendet, um Anmeldungen auf anderen Teilen meiner Website zu ermöglichen, aber jetzt funktionieren Profilbilder nicht mehr. Ich glaube, das hat mit CORS-Richtlinien zu tun, aber ich bin mir nicht sicher, wo ich das konfigurieren kann. Ich würde es idealerweise für forum.domain.tld und domain.tld zulassen – oder ein Wildcard für alle Subdomains würde auch funktionieren. Ist das etwas, das ich in Discourse einstellen würde, oder wo genau? Ich benutze Vultr Object Storage, falls das einen Unterschied macht.
Kann die Versionierung für den files S3-Bucket aktiviert werden? Ist AWS Backup die empfohlene Methode zum Sichern von S3-Buckets für Discourse?
Ja.
Die Verwendung der Versionierung oder die Synchronisierung in eine andere Region sind alles gute Strategien.



