Solicitações de fontes inseguras

Suporte
1 
Conteúdo Misto: A página em '\u003cURL\u003e' foi carregada via HTTPS, mas solicitou uma fonte insegura '\u003cURL\u003e'. Esta solicitação foi bloqueada; o conteúdo deve ser servido via HTTPS

E 40 solicitações de fontes do gem discourse-fonts. Esta é uma instalação nova onde Postgres e Redis estão rodando em um servidor separado dentro da rede local e a conexão é “socketed”, mas servida para o exterior via https, é claro. Existem threads semelhantes, mas nenhuma resposta clara para mim. A verificação do CSS aponta para wizard.scss (source-mapped). Alguma dica?

2

Você habilitou a configuração force https?

1 curtida
3

Mais provavelmente não. Onde eu a configuro? E por que ela seria necessária em primeiro lugar, em vez de o CSS solicitar ativos estáticos via https ou referências relativas?

FWIW - no servidor web voltado para o exterior, eu tenho a configuração típica de 301.

Edição:

Encontrei a configuração com base em esta postagem, obrigado @Arkshine.

1 curtida
4

Não tenho certeza por que você tem um link http em algum lugar; https deve ser imposto de qualquer maneira.

Você pode encontrar na barra de pesquisa:

image
image861×193 6.81 KB

2 curtidas
5

Bem, eu também não. Eu não modifiquei nada. Apenas o launcher build app regular. Esses URLs parecem estar no CSS processado, que obviamente eu não toquei (nem o scss) de forma alguma. Eu também não encontrei nada relacionado a https no app.yml, então… não sei. O force_https parece resolver o problema.

1 curtida
6

FORCE_HTTPS informa ao Discourse para reescrever as requisições.

É necessário mesmo que você esteja fazendo encapsulamento SSL fora do contêiner para evitar o problema que você está descrevendo.

1 curtida
7

Depende de como definimos “necessário”. Atualmente, pode ser necessário contornar o problema real, que é que os arquivos CSS compilados referenciam ativos estáticos explicitamente usando o esquema http. Mas, na minha opinião, isso não deveria ser necessário a longo prazo.

8

Necessário, pois é o propósito do FORCE_HTTPS - é assim que você informa ao Discourse que ele está sendo servido com segurança e para reescrever os links como tal.

9

Quais fatores/condições impactariam o protocolo HTTP/HTTPS dos URLs dos ativos (JS/CSS)?

  1. Se você comentar abaixo e seu site for acessado via HTTP, os URLs dos ativos também serão HTTP
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

Neste caso, se você habilitar force_https, você acabará com um erro em todos os URLs de ativos R_SSL_PROTOCOL_ERROR se o domínio solicitado não tiver um certificado instalado. Para evitar isso, instale um certificado para resolver o problema do protocolo SSL.

  1. Se você instalar o Discourse com o template acima descomentado, o URL dos ativos do site deve ser HTTPS, juntamente com o protocolo do URL base do seu site. Além disso, o force https ficará invisível na interface do administrador.
10

Conforme mencionado na postagem original, no meu caso o certificado e tudo está correto e válido, mas todas as conexões com o exterior são tratadas por um proxy reverso (nginx, obviamente ;-)), enquanto a conexão com o discourse passa por um socket Unix. Isso significa que tenho
templates/web.socketed.template.yml
em vez de qualquer um dos que você menciona. Ainda assim - isso não deveria fazer com que os URLs estáticos tivessem um esquema http: explícito codificado.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.