Weblink in Konferenzeinladung nur http, nicht https

  • Mir gelingt es nicht, in den Einladungstext für geplanten Konferenzen den Weblink (Variable %WEB_LINK%) mit https zu generieren.
    Die E-Mail, die genieriert wird sieht etwa so aus:


    Sehr geehrte /-r Frau / Herr Schneider,


    hiermit möchten wir Sie zur Telefonkonferenz 'test2' am Dienstag, 3. Juni 2014 um 22:40 Uhr MESZ einladen.
    Um an der Konferenz teilzunehmen, rufen Sie bitte die Nummer +49 (0)761 123456 an und geben Sie nach der Aufforderung folgenden PIN-Code ein: 397647


    Wenn Sie die Konferenz am Bildschirm verfolgen möchten, öffnen Sie bitte nachstehenden Link


    http://<woltlab-metacode-marker data-name="i" data-uuid="5d4f91fb-0993-4fc5-8224-009c19cf8976" data-source="W0ld" />tk.meindnsname.de<woltlab-metacode-marker data-uuid="5d4f91fb-0993-4fc5-8224-009c19cf8976" data-source="Wy9pXQ==" />:80/jsp/granted/extern/conference/display.do?pin=397647


    Mit freundlichen Grüßen


    Das kann doch nicht sein, dass man für Telefonkonferenzen zwingend den normalen http Port aufmachen muss?


    (Version 5.7.0.7)


    Grüße

  • Hi,


    wenn du unter "Server" -> "Webserver" -> "Umleitung auf HTTPS erzwingen" angehakt hast, dann wirst du immer automatisch auf den https-link umgeleitet.
    Einen anderen Weg hatte ich bis jetzt auch nicht gefunden, im Template direkt https anzugeben.
    Vielleicht kann man im Starface System neue/eigene Variablen (ein Modul oder in der DB?) generieren die unter Konferenz genutzt werden können?
    "%WEB_LINK_HTTPS%" - wäre ja mal eine neue Anforderung, wenn es nicht schon etwas gibt.


    Grüße
    Alex

  • Ja, das habe ich mir auch schon überlegt, vermute aber, dass es einige unschöne Nebeneffekte hat:
    Die Umleitung auf https gilt ja dann auch für intern. Dann bekomme ich Zertifikatsfehler, nicht nur bei den Konferenzen, sondern beim allgemeinen Zugriff auf die WebGUI, weil der DNS Name intern und extern nicht übereinstimmen, bzw. ich müsste entweder den internen DNS eine interne IP rausgeben lassen, d.h. je nach dem welcher DNS gefragt wird, würden die Namen zu unterschiedlichen IPs aufgelöst oder ich schicke auch den internen Zugriff durch den NAT Router...
    Alles nicht so das wahre.


    Dabei wäre es ganz einfach, wenn das Feld in dem man die Webserveradresse angibt, nicht das Protokoll rauswerfen würde. Sprich, wenn ich als Webserveradresse https://host.domain.de angebe, dann wird das auch so verwendet, wenn ich kein Protokoll angebe, dann verwendet er wie bisher http:\\...


    Für die Konferenzen finde ich den http Zugriff auch noch in Ordnung, wenn damit nicht auch der unverschlüsselte Zugriff auf die WebGUI einhergehen würde.

  • Wir haben keinen externen Zugriff für die Starface - aber für andere Dienste.
    Eigentlich sollte der externe Zugriff der Starface über einen Reverse Proxy ins Internet verfügbar gemacht werden, dort kannst du mit öffentlichen Zertifikaten arbeiten.
    Intern nutzen wir Zertifikate aus unserer MS CA, diese sind in der Starface importiert. Rechner aus dem AD verfügen über die Root-Zertifikate.


    Intern im DNS kannst du die externe Domain anlegen (Vorsicht: Dann musst du für alle Host der externen Domain diese auch dort anlegen) und den Record der Starface mit der internen IP anlegen.


    Alternativ geht der externe und interne Zugriff über den Reverse Proxy.

  • *Thema ausgrab*


    Ich tüftele auch gerade etwas mit den geplanten Konferenzen und stolpere über den WebLink. Zwar ist es (zwischenzeitlich?) möglich über das vorangestellte Protokoll https:// die Webadresse gleich passend auszuliefern. Allerdings unterstellt die SF immer die Default-Ports 80 und 443. Ich hätte aber Bedarf einen alternativen Port zu benennen. Mache ich das - ähnlich wie das Protokoll - explizit dann endet das in der URL

    Code
    https://[full.qualified.domain:altport]:443/restlicher/link/

    also in der Tat mit den eckigen Klammern :-o.


    Idee dazu? Feature request?

  • Hallo stk


    Bin zur zeit auch am selben Problem.
    Da es ja generell nicht empfohlen wird die Standart Ports offen zu lassen verwenden wir auch für uns ein spezifisches im https.


    Ein wink an die Technik. Wenn mann ja unter der Web Oberfläche ja sogar die HTTPS auf ein anderes Port verschieben kann und HTTPS erzwingen kann begreift ich ehrlich nicht ganz wieso dies noch nicht integriert wurde. Zudem nach der Attacke wird ja von HTTP und div. anderen Standartports abgeraten.


    Bist du da schon weiter gekommen?


    Gruss aus der Schweiz

Jetzt mitmachen!

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