Richieste di font non sicure

Supporto
1 
Contenuto misto: La pagina a '\u003cURL\u003e' è stata caricata tramite HTTPS, ma ha richiesto un font non sicuro '\u003cURL\u003e'. Questa richiesta è stata bloccata; il contenuto deve essere servito tramite HTTPS

E 40 richieste per font dal gem discourse-fonts. Questa è una nuova installazione in cui Postgres e Redis sono in esecuzione su un server separato all’interno della rete locale e la connessione è “socketed” ma servita all’esterno tramite https, ovviamente. Ci sono thread simili ma nessuna risposta chiara per me. Il controllo del CSS punta a wizard.scss (source-mapped). Qualche indizio?

2

Hai abilitato l’impostazione force https?

1 Mi Piace
3

Molto probabilmente no. Dove lo imposto? E perché dovrebbe essere necessario in primo luogo invece di far richiedere al CSS risorse statiche tramite https o riferimenti relativi?

FWIW - sul webserver rivolto all’esterno ho la tipica impostazione 301

Modifica:

Ho trovato l’impostazione basata su questo post, grazie @Arkshine

1 Mi Piace
4

Non sono sicuro del motivo per cui hai un link http da qualche parte; https dovrebbe essere applicato indipendentemente.

Puoi trovare nella barra di ricerca:

image
image861×193 6.81 KB

2 Mi Piace
5

Beh, nemmeno io. Non ho modificato nulla. Solo il normale launcher build app. Questi URL sembrano essere nel CSS elaborato, che ovviamente non ho toccato (né gli scss) in alcun modo. Non ho trovato nulla di https correlato nemmeno in app.yml, quindi… non lo so. Il force_https sembra risolvere il problema.

1 Mi Piace
6

FORCE_HTTPS indica a Discourse di riscrivere le richieste.

È necessario anche se si sta eseguendo l’incapsulamento SSL all’esterno del container per evitare il problema che stai descrivendo.

1 Mi Piace
7

Dipende da come definiamo “necessario”. Attualmente potrebbe essere necessario aggirare il problema effettivo, ovvero che i file CSS compilati fanno riferimento a risorse statiche esplicitamente utilizzando lo schema http. Ma secondo me questo non dovrebbe essere necessario a lungo termine.

8

Necessario nel senso che è lo scopo di FORCE_HTTPS: è così che si dice a Discourse che viene servito in modo sicuro e che i link devono essere riscritti di conseguenza.

9

Quali fattori/condizioni influirebbero sul protocollo HTTP/HTTPS degli URL degli asset (JS/CSS)?

  1. Se si commenta quanto segue e si accede al sito tramite HTTP, anche gli URL degli asset saranno HTTP
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

In questo caso, se si abilita force_https, si finirà con tutti gli URL degli asset che generano un errore R_SSL_PROTOCOL_ERROR se il dominio richiesto non ha un certificato installato. Per evitarlo, si installa un certificato per risolvere il problema del protocollo SSL.

  1. Se invece si installa Discourse con il template sopra non commentato, l’URL degli asset del sito dovrebbe essere HTTPS insieme al protocollo dell’URL di base del sito. Inoltre, force https è invisibile nell’interfaccia utente di amministrazione.
10

Come menzionato nel post originale, nel mio caso il certificato e tutto il resto è corretto e valido, ma tutte le connessioni verso l’esterno sono gestite da un reverse-proxy (nginx, ovviamente ;-)), mentre la connessione a discourse avviene tramite socket Unix. Ciò significa che ho
templates/web.socketed.template.yml
piuttosto che uno qualsiasi di quelli che menzioni. Tuttavia, questo non dovrebbe causare URL statici con uno schema http: esplicito codificato in modo fisso.

11

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