sourceserver.info

Sourceserver.info bietet jetzt auch die Transportverschlüsselung an.

Die Umleitung ist aktiv.

Leider haben wird dadurch Mixed-Content, der nicht im Browser angezeigt wird.
Falls jemand eine einfache Lösung kennt, nur her damit.

Eine Lösung wären Protokollrelative URLs, was aber nur funktioniert, wenn der externe Inhalt auch via SSL abrufbar ist.

Bis die Probleme behoben sind, lasse ich die Umleitung inaktiv.

Wer die Seite jetzt schon verschlüsselt laden möchte, kann das gerne tun: https://sourceserver.info

Danke für den Hinweis.

CF setze ich woanders noch ein. Bin mir aber nicht sicher ob externe Inhalte dann via SSL auch wirklich erreichbar sind.
Wenn z.B. ein absoluter Link auf http://domain.tld/bild.png verweist, kann der Links soweit ich weiß durch CF umgeschrieben werden.
Das klappt dann aber auch nur, sofern die externen Inhalte auch via SSL ausgeliefert werden können.

Das gleiche Problem mit Protokollrelativen Verlinkungen: //domain.tld/bild.png
Auch bei dieser Lösung muss das Ziel die Inhalte via SSL ausliefern können.

Eine Mögliche Lösung: Ein Plugin das die externen Inhalte des Forums über einen https Relay-Server leitet, der die Inhalte stupide via http aufruft und den Content dann ausliefert.


CF kann das, soweit ich weiß, nicht. Hatte da schon einiges ausprobiert. Des weiteren hab ich keine Befürchtung, dass wir angegriffen werden. Deswegen möchte ich den Nutzern nicht unbedingt zumuten über einen US-Amerikanischen Server umzuleiten. Durch Beobachtung weiß ich, dass einige Besucher sourceserver.info über einen Proxy besucht haben. Der Grund wird wahrscheinlich der Einsatz von Google-Analytics gewesen sein. Aus dem Grund hab ich google von unserer Seite wieder entfernt.

Im Falle vermehrter Angriffe, sieht die Situation etwas anders aus. Dann muss man halt aktiv werden und auf den Datenschutz seiner Besucher verzichten.

Das ist einfach zu erklären.

Die Links innerhalb des Forums sind alle relativ. Die Basisurl wird dann mit den relativen Links erweitert. Die Basisurl habe ich bereits auf https umgestellt,
was dazu führt, dass die HTML-Seite via http ausgeliefert wird und der Rest via https (ziemliches durcheinander).

Ruft man die Seite via https auf, wird auch das HTML-Dokument natürlich via HTTPS ausgeliefert.


Die externen Links sind absolute Links. Dessen Protokoll http oder https ist festgelegt. So stehen sie in der Datenbank.
Diese externen Links werden nicht durch das Forum verändert.

Wenn nun das Dokument via https ausgeliefert wird, achtet jeder gute Browser darauf, dass nur Inhalte via https geladen werden.
Alle anderen Inhalte werden nicht geladen, es seiden man stellt es in seinem Browser explizit ein.

Angenommen den Fall, man würde einfach mit einem SQL-Query nach http:// in den Tabellen suchen, sourcerserver.info ausschließen
und http durch https ersetzen, hätte man immer noch das Problem, dass man nicht weiß, ob der Webserver, auf dem der externe Inhalt liegt,
auch ein gültiges Zertifikat hat und ob SSL überhaupt aktiviert ist.

Die mir einzig bekannte Lösungen wären ein Relay-Server, der externe Inhalte via http laden kann und
diese via https ausliefert oder man entfernt strikt alle externen Inhalte von der Seite. Ich glaube das Serversupportforum hat seit
Anfang an die Richtlinie, dass externe Inhalte nicht zulässig sind. Man muss ja auch immer davon ausgehen, dass ein Server mal nicht erreichbar ist,
was zu einem Timeout führt und die Ladezeit erhöhen kann.

Hier mal ein Beispiel
http://keks-brigarde.net/gameserver/smacbans/stats.php
https://keks-brigarde.net/gameserver/smacbans/stats.php <<< SEC_ERROR_UNKNOWN_ISSUER
https://ssl-redirect.vv.ist-im-web.de/ke…cbans/stats.php <<< Mein Relay-Server, LE-Zertifikat, HTTP/2 (Link entferne ich später wieder)

Der erste Link wird genutzt. Lädt man die Seite nun via HTTPS, wird das Bild nicht angezeigt. Ganz normal.
Der zweite Link würde auch nicht geladen werden, da das Zertifikat einen unbekannten CA hat (selbst signiert).
Der dritte Link würde funktionieren. So ein Dienst wird sogar kostenlos von einem Anbieter angeboten. Ich hab leider den Namen vergessen.

Die Header der Stile waren absolut verlinkt und wurden deswegen auch nicht angezeigt. Setze ich sie protokollrelative Links für die Banner der Stile, schreibt das Forum die Links falsch um. Setze ich relative Links, für die Banner, wird das Verzeichnis wcf verwendet, aber die Banner sind im Wurzelverzeichnis. Jetzt habe ich absoluten Links einfach in https geändert. Das ist aber auch nicht so toll.

Zumindest ist das Schloss jetzt in der Forumsansicht grün und nicht durchgestrichen.
Um den Rest kümmere ich mich später.

Ab sofort wird Content-Security-Policy verwendet, um http zu https Verbindungen upzugraden.
Externe Inhalte wie z.B. Grafiken werden dann via https geladen, sofern der Webserver das unterstützt und das Zertifikat gültig ist.
Wenn die externen Inhalte nicht via https ausgeliefert werden können, werden diese nicht geladen.

Sollten Bilder in Beiträgen verwendet werden, ladet diese bitte als Anhang in das Forum hoch. Der Anhang kann dann
einfach in den Beitrag eingefügt werden.

Für alle, die das gleiche Problem mit Mixed-Content in ihrem (WBB3)-Forum haben, sollten sich folgenden Artikel durchlesen:
https://developer.mozilla.org/en-US/docs…secure-requests

Da ich keine direkte Kontrolle über den Webserver habe, musste ich auf den Meta-Tag auswichen:



Um der Installation irgendwelcher Plugins aus dem Weg zu gehen, habe ich das Template 'templates/headInclude.tpl' direkt bearbeitet.
Dies betrifft dann alle Seiten, bis auf das Admininterface.