Die ist bewusst, dass es ohne https keine Security geben kann, die durch diese Seiten getestet wird, oder?
Das kleine s steht für secure.
merrx.bestpony.de unterstützt keine Verschlüsselung. Das gibt dann mixed content Warnungen bzw die Smilie Anzeige die Smilie Bar geht kaputt. Das sollte also vorher umgestellt werden.
Laut
https://blog.qualys.com/ssllabs/... erlauben die meisten Webbrowser passiven mixed-content - also das hinzuladen von Bildern von nicht-TLS Adressen.
Das heißt, dass solange kein HSTS oder CSP für verschlüsseltes bronies.de auf dem Webserver oder in Cloudflare aktiviert wird, das Nachladen von Bildern von nicht-https-Quellen keine nervigen Warnmeldungen verursachen sollte. Für eine Übergangszeit bis die Leute ihre Signaturen und Scripte eventuell angepasst haben müsste das gut genug sein.
Das lässt sich unter
https://mixed-content-test.appspot.com/ mit klick auf "HTTP Image" einfach testen.
(13.09.2016)rainbowderpy schrieb: [ -> ]Für eine Übergangszeit bis die Leute ihre Signaturen und Scripte eventuell angepasst haben müsste das gut genug sein.
Welche Übergangszeit? Auch in einigen Jahren werden garantiert nicht alle Signaturen und Avatare auf verschlüsselten Seiten gehostet sein. Da reden wir wenn dann aber von einer sehr langen Übergangszeit.
Die Warnungen wird's nach der Umstellungimmer geben, aber das ist ja kein Problem, solange Inhalte dargestellt werden.
Das mit der Sidebar haben wir schon im Auge, dass es da nen Ausweg geben wird. Leider braucht die Sidebar in ihrer derzeitigen Form auch aktive Inhalte von http Verbindungen, daher würde sie tatsächlich nicht mehr gehen. Aber wie gesagt, ist von uns eine entsprechende Lösung mit Merrx zusammen in Arbeit.
Hält sich eigentlich Greasemonkey bei Userscripts überhaupt an die Mixed-Content-Regeln vom Browser?
(13.09.2016)Leon schrieb: [ -> ]Hält sich eigentlich Greasemonkey bei Userscripts überhaupt an die Mixed-Content-Regeln vom Browser?
Greasemonkey selbst nicht, nein. Also wenn das Userskript außerhalb des eigentlichen Scopes der Seite arbeitet (was es grundsätzlich tut) und dabei direkt Inhalte von http Verbindungen bezieht, ist das erstmal kein Problem.
Aber sobald Javascripts in den body der Seite als remote include eingebunden werden (zusätzliche <script>-Tags), Javascript Code als Eventlistener an Elemente im DOM-Baum gehängt wird, oder ein in den body direkt eingefügtes Inline-Javascript z.B. einen XHR absetzen will, zählen für diesen Aufruf die Regeln der Seite. Letzteres ist wie die Sidebar arbeitet, also es wird ein bisschen Javascript in die Seite eingebunden, damit dann später aufgrund von User-Interaktion XHR Requests (konkret Abfrage der aktuellen Smilie-Listen einer bestimmten Kategorie/Typs) noch abgefeuert werden können.
Ich denke es ist sogar so, dass jegliche durch Nutzeraktionen in der Seite ausgelösten Events automatisch jeglichen Code der dadurch direkt oder indirekt ausgeführt wird in dem entsprechenden Sicherheitsrahmen der Seite zwingt.
Daher kann man wohl auch nicht (einfach) um die Einschränkung herum tricksen, ohne die komplette Funktionsweise des Skripts neu zu überdenken und z.b. immer beim Aufruf einer Seite sofort alles von Remote zu laden und erst anschließend in die Seite einzufügen. Die Funktionsweise als "Bookmarklet" könnte man mit solchen Tricks aber überhaupt nicht mehr hinbekommen.
(14.09.2016)Evenprime schrieb: [ -> ]z.b. immer beim Aufruf einer Seite sofort alles von Remote zu laden und erst anschließend in die Seite einzufügen.
Darauf wollte ich hinaus. Zur Zeit lädt das Skript die Link-Listen für die jeweiligen Smileys erst, wenn man die jeweiligen Kategorien auswählt. Das ließe sich bestimmt auch über das Userscript direkt machen, jedoch müsste sich dann das Skript wahrscheinlich auch selbst um die Verwaltung der Kategorien und Größen kümmern, was derzeit alles serverseitig über PHP passiert.
Die Seite wird nun ca. eine Woche lang optional über https oder http erreichbar sein. Sollten sich keine groben Probleme mehr abzeichnen, wird exklusiv auf https umgestellt.
Einige Limitierungen die inzwischen bekannt sind:
liveleak.com
veoh.com
metacafe.com
können nicht mehr direkt als Video eingebunden werden, da diese Seiten keine https-Variante ihrer Videos anbieten.
Zudem können sich einige sehr alte Browser und/oder Betriebssysteme aus technischen Limitierungen nicht per https mit der Seite verbinden, d.h. diese werden ab nächster Woche ausgesperrt sein. Wer wissen will, ob z.b. sein Smartphone davon betroffen ist, kann schon jetzt probieren die Seite per https aufzurufen. Wenns klappt, wird es auch in einer Woche kein Problem geben.
Merrx Smilie Sidebar funktioniert in der alten Version von 2014 in https nicht. Es gibt eine aktuelle und kompatible Version unter
https://smilies.bronies.de zu finden, die ebenfalls von Merrx betreut wird.
EDIT: Diverse Firmennetzwerke, die verschlüsselte Verbindungen zu Webseiten aufbrechen oder gar unterbinden, können euer Forenerlebnis beeinträchtigen. Dies ist mit dem jeweiligen Arbeitgeber zu klären.
Da du ja offensichtlich mit merrx Kontakt hast, sonst gäbe es keine Kooperation und er würde nicht weiterhin die Smiley-Sidebar betreuen, kannst du ihm dann bitte Bescheid geben, dass mal die Smileys auf den aktuellen Stand gebracht werden sollen (no Sunset Shimmer/Starlight Glimmer/The Dazzlings/Whatever)?
Hier hat er sich ja nie gemeldet bzgl. Aktualisierungen, obwohl von Usern gewünscht.
Aktuell leitet übrigens
https://bronies.de noch auf
http://www.bronies.de weiter, was nicht so optimal ist.
(Sofern irgendwann automatisch auf https umgeleitet wird, wäre das aber eh nicht mehr relevant.)
das Google Pakeranking sieht vermeidbare Weiterleitungen gar nicht gerne. Allgemein wäre es auch gut, vor dem aktivieren der
http://www.bronies.de auf TLS Weiterleitung in den Google Webmaster-Tools, die preferred Domain in den Suchergebnissen anzupassen und dem Crawler ein paar Tage Zeit zu geben.
Also, mein S5 mini hat - ohne das ich irgendwas einstellen musste - bereits selbstständig auf Https:// umgestellt.
Man kann es sehen, ohne einen Test zu machen - wenn ein Geschlossenes Schloß im Browser vor der Adresse is, dann läuft die verbindung über Https.
(03.10.2016)rainbowderpy schrieb: [ -> ]das Google Pakeranking sieht vermeidbare Weiterleitungen gar nicht gerne. Allgemein wäre es auch gut, vor dem aktivieren der http://www.bronies.de auf TLS Weiterleitung in den Google Webmaster-Tools, die preferred Domain in den Suchergebnissen anzupassen und dem Crawler ein paar Tage Zeit zu geben.
Die Weiterleitung auf https:// wird als 301-Weiterleitung erfolgen. So wie Google es gerne
hätte . Und ab gesehen davon, ist das auch nur ein Ranking-Faktor von vielen. Ich denke nicht, dass wir selbst ohne 301-Weiterleitung da so viel verlieren. Die Weiterleitung von bronies.de auf
http://www.bronies.de ist zum Beispiel eine 302 Weiterleitung und wir sind trotzdem ganz weit oben im Ranking
.
(03.10.2016)Crash Override schrieb: [ -> ]Also, mein S5 mini hat - ohne das ich irgendwas einstellen musste - bereits selbstständig auf Https:// umgestellt.
Man kann es sehen, ohne einen Test zu machen - wenn ein Geschlossenes Schloß im Browser vor der Adresse is, dann läuft die verbindung über Https.
Das liegt wahrscheinlich daran, weil alle internen Forenlinks bereits auf https umgestellt sind. Wenn du per Hand bronies.de aufrufst landest du noch auf der http-Version, sobald du im Forum aber irgendeinen Link anklickt bist du auf https
.
(03.10.2016)rdmlp schrieb: [ -> ]Die Weiterleitung von bronies.de auf http://www.bronies.de ist zum Beispiel eine 302 Weiterleitung und wir sind trotzdem ganz weit oben im Ranking .
Was wahrscheinlich daran liegt, daß www.<domain> als
übliche Subdomain für nen Webserver sowieso bevorzugt wird.
Andererseits, wer kehrt hier überhaupt über den pagerank?
Der Google Pagerank ist nicht unwichtig. Er ist nicht einfach eine Bewertung der Seite, damit Nutzer sich informieren können oder so, sondern er bestimmt, wie weit oben eine Seite in den Google-Suchergebnissen erscheint. Je höher der Pagerank von bronies.de, desto öfter erscheint bronies.de in den Suchergebnissen und desto mehr neue Benutzer stoßen auf die Seite und registrieren sich eventuell.
Na ja. Das macht zwar Sinn bei konkurrierenden Seiten, jedoch gibt es diese bei Bronies.de praktisch nicht, bzw. die Relevanz ist wesentlich höher als die möglichen Negativpunkte wegen der Weiterleitung.
Außerdem geht es bei den Weiterleitunge weniger um das Ranking, sondern eher darum, ob nun die ursprüngliche oder die weitergeleitete URL indiziert wird. Da beim Forum die weitergeleitete Seite identisch ist, würde ich das eher als Kosmetik einstufen. Weiterhin erkennt Google genauso auch 302- oder JavaScript-Weiterleitungen, selbst wenn 301 empfohlen wird.
Ist das Googleranking nicht völlig egal?
Wer sich für Bronies interessiert googlet bronies und findet euch.
Oder gibts da noch Konkurenz? Nicht, dass ich wüsste.