[2.0.9pl1] Auslöser einer Benachrichtigung bestimmt Protokoll für Empfänger

  • Betroffene App
    WoltLab Suite Core

    Wenn ich im Protokoll HTTPS bin und auf ein Thema antworte, so erhalten die User, die dieses Thema abonniert haben und eine Mail dazu bekommen, Links zur HTTPS-Version meiner Seite. Bin ich selbst nur mit HTTP unterwegs, bekommen die User HTTP-Links.

    D. h. der Auslöser einer Benachrichtigung bestimmt das Protokoll für den Empfänger. Das soll sicher nicht so sein.

    Aufgefallen ist dies durch das Plugin UZ Erweitertes Like , weil die Like-Benachrichtigung meine User immer von SSL auf Nicht-SSL weitergeleitet hat (aber nicht immer) und damit häufig zum Ausloggen geführt hat.

    Der Fehler ist aber offenbar im Benachrichtigungssystem des WCF zu suchen.

    • Offizieller Beitrag

    Der Link wird immer anhand des Protokolls des aktiven Benutzers generiert. Das WCF speichert nicht permanent welches Protokoll ein Benutzer für den Aufruf der Seite benutzt. Die Generierung eines passenden Links beim Versenden von Benachrichtigungen ist dementsprechend nicht möglich.

    Allgemein empfehlen wir, das Protokoll über den Webserver auf einen festen Wert einzustellen, um die diversen Probleme, die sich beim Mix der Protokolle ergeben, zu vermeiden.

  • Was spricht dagegen, Links ohne Protokoll zu verwenden?

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

  • Links ohne Protokoll funktionieren in einer E-Mail vermutlich nicht.
    Aber wer die gleiche Seite sowohl unter HTTP als auch unter HTTPS aufrufbar macht, macht ja eh schon was verkehrt. Das Problem lässt sich vermeiden.

  • Was spricht dagegen, Links ohne Protokoll zu verwenden?

    Frage ich mich auch. Für Mails könnte man ja eine Ausnahme machen (wenn es da nicht anders geht). Wenn ich im Forum ein Posting mit einem internen Link mache, so bekommt der aufrufende User auch nicht mein Protokoll, sondern seins. Müsste in meinen Augen bei Benachrichtigungen ebenfalls so sein.

    Aber wer die gleiche Seite sowohl unter HTTP als auch unter HTTPS aufrufbar macht, macht ja eh schon was verkehrt.

    Es gibt leider noch genügend Proxys und einige Geräte, die kein HTTPS können. Da ich niemanden aussperren möchte, muss ich beides anbieten (oder HTTPS deaktivieren, was meine User auch nicht schön fänden).

    Im Moment sehe ich eine Mischlösung als nötig an. In einem Jahr sieht die Lage sicher schon ganz anders aus.

  • Meine Userschaft ist halt nicht hipp genug. ;)

    Ich kann dir aus dem Stegreif keine Beispiele nennen, aber das mit den Proxys ist nicht von der Hand zu weisen (da kann ich auch gerne mit Beispielen dienen).

  • Wie sieht's mit Suchmaschinenbots aus, können die heute alle HTTPS?

    Aufgrund der Probleme mit dem WBB 4 und einem HTTP/HTTPS-Mischbetrieb muss ich vmtl. wirklich HTTPS erzwingen.

    • Offizieller Beitrag

    Suchmaschinen haben kein Problem damit. Google überlegt sich sogar (oder tun sie es bereits?), Webseiten mit TLS höher zu ranken.

    Google wertet Seiten mit SSL/TLS bereits seit August 2014 höher, wenn gleich es nur einen geringen Einfluss hatte. Ob dies inzwischen auf einen Normalwert angehoben wurde ist nicht wirklich bekannt, aber das ist bei Google ja normal.

    @King555 Ausnahmslos alle relevanten Suchmaschinen können SSL/TLS.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!