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 Likes
Thanks, I missed this bit:
1 Like
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 Like
You just need to follow this guide here in the OP and you will get a functional object storage configuration.
3 Likes
Setting those variables makes them unavailable from the UX. You must set them as described here rather than the ux.
2 Likes
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 Like
Are those the urls you put in the env variables described in the OP? And are they https?
1 Like
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 Likes
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 Likes
A CDN is mandatory for it to work correctly.
4 Likes
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 Likes
That is not a supported use case per the OP:
1 Like
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 Likes
Should my staging site use the same S3 bucket as my production site?
1 Like
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 Likes
DISCOURSE_CDN_URL and DISCOURSE_S3_CDN_URL need to be separate as well?
1 Like
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 Likes
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 Like
Can versioning be enabled on the files S3 bucket? Is AWS Backup the recommended way to backup S3 buckets for Discourse?
1 Like
Yes.
Using versioning, or syncing to a different region are all good strategies.
4 Likes