Unsichere Schriftartanforderungen

Unterstützung
1 
Gemischter Inhalt: Die Seite unter '\u003cURL\u003e' wurde über HTTPS geladen, hat aber eine unsichere Schriftart '\u003cURL\u003e' angefordert. Diese Anfrage wurde blockiert; der Inhalt muss über HTTPS bereitgestellt werden

Und 40 Anfragen für Schriftarten aus dem discourse-fonts-Gem. Dies ist eine frische Installation, bei der Postgres und Redis auf einem separaten Server im lokalen Netzwerk laufen und die Verbindung “gesockelt” ist, aber natürlich über HTTPS nach außen bereitgestellt wird. Es gibt ähnliche Threads, aber keine klare Antwort für mich. Die Überprüfung von CSS verweist auf wizard.scss (source-mapped). Irgendwelche Hinweise?

2

Haben Sie die Einstellung force https aktiviert?

1 „Gefällt mir“
3

Höchstwahrscheinlich nein. Wo stelle ich das ein? Und warum sollte es überhaupt benötigt werden, anstatt dass die CSS-Anfrage statische Assets über https oder relative Referenzen stellt?

FWIW - auf dem nach außen gerichteten Webserver habe ich die üblichen 301 gesetzt.

Bearbeiten:

Die Einstellung wurde basierend auf diesem Beitrag gefunden, danke @Arkshine.

1 „Gefällt mir“
4

Ich bin mir nicht sicher, warum Sie irgendwo einen HTTP-Link haben; HTTPS sollte trotzdem erzwungen werden.

Sie finden dies in der Suchleiste:

image
image861×193 6.81 KB

2 „Gefällt mir“
5

Nun, ich auch nicht. Ich habe nichts geändert. Nur der normale launcher build app. Diese URLs scheinen im verarbeiteten CSS zu sein, das ich offensichtlich in keiner Weise (auch nicht das scss) berührt habe. Ich habe auch nichts HTTPS-bezogenes in der app.yml gefunden, also… keine Ahnung. Die force_https scheinen das Problem zu umgehen.

1 „Gefällt mir“
6

FORCE_HTTPS weist Discourse an, Anfragen umzuschreiben.

Es ist auch dann notwendig, wenn Sie SSL-Kapselung außerhalb des Containers durchführen, um das von Ihnen beschriebene Problem zu vermeiden.

1 „Gefällt mir“
7

Es hängt davon ab, wie wir „notwendig“ definieren. Derzeit mag es notwendig sein, das eigentliche Problem zu umgehen, nämlich dass kompilierte CSS-Dateien statische Assets explizit mit dem http-Schema referenzieren. Aber meiner Meinung nach sollte dies auf lange Sicht nicht notwendig sein.

8

Notwendig, da es der Zweck von FORCE_HTTPS ist – so teilen Sie Discourse mit, dass es sicher bereitgestellt wird und Links entsprechend umschreibt.

9

Welche Faktoren/Bedingungen würden sich auf das URL-Protokoll HTTP/HTTPS der Assets (JS/CSS) auswirken?

  1. Wenn Sie dies auskommentieren, und Ihre Website über HTTP aufgerufen wird, dann werden die Asset-URLs ebenfalls HTTP sein
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

In diesem Fall, wenn Sie force_https aktivieren, erhalten Sie bei allen Asset-URLs den Fehler R_SSL_PROTOCOL_ERROR, wenn die angeforderte Domain kein Zertifikat installiert hat. Um dies zu vermeiden, installieren Sie ein Zertifikat für diese Domain, um das SSL-Protokollproblem zu lösen.

  1. Wenn Sie stattdessen Discourse mit der obigen, auskommentierten Vorlage installieren, sollten die Asset-URLs der Website zusammen mit dem Protokoll der Basis-URL Ihrer Website HTTPS sein. Darüber hinaus ist force https in der Admin-Oberfläche unsichtbar.
10

Wie im ursprünglichen Beitrag erwähnt, sind in meinem Fall Zertifikat und alles korrekt und gültig, aber alle Verbindungen nach außen werden von einem Reverse-Proxy (offensichtlich Nginx :wink: ) gehandhabt, während die Verbindung zu Discourse über einen Unix-Socket erfolgt. Das bedeutet, ich habe
templates/web.socketed.template.yml
anstelle von einer der von Ihnen genannten. Dennoch sollte dies nicht dazu führen, dass statische URLs hartkodierte explizite http: Schemas haben.

11

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