Konfigurieren Sie einen S3-kompatiblen Objektspeicheranbieter für Uploads

It’s set in the example configuration block for Vultr in the OP. Copy and paste into your app.yml and adjust the necessary fields.

2 „Gefällt mir“

Thanks, I missed this bit:

1 „Gefällt mir“

This isn’t going smoothly for me, sorry to reply so many times.

If I do the above, should I ignore the admin panel settings for s3 and backups?

Or should admin panel settings be configured as well?

1 „Gefällt mir“

You just need to follow this guide here in the OP and you will get a functional object storage configuration.

3 „Gefällt mir“

Setting those variables makes them unavailable from the UX. You must set them as described here rather than the ux.

2 „Gefällt mir“

I think it’s (mostly?) working now, but is this content security policy script src safe?

I’m using AWS for two S3 containers (for uploads & backups), and two CloudFront CDNs (for files & assets). When I use my own CNAMEs for the CloudFront CDNs, I get a bunch of script-src network errors in my browser when loading Discourse. No more errors after adding those entires to my CSP.

1 „Gefällt mir“

Are those the urls you put in the env variables described in the OP? And are they https?

1 „Gefällt mir“

Yes, I don’t have script-src warnings when I put the two d23whatever.cloudfront.net URLs in the env variables. When I put my custom URLs, i.e. community-cdn.mydomain and files-cdn.mydomain, in the env variables, that’s the time I get these script-src warnings. And apparently the stripe js is still giving me this warning even though it’s in my content security policy script src.

2 „Gefällt mir“

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

2 „Gefällt mir“

Ein CDN ist zwingend erforderlich, damit es korrekt funktioniert.

4 „Gefällt mir“

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.

3 „Gefällt mir“

Dies ist laut dem OP kein unterstützter Anwendungsfall:

1 „Gefällt mir“

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

3 „Gefällt mir“

Sollte meine Staging-Website denselben S3-Bucket wie meine Produktions-Website verwenden?

1 „Gefällt mir“

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.

5 „Gefällt mir“

Müssen DISCOURSE_CDN_URL und DISCOURSE_S3_CDN_URL ebenfalls getrennt sein?

1 „Gefällt mir“

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).

4 „Gefällt mir“

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.

1 „Gefällt mir“

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?

1 „Gefällt mir“

Ja.

Die Verwendung der Versionierung oder die Synchronisierung in eine andere Region sind alles gute Strategien.

4 „Gefällt mir“