Hello,
I tried using Force https and it seemed to work for me except it was causing login problems. However, the logos are loaded using http by default. They should use the // protocol and let the browser decide which one to use, right? Or maybe there is another solution I’m missing?
Thanks
Hi Eddie,
What version of Discourse are you running? In recent versions logos are uploaded via site settings, instead of being linked using a URL, so this should no longer be an issue.
Hi Joshua, We recently upgraded to v2.2.5. During the previous upgrade, before force https, I believe I deleted the post where the logos were uploaded and switched to the site settings. Everything was fine. Then with v2.2.5, I can’t get rid of the http:// part without force https. I tried reuploading, the wizard, even modifying the images so their hash was different. No luck
Sorry, now I’m confused. Is force_https enabled or not? Is there any possibility you’re overriding the uploaded logos via themes? If your force_https is enabled, and your logos are served via site settings, there should not be a mixed content warning. Are you able to share a link to your site so I can take a look?
It was enabled, thought the upgrade was over. Then our QA reports that logins are not working. so we disabled force https for now. You can test here //forum.y8.com
I checked the themes and didn’t spot anything that might cause this https problem. We mostly use stock, though it is an old stock theme.
With force_https disabled, I can’t test this. We rely on that setting to ensure assets are served over https, not http. Regarding the login issue, it appears you’re using SSO, so ensure the SSO redirect from your provider links to your site via https://, not http://. Once you’ve re-enabled force_https I can take another look.
This forum is using the oauth2 basic plugin. Maybe there is a problem with that, might require a version roll back. Not sure yet. I did check the settings, all addresses were using https, so no obvious problem there.
Tenho um problema semelhante aqui:
Depois de descobrir que o logotipo e o ícone grande são carregados via HTTP, causando conteúdo misto, ativar o force_https resolveu isso. Mas o login não era mais possível, resultando em um loop de redirecionamento. Após desativar essa opção, o login voltou a funcionar.
Por que isso está acontecendo?
E por que apenas essas duas imagens são carregadas via HTTP, enquanto todos os outros recursos são carregados corretamente via HTTPS?
Qual é o seu método de login? Estou imaginando que não seja login local (usuário/senha), certo?
Existe algum proxy ou outro serviço à frente da sua instalação?
Estou usando SSO por meio de outro aplicativo web.
O nginx é usado como proxy reverso.
Como o nginx foi configurado?
O Nginx está redirecionando todas as solicitações HTTP para HTTPS, então não deveria ser possível carregar conteúdo via HTTP de qualquer forma.
Minha primeira ideia seria verificar novamente sua configuração de SSO para ver para onde ela está direcionando os usuários, bem como quais origens ela aceita. Certifique-se de que tudo na configuração do SSO esteja usando https://. Também é possível que isso seja um problema do Nginx. Será difícil depurar aqui com múltiplas variáveis…
Tenho exatamente o mesmo problema relatado por outras pessoas aqui e neste thread.
O problema não está relacionado à implementação do SSO nem ao servidor web: no meu caso, as requisições HTTP são redirecionadas para HTTPS, que então passam pelo proxy reverso. O SSO funciona perfeitamente se eu redirecionar o usuário para https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE e force_https estiver definido como false. Isso demonstra que tanto a parte do SSO quanto o proxy funcionam perfeitamente. O problema só ocorre quando altero force_https para true. Quando já possuo uma sessão pré-existente, posso alterar force_https para true e usar o Discourse sem nenhum problema (o que reforça ainda mais que o problema não está relacionado ao proxy reverso). Manter force_https como false não é uma opção, pois isso quebra os logotipos e o Chrome fica insatisfeito quando há mistura de ativos de HTTP e HTTPS (ele exibe um pequeno alerta na barra de endereço informando que a página não é segura).
Como é a sua configuração do nginx e você tem um cabeçalho X-Forwarded-Proto nela?
Muito obrigado. Sim; isso resolveu o problema. Então era realmente relacionado ao proxy. Desculpe por ter assumido o contrário, apenas porque o conteúdo foi carregado.
Para fins de completude, estou usando o Apache como Proxy Reverso e não o nginx. Aqui estão as linhas de configuração relevantes:
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
Adicionar a primeira linha resolveu o problema.
Olá,
Desculpe trazer isso novamente, mas na verdade não estou conseguindo eliminar os avisos de conteúdo misto no Firefox. O engraçado é que tenho uma configuração bastante semelhante… mais ou menos. Talvez alguém possa trazer algumas ideias ou melhorias. Não sou exatamente um grande especialista em diretivas do Apache, mas faz sentido para mim – pelo menos um pouco.
Temos o Discourse rodando em Docker atrás de um Apache via Reverse Proxy, e gerenciamos os certificados do Let’s Encrypt com o ISPConfig, já que temos muitos domínios “normais” rodando em nosso servidor.
Configuramos o Reverse Proxy com diretivas do Apache pelo ISPConfig. Nossa configuração fica assim:
ProxyPreserveHost On
ProxyPass /.well-known/acme-challenge !
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://sub.domain.de$1 [R,L]
Ainda temos avisos de conteúdo misto no Firefox. O que tentei foi ativar a opção force ssl nas configurações. Como primeiro efeito, não conseguimos mais fazer login. Autenticamos apenas por usuário e senha. Então, tentei a correção mencionada:
Bom, com force ssl ativado, o login agora é possível. Mas ainda temos o Firefox exibindo avisos de conteúdo misto. O console diz:
e
estão sendo entregues via HTTP… Também tentamos reenviar essas imagens de marcação usando sub.domain.de/wizard, mas ainda estamos com esse problema… Existe alguma maneira de… não sei, forçar o reprocessamento das imagens otimizadas usando HTTPS? Há algo de errado com nossa configuração de Reverse Proxy?
Agradeceria muito qualquer ajuda adicional aqui. É como um oceano de possíveis configurações de Reverse Proxy com SSL forçado pelo Let’s Encrypt (gerenciado pelo) Apache (e não pela configuração nativa do Discourse), então sinto que estou me afogando. E tenho a sensação de que poucas pessoas usam o Apache como host com Reverse Proxy e essa configuração do Let’s Encrypt que estamos usando. Ou talvez sejamos apenas nós que estamos configurando tudo errado.
Bom, como disse, agradeço qualquer dica. Obrigado desde já!
Tente SiteIconManager.ensure_optimized! a partir do console do Rails.
Uau, que resposta rápida! Muito obrigado.
Bem, enquanto isso… não sei se foi desencadeado por deixar o tempo passar até que algo acontecesse. Mas o que fiz depois de enviar meu primeiro post foi simplesmente fazer o upload dessas duas imagens (favicon e ícone da Apple) novamente, sem usar o assistente, mas sim nas configurações de administração (marcação). E justamente naquele momento, eu ia fechar a aba só para verificar se o login e tudo mais estavam funcionando corretamente… adivinhe só. Os erros de conteúdo misto do Firefox desapareceram!
Uau!
Bem, @RGJ, ainda assim muito obrigado. Acho que isso também corrigiria o reprocessamento das imagens otimizadas. Você acha que isso foi acionado no meio do caminho por causa de um limite de tempo ou pelo upload das imagens novamente usando o painel de administração, e não o assistente?
Obrigado novamente, especialmente a @alphanoob1337, por finalmente fazer isso funcionar!
Uau, isso é bem inconveniente para uma segunda-feira, mas sair do escritório com uma sensação agradável e feliz 
