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 curtidas
Thanks, I missed this bit:
1 curtida
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 curtida
You just need to follow this guide here in the OP and you will get a functional object storage configuration.
3 curtidas
Setting those variables makes them unavailable from the UX. You must set them as described here rather than the ux.
2 curtidas
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 curtida
Are those the urls you put in the env variables described in the OP? And are they https?
1 curtida
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 curtidas
Configurei Uploads do S3 e armazenamento de objetos conforme descrito aqui no OP, mas sem uma CDN.
Para a variável DISCOURSE_S3_CDN_URL, tenho isto:
https://my-bucket-uploads.s3.dualstack.us-west-2.amazonaws.com
Tudo parece bem, incluindo backups, no entanto, no console este erro aparece quando uma resposta a uma postagem é iniciada:
A URL da solicitação no erro é, na verdade, uma string de duas URLs, o que parece ser a causa?
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 curtidas
Uma CDN é obrigatória para que funcione corretamente.
4 curtidas
Também estou nesta situação com um object store configurado (minio) mas sem CDN. É um caso de uso que poderia ser suportado?
Pelo que estou vendo até agora nos meus testes, apenas o arquivo js markdown-it-bundle está com problemas, pois aponta para a URL errada - DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Na verdade, parece um bug para este, se eu definir a variável DISCOURSE_CDN_URL, ele ainda aponta para a URL errada neste formato DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Na verdade, deveria apontar para DISCOURSE_S3_CDN_URL/assets/markdown-it-bundle-HASH.br.js
Outros assets js estão apontando para a URL correta.
Acho que, pelo que você está dizendo, terei outros problemas que ainda não identifiquei. Talvez você possa me dar mais informações sobre o que pode dar errado?
Se entendi bem, os assets js estão no object store, as folhas de estilo deveriam estar em uma CDN. Sem uma CDN, as folhas de estilo poderiam ser entregues pelo aplicativo como de costume? (pelo que estou vendo, é o caso)
Obrigado pela sua ajuda.
3 curtidas
Esse não é um caso de uso suportado, de acordo com o OP:
1 curtida
Prezados todos,
Configurei um novo servidor Discourse com Lightsail, usando este guia para uploads e backups S3 configurando uploads de arquivos e imagens para S3
Após a configuração, recebi o erro “O bucket não permite ACLs” na tela ao fazer upload de uma imagem
Aqui está minha política para 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/*"
]
}
]
}
E aqui está meu acesso público configurado para o bucket S3:
Alguém poderia me ajudar a resolver este problema, por favor?
Muito obrigado
Atenciosamente,
Quang
3 curtidas
Meu site de staging deve usar o mesmo bucket S3 que meu site de produção?
1 curtida
Não, isso seria muito inseguro e poderia excluir arquivos que ainda deveriam existir no outro ambiente e alterar arquivos do outro ambiente (o que poderia causar arquivos ausentes, arquivos incorretos e assim por diante).
Tanto os buckets quanto as credenciais devem ser diferentes (e as credenciais de staging não devem ter acesso ao bucket de produção, especialmente em relação a operações de gravação e exclusão).
Talvez haja uma maneira de usar caminhos com credenciais diferentes para cada caminho, mas as chances de se prejudicar são altas, então eu aconselho a usar buckets separados.
5 curtidas
DISCOURSE_CDN_URL e DISCOURSE_S3_CDN_URL também precisam ser separados?
1 curtida
Presumo que sim, porque se seus domínios/URLs de staging e produção forem diferentes (eles são, não são?), então DISCOURSE_CDN_URL (que acaba apontando para o provedor de CDN, que aponta para o domínio do seu site) deve ser diferente para staging e produção. A mesma lógica se aplica a DISCOURSE_S3_CDN_URL (porque buckets diferentes devem ter URLs diferentes).
4 curtidas
Olá a todos, sou bem novo no S3, então não tenho certeza de como formular isso, mas farei o meu melhor. Então, acabei de mudar para usar o S3 para uploads e backups e tenho usado o Discourse Connect para permitir logins em outras partes do meu site, mas agora as imagens de perfil não funcionam. Acredito que isso tenha a ver com políticas CORS, mas não tenho certeza de onde posso configurá-lo. Eu idealmente gostaria de colocar na lista de permissões para forum.domain.tld e domain.tld - ou um curinga em todos os subdomínios também funcionaria. Isso é algo que eu definiria no Discourse, ou onde exatamente? Estou usando o armazenamento de objetos Vultr, se isso fizer alguma diferença.
1 curtida
A versão pode ser habilitada no bucket S3 files? O AWS Backup é a maneira recomendada de fazer backup de buckets S3 para Discourse?
1 curtida
Sim.
Usar o versionamento ou sincronizar para uma região diferente são todas boas estratégias.
4 curtidas