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개의 좋아요
Thanks, I missed this bit:
1개의 좋아요
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개의 좋아요
You just need to follow this guide here in the OP and you will get a functional object storage configuration.
3개의 좋아요
Setting those variables makes them unavailable from the UX. You must set them as described here rather than the ux.
2개의 좋아요
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개의 좋아요
Are those the urls you put in the env variables described in the OP? And are they https?
1개의 좋아요
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개의 좋아요
I set up S3 Uploads and object storage as outlined here in the OP, but without a CDN.
For the DISCOURSE_S3_CDN_URL variable, I have this:
https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com
All seems fine, including backups, however, in the console this error shows up when a reply to a post is started:
The request url in the error is actually a string of two urls which seems like the cause?
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개의 좋아요
A CDN is mandatory for it to work correctly.
4개의 좋아요
I’m also in this situation with an object store configured (minio) but no CDN. Is it a use case that could be supported ?
From what I’m seeing so far in my tests there is only the markdown-it-bundle js file that is having issues as its pointing to the wrong URL - DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
It actually looks lit a bug for this one, if I set DISCOURSE_CDN_URL variable, it still points to the wrong URL in this form DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/markdown-it-bundle-HASH.br.js
it should point to DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Other js assets are pointing to the right URL ’
I guess from what you are saying I will have other issues that I have not identified yet. Maybe you can give me more info on what could go wrong ?
If I undestand it well, js assets are on the object store, stylesheets should be on a CDN. WIthout a CDN could the stylesheets be delivered by the app as usual ? (from what i’m seeing its the case)
Thanks for your help
3개의 좋아요
That is not a supported use case per the OP:
1개의 좋아요
Dear all,
I set up a new discourse server with Lightsail, using this guide for S3 uploads and backups setting-up-file-and-image-uploads-to-s3
After setup, I got the error shown “The bucket does not allow ACLs” on the screen when I upload an image
Here is my policy for 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/*"
]
}
]
}
And here is my setup public access for S3 bucket:
Would someone help me to solve this issue, please?
Thanks so much
Cheers,
Quang
3개의 좋아요
Should my staging site use the same S3 bucket as my production site?
1개의 좋아요
No, that would be very unsafe, and it could delete files that should still exist in the other environment and change files from the other environment (which could cause missing files, wrong files, and so on).
Both the buckets as well as the credentials should be different (and the staging credentials shouldn’t have access to the production bucket, specially regarding write and delete operations).
Maybe there’s a way using paths with different credentials for each path, but the chances of shooting your own foot are high, so I advise to use separate buckets.
5개의 좋아요
DISCOURSE_CDN_URL and DISCOURSE_S3_CDN_URL need to be separate as well?
1개의 좋아요
I assume so, because if your staging and production domains/urls are different (they are, aren’t they?), then DISCOURSE_CDN_URL (that ends up pointing to the CDN provider, which points to your website domain) is expected to be different for staging and production. The same logic applies to DISCOURSE_S3_CDN_URL (because different buckets should have different urls).
4개의 좋아요
Hey all, I’m pretty new to S3, so I’m not entirely sure how to phrase this, but I’ll try my best. So, I just switched to using S3 for uploads and backups and I have been using Discourse Connect in order to allow for logins on other parts of my site, but now profile images don’t work. I believe this has to do with CORS policies, but I’m not sure where I could configure it. I would ideally want to whitelist it for forum.domain.tld and domain.tld - or a wildcard on all subdomains would work too. Is this something I would set in Discourse, or where exactly? I’m using Vultr object storage if that makes a difference.
1개의 좋아요
Can versioning be enabled on the files S3 bucket? Is AWS Backup the recommended way to backup S3 buckets for Discourse?
1개의 좋아요
Yes.
Using versioning, or syncing to a different region are all good strategies.
4개의 좋아요