Olá.
Temos uma instalação do Discourse v2.4.0.beta2 +346 que estava originalmente disponível em include.metaring.com,
utilizando o Apache HTTP Server no Ubuntu, que:
- Redireciona todas as requisições HTTP para HTTPS
- Gerencia o certificado SSL (LetsEncrypt) automaticamente
- Todas as requisições eram redirecionadas via Proxy para usar nginx http sock, portanto as portas 80 e 443 do Docker do Discourse estão desativadas/não utilizadas
Fizemos:
./launcher enter app
rails c
[1] pry(main)> SiteSetting.force_https = true
=> true
Para ter certeza absoluta de que tudo era servido via HTTPS (tivemos vários erros caso contrário)
E tudo funcionava perfeitamente.
Então decidimos mover a aplicação (sem tocar no banco de dados ou em outras coisas) para include.metaring.com/discourse, então editamos o arquivo app.yml da seguinte forma:
DISCOURSE_HOSTNAME: include.metaring.com<— Inalterado, igual ao de antesDISCOURSE_RELATIVE_URL_ROOT: /discourse
Então, para ter extremamente certeza, fizemos:
./launcher stop app
./launcher destroy app
./launcher cleanup
./launcher rebuild app
Claro que também inserimos no arquivo de configuração do Apache as regras para ProxyPass corretamente de /discourse para unix:/../../nginx.http.sock|http://localhost/*discourse*
Após isso, a aplicação, é claro, ficou online, mas apresentou muitos problemas:
-
Todo o conteúdo estático (plugins, assets, imagens, javascripts, uploads) não estava disponível. Após longas sessões de depuração e buscas infrutíferas na web para fazê-los funcionar, criamos algumas regras de proxy no Apache para tunelá-los para o caminho localhost na raiz, sem o prefixo /discourse (por exemplo, /disourse/plugins aponta para → unix:/../../nginx.http.sock|http://localhost/plugins e assim por diante)
-
Alguns caminhos /uploads vinham das páginas web sem o prefixo /discourse, então precisávamos escrever outra regra de proxy no Apache que movesse de /uploads/ para unix:/../../nginx.http.sock|http://localhost/discourse/uploads
-
Agora a coisa mais estranha: quando o cliente envia requisições contendo /uploads/default/ ou /discourse/uploads/default/ (conteúdo estático), precisamos seguir a solução do ponto 1 descrita anteriormente e redirecionar ambos para
http://localhost/uploads/default/(sem o prefixo /discourse), enquanto outras requisições /uploads/ ou /discourse/uploads/ que não contêm o prefixo /default no caminho devem ser redirecionadas parahttp://localhost/discourse/uploads/(note que sem o caminho default significa que são chamadas de serviços web)
Com todas essas 9 regras de proxy que inserimos, tudo funciona perfeitamente novamente, mesmo sob o caminho /discourse. Mas achamos extremamente estranho que precisássemos escrever tudo isso para fazer tudo funcionar novamente.
Estamos fazendo algo errado?
Existe algum outro método inteligente para gerenciar essa situação?
=== EDIÇÃO ===
Esqueci outra coisa que talvez esteja relacionada:
Quando o usuário tenta fazer upload de uma imagem personalizada para usar como avatar pessoal, o upload é bem-sucedido e a miniatura da imagem é exibida corretamente.
Mas quando o botão Salvar alterações é pressionado e a página é recarregada, o avatar volta ao avatar padrão do usuário
Ao verificar o arquivo
produciton.log, ele mostra que o erro é Code 418.Outros uploads de imagens funcionam bem.
Obrigado antecipadamente pelas respostas e pelo seu trabalho incrível!