Está definido no bloco de configuração de exemplo para Vultr no post original. Copie e cole no seu app.yml e ajuste os campos necessários.
2 curtidas
Obrigado, perdi essa parte:
1 curtida
Isso não está indo muito bem para mim, desculpe por responder tantas vezes.
Se eu fizer o acima, devo ignorar as configurações do painel de administração para S3 e backups?
Ou as configurações do painel de administração também devem ser configuradas?
1 curtida
Basta seguir este guia no OP e você obterá uma configuração de armazenamento de objetos funcional.
3 curtidas
A configuração dessas variáveis as torna indisponíveis na UX. Você deve defini-las conforme descrito aqui, e não na UX.
2 curtidas
Acho que está (quase?) funcionando agora, mas essa content security policy script src é segura?
Estou usando a AWS para dois buckets S3 (para uploads e backups) e dois CDNs CloudFront (para arquivos e recursos). Quando uso meus próprios CNAMEs para os CDNs CloudFront, recebo vários erros de rede de script-src no navegador ao carregar o Discourse. Os erros desapareceram após adicionar essas entradas ao meu CSP.
1 curtida
São essas as URLs que você colocou nas variáveis de ambiente descritas no tópico original? E elas são https?
1 curtida
Sim, não recebo avisos de script-src quando coloco as duas URLs d23whatever.cloudfront.net nas variáveis de ambiente. No entanto, quando coloco minhas URLs personalizadas, ou seja, community-cdn.mydomain e files-cdn.mydomain, nas variáveis de ambiente, é nesse momento que recebo esses avisos de script-src. E, aparentemente, o Stripe JS ainda está me dando esse aviso, mesmo estando no meu script src da política de segurança de conteúdo.
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