Design-Assistent-Seiten auf https umstellen

[#1]

Hallo Telekom-Team,

ich weiß, es gibt bereits etliche Anfragen zum Thema https. Dennoch wüsste ich gerne, wie es weitergehen soll, vor allem, weil ich nichts konkret zum Thema Design-Assistent gefunden habe. Am 25.Mai tritt die DSGVO in Kraft, und die Abmahner stehen sicher schon in den Startlöchern. Ich betreibe drei homepages (1xStarter, 1xBasic und 1xAdvanved), die ich alle über den Design-Assistenten bearbeite, unter anderem deshalb, weil sie schon so lange existieren und vor allem deshalb, weil man eine Seite mit 1GB Daten nur mit unvertretbarem Aufwand z.B. auf Creator umstellen kann (wenn überhaupt). Was ebenfalls unterschätzt wird, ist die Tatsache, dass das Design der homepage oft ein Teil der "corporate identity" ist. Eine Umstellung bekannter Seiten auf neues Design ist dabei sehr nachteilig.

Frage 1: (wie) kann ich meine Seiten auf https umstellen?

Frage 2: sind verlinkte html-Unterseiten und spezielle Inhalte wie z.B. Java-Scripte (Bildergalerien etc.) damit auch erfasst bzw. können sie belassen werden?

Ich bin - sonst hätte ich keinen homepage-Baukasten benutzt - absoluter Amateur. Und wie ich annehme einer von vielen hunderttausenden, die sich seinerzeit auf die Telekom-Angebote verlassen haben. Angesichts bereits anderweitig erwähnter Nachteile und Konsequenzen vor allem vor dem Hintergrund inzwischen absurder Datenschutzvorschriften für Privatleute, Freiberufler und Kleinunternehmer sehe ich die Telekom hier zeitnah zum Anbieten brauchbarer Lösungen (und damit meine ich nicht das Neuerstellen ganzer Seiten) verpflichtet. Wie bereits des öfteren erwähnt: andere (kleinere) können es auch.

[#2 · Accepted solution]

Hallo @harald57,

letztendlich müssen wir mit diesem "Zustand" leben. Der Designassistent wird bereits seit mehreren Jahren nicht mehr weiterentwickelt und stammt aus einer Zeit, in der die Nutzung von Zertifikaten für die eigene Domain noch nicht verbreitet war. Entsprechend wurde bei der Entwicklung dieser Anwendungsfall nicht berücksichtigt.

An diesem Zustand wird sich auch nichts mehr ändern. Was kann man in diesem Fall tun? Hier findest du eine Hilfe dazu: https://homepagecenter.telekom.de/index.php?id=790

Mein ganz persönlicher Tipp: Es wäre wirklich der Zeitpunkt gekommen, sich Gedanken zu machen, ob du neben der bestehenden Homepage eine neue über ein Offline-Programm erstellst oder eine Umstellung auf den Homepage Creator vornimmst.

Viele Grüße Nadine H.

[#3]

@harald57

Hallo Harald,

ich habe deine Anfrage mal an die zuständigen Kollegen per Ticket weitergeleitet. Sobald ich eine Antwort erhalte oder noch Rückfragen habe, melde ich mich wieder bei dir.

Die anderen Fragen beantworte ich dir gleich per DM.

Viele Grüße Nadine H.

[#4]

@harald57

Moin Harald,

ich habe eine Antwort zu meinem Ticket erhalten. Du hast wohl vier Widgets eingerichtet, die jeweils Inhalte von extern ohne https nachladen. Der Kollege geht davon aus, dass die das Problem verursachen. Es wird empfohlen, die Widgets im Designassistent zu suchen und zu ändern bzw. durch https Links ersetzen (wenn die Inhalte denn per https erreichbar sind).

Melde dich danach gerne noch mal hier.

Viele Grüße Nadine H.

[#5]

Hallo Nadine, komme leider wieder erst jetzt dazu, Dir zu antworten, habe Dir aber auch eine Antwort "privat" geschickt. Da habe ich mich auch zu den widgets geäußert, ich fürchte, das funktioniert so nicht, weil die widgets meiner Meinung nach vom DA auf einem http- Bereich abgelegt und von da auch wieder abgerufen werden. Deshalb lösen sie eine Fehlermeldung aus, auch wenn der eigentliche Inhalt ein https-script ist. Aber ich probier es nochmal aus mit einem widget, das definitiv aus https besteht (z.B. Wetter-Widget). Wär super, wenn Dein Kollege recht hat. 

Jetzt aber erst mal danke für das migrieren meiner zweiten Seite! Die dritte und letzte habe ich Dir jetzt auch angegeben. Dann sehen wir weiter.

Viele Grüße, Harald

[#6]

Hallo Nadine, kleiner Nachtrag: der Vorschlag Deiner Kollegen funktioniert nicht. Ich habe ein https-script als widget hinterlegt und per DA in die Seite eingebaut. Zum einen gibt der DA grundsätzlich die widgets in http aus, und auch wenn ich diesen Baustein in der Seite manuell auf https umstelle, bleibt die Fehlermeldung trotzdem. Vermutlich müsste man, wie ich bereits geschrieben hatte, den Serverbereich, auf dem die widgets hinterlegt werden, selbst erst mal auf https umstellen. Wenn die Kollegen es wünschen, kann ich die Seite mit dem Fehlerwidget gerne nochmal hochladen. Der Baustein in der Seite selbst (den ich natürlich wieder entfernt habe) ist der hier (für ein audio-script):

<SCRIPT>
/* please note: this script requires url.js */
if (typeof(__path_prefix__) == 'undefined')
__path_prefix__ = '.';
if (typeof(URL) == 'function') {
var appLoaderUrl = new URL('https://homepage.t-online.de/cgix/AppLoader.cls/ATOIX0INZO7A/7091/67824/align%3Aleft%3Blanguage%3Ade...');
if (appLoaderUrl.setSession())
appLoaderUrl.setParameter("foo", Math.random(), true);
document.write("<SCRIPT src='" + appLoaderUrl.toExternalForm() + "'></"+"SCRIPT>");
}
</SCRIPT>

Davon abgesehen wird immer noch vom DA ein zweiter solcher Baustein ohne erkennbare Funktion eingebaut (kein widget von mir). Welche Bedeutung der hat, weiß ich nicht. Würde mich wie gesagt freuen, wenn die Kollegen noch was ändern könnten.

Grüße, Harald

[#7]

@harald57

Hallo Harald,

ist ja kein Problem, abends ist von uns im Moment auch keiner hier. Ich habe deine Angaben noch mal im Ticket aufgenommen und den Kollegen weitergeleitet. Mal schauen was die dazu sagen.

Deine PN beantworte ich gleich, wenn ich die dritte Homepage umgestellt habe.

Viele Grüße Nadine H.

[#8]

Hallo Nadine, danke für das Umstellen der drei Seiten. Bin gespannt, ob die Kollegen noch was austüfteln. Ansonsten werde ich hier vielleicht gelegentlich noch die (meiner Meinung nach) einfachste Methode für das manuelle Einpflegen von externen Inhalten in DA-Seiten vorstellen. Muss ich aber leider selbst noch herausfinden....:-). Und vielleicht kommt ja auch noch eine zielführende Antwort in meinem anderen Thread zur externen Bearbeitung von DA-Seiten. 

Viele Grüße, Harald

[#9]

@harald57

Hallo Harald,

zu dem Ticket, welches @Nadine H. eingestellt hat, gibt es bereits eine Zwischenmeldung.
Bezüglich der unsicheren Elemente im DA existiert bereits ein Ticket beim Entwickler, damit auch diese Elemente auf HTTPS umgestellt werden. Ein konkreter Termin konnte aber nicht genannt werden, Du musst Dich also noch ein wenig gedulden.

Gruß,
Ingo F.

[#10]

Hallo Ingo, danke für die Nachricht. Bin gespannt, ob das tatsächlich noch geändert wird. Das würde möglicherweise bedeuten, dass man zumindest einen Teil der Extras beim DA doch weiterhin nutzen kann.

Momentan baue ich die Widgets nach der Veröffentlichung manuell in die Seiten ein und lösche die "schädlichen" Scriptteile raus. Wenn man sich da ein Schema erarbeitet, geht das ganz gut. Viele Seiten bleiben ohnehin meistens unverändert, die muss man nur einmal ändern, speichert sie lokal ab und lädt sie nach jedem Veröffentlichen einfach wieder per FTS hoch, so dass sie die "unsicheren" Seiten vom DA überschreiben. Dann muss man nur die in der jeweiligen Sitzung geänderten Seiten "nachbearbeiten". Nichtsdestotrotz wäre es natürlich komfortabler, wenn man sich diese Prozeduren sparen könnte.

Ich habe noch eine Frage: Soll / muss ich eigentlich DNSsec einstellen? Irgendwie verstehe ich nicht, ob das irgendeinen sinnvollen Effekt auf die Sicherheit hat bzw. warum - wenn ja - es nicht von Haus aus eingestellt ist oder wird?

Grüße, Harald

[#11]

@harald57

Hallo Harald,

ja, da steht die Rückmeldung noch aus, die Kollegen sind sich da anscheinen noch nicht ganz grün.

Zum Thema DNSSec haben wir in der Homepage Hilfe unter https://homepagecenter.telekom.de/index.php?id=681&no_cache=1&sword_list%5B%5D=DNSSec einen kurzen Artikel, der sehr einfach erklärt, wozu dies dient.

Gruß,
Ingo F.

[#12]

@harald57

Hallo Harald,

ich habe gerade noch einmal mit den Kollegen gesprochen und es wird hier nachträglich keine Anpassung des DA mehr geben. Wenn Du aber eh den Quelltext nach dem Veröffentlichen bearbeitest, kannst Du bei den unsicheren Elementen (per http eingebunden), einfach Mal versuchen, daraus ein HTTPS zu machen.
Mir wurde gesagt, das soll dann funktionieren.

Gruß,
Ingo F.

[#13]

Hallo Ingo,
danke nochmal für Deine/Eure Bemühungen. Nochmal kurz zu den widgets (nur die machen Probleme bei der Verschlüsselung): Ich gehe mal davon aus, dass alle Daten mit auf die neue Plattform migriert wurden. Das Problem kann also eigentlich nur in dem Scriptbaustein ("apploader...") liegen, der vom DA generiert wird. Da sind ein paar http: - Adressen drin, die ich aber - weil das script ja auf dem t-online server liegt, nicht ändern kann. Ich werde es mal mit einer Umleitung versuchen....keine Ahnung ob das geht.
Ich habe aber noch eine "Zusatzfrage": wenn man die Sicherheitsinformationen einer migrierten Seite im Browser aufruft, sieht man, dass sie von let's encrypt zertifiziert wurden. Das Problem bei let's encrypt liegt ja bekanntlich darin, dass man das Zertifikat alle drei Monate erneuern muss. Folgerichtig läuft es bei meinen Seiten am 15.8. aus. Dabei dürfte der Feiertag das geringste Problem sein...:-) Aber wie geht es dann weiter? Kümmert sich die Telekom um die laufende Verlängerung oder geht das automatisch oder sitzen wir dann alle drei Monate wieder auf dem Trockenen? Das wäre nicht schön......?!?
Grüße, Harald

[#14]

@harald57

Hallo Harald,

natürlich wurden alle Daten auf die neue Plattform migriert.

Mit dem apploader liegst Du richtig. Ich weiß aber nicht, was Du jetzt mit der Umleitung meinst. Willst Du Deine Domain umleiten?

Das Zertifikat wir natürlich automatisch verlängert.

Gruß,
Ingo F.

[#15]

Hallo Ingo, nein, ich will nicht meine Domain umleiten. Die "apploader"-scripte enthalten jeweils eine (leicht auf https umstellbare) Adresse zu einem 'homepage.t-online'-Script mit Aufruf der jeweiligen Inhalte (forum, blog, Gästebuch etc.). Ruft man dieses script manuell auf, erscheinen dort wieder diverse http-Adressen, welche ich aber nicht ändern kann - es sei denn, ich lade das script herunter, modifiziere es und lade es auf meinen seiten-webspace wieder hoch. Wenn ich dann über einen modifizierten "apploader" (eigenes oder modifiziertes script) darauf zugreifen könnte, wäre die Anzeige vielleicht https-konform. Aber zum einen müsste ich einen Fachmann für das Umarbeiten des scripts hinzuziehen, und auch dann ist fraglich, ob es überhaupt funktionieren würde. Jedenfalls meinte ich das mit "umleiten", also Aufruf der Extra-Seiten über ein Script auf meinem webspace statt auf den telekom-Servern.
Momentan habe ich bei Forum, blog und Gästebuch einfach eine "Vorschaltseite" mit Warnhinweis eingebaut, von der aus die weniger hysterischen Besucher dann auf die "unsicheren" Seiten zugreifen können. Somit erscheinen auf den Hauptseiten meiner homepage keine Browser-Warnungen mehr. Den Rest kann dann jeder für sich entscheiden. Sollte ich noch eine bessere als diese "Krückstock"- Lösung finden, melde ich mich, und Du gerne, falls sich die Kollegen die Sache mit den "Extras" doch noch anders überlegen. Der DA wäre es ungeachtet aller Zeitgeist-Manie wert, und auch für cm4all wäre es sicher keine große Sache.

Ansonsten vielen Dank und Grüße,
Harald

[#16 · Accepted solution]

Hallo @harald57,

letztendlich müssen wir mit diesem "Zustand" leben. Der Designassistent wird bereits seit mehreren Jahren nicht mehr weiterentwickelt und stammt aus einer Zeit, in der die Nutzung von Zertifikaten für die eigene Domain noch nicht verbreitet war. Entsprechend wurde bei der Entwicklung dieser Anwendungsfall nicht berücksichtigt.

An diesem Zustand wird sich auch nichts mehr ändern. Was kann man in diesem Fall tun? Hier findest du eine Hilfe dazu: https://homepagecenter.telekom.de/index.php?id=790

Mein ganz persönlicher Tipp: Es wäre wirklich der Zeitpunkt gekommen, sich Gedanken zu machen, ob du neben der bestehenden Homepage eine neue über ein Offline-Programm erstellst oder eine Umstellung auf den Homepage Creator vornimmst.

Viele Grüße Nadine H.

[#17]

Hallo zusammen! Nach rund einem halben Jahr komme ich nochmal auf diesen Beitrag zurück. Heute habe ich nämlich überrascht festgestellt, dass nach der letzten Veröffentlichung meiner umfangreichsten Seite (homepage advanced, erstellt mit dem Design-Assistenten) nun offenbar sämtliche DA-Bausteine (im Seitenquelltext erkennbar an der Bezeichnung "WebApp-ID..." und dem scriptelement "apploader") auf https umgestellt wurden und zumindest in den bei mir installierten Browsern nun wieder ohne Fehler- bzw. Sicherheitsmeldung funktionieren. Sollte es wirklich möglich sein, dass sich ein Telekom-Mensch doch noch dieser Problematik angenommen hat? Entgegen den oben mehrfach geäußerten Verlautbarungen ("da wird sich auch nichts mehr ändern..." etc.)?
Vielleicht können die Teamleute (Nadine, Ingo...) das bitte noch einmal verifizieren, bevor ich sämtliche "Vorschaltseiten" mit Warnhinweisen wieder entferne und vielleicht auch meine zwischenzeitlich von Hand (wegen des unsicheren "apploader"-scripts) eingesetzten widgets wieder gleich im DA einfüge.
Falls es sich wirklich so verhält wie vermutet entbiete ich schon jetzt ein dickes Dankeschön an die betreffenden MitarbeiterInnen. Damit könnte der DA noch locker ein paar Jährchen weiterleben, wenn man ihn lässt. Ich habe meine DA-Seiten mit ein paar wenigen Kniffen (uralte Seiten in die Mitte rücken, passende stehende Bildhintergründe einfügen - alles mit wenigen Klicks nach der Veröffentlichung zu machen) "aufgepimpt", so dass sie problemlos mit zeitgeistüberfrachteten chichi-Seiten mithalten können.

Grüße an alle,
Harald

[#18]

@harald57

Hallo Harald,

vorab erst einmal ein frohes neues Jahr.

Ich habe die Info gefunden, dass man für die SSL-Problematik im Design-Assistenten einen Workaround gefunden hat, aber das dieser bereits umgesetzt wurde, ist mir nicht bekannt.
Ich werde das bei den Kollegen noch einmal genau in Erfahrung bringen und Dir dann hier eine Rückmeldung geben.

Gruß,
Ingo F.

[#19]

Hallo Ingo,
Dir auch ein gutes neues Jahr und danke für die Antwort.
Bei mir funktionieren jedenfalls alle Seiten mit "Extras" (blog, forum, alte Diashow usw.) jetzt ohne Beanstandung. Allgemeine Widgets habe ich noch nicht getestet, weil ich sie zwischenzeitlich immer von Hand nachträglich eingefügt habe und erst wieder alles umstellen müsste.
Wenn Du mit den Kollegen kommunizierst, bitte Sie doch gleich darum, im Gästebuch-Script die Abfragezeile zu korrigieren (ich kann den zugehörigen Apploader zwar aufrufen, aber natürlich nicht ändern). Die kritische Zeile ist m.E. diese:

var dummy = new URL("http://dummy?" + appInfo.customField);

Das ist die Zeile, in der ein Gast seine homepage-Adresse eingeben kann. Das "http" ist dort als Voreintrag zu sehen und müsste natürlich "https" heißen. Über diese Kleinigkeit stolpert der Browser und gibt eine Fehlermeldung aus (die Seite wird trotzdem geladen und angezeigt). Wenn das korrigiert wird, funktioniert auch das Gästebuch wieder einwandfrei.
Ansonsten werden speziell in unserem Gästebuch nur die Emoticons beanstandet, die einige dort hinterlassen haben. Keine Ahnung, ob die irgendwo auf dem t-online-server hinterlegt sind oder wie die Besucher die da hinein gebracht haben - aber egal, das dürfte nicht so tragisch sein und vielleicht kann ich die ja auch als admin entfernen.

Grüße,
Harald

[#20]

@harald57

Hallo Harald,

vielen Dank für die Information zu dem Eintrag im Gästebuch, dies habe ich an meine Anfrage direkt angehängt.

Ich kann jetzt auch schon sagen, dass die Änderungen im Design-Assistenten bezüglich der SSL-Kompatibilität noch nicht vollständig abgeschlossen, aber wie Du ja bereits gemerkt hast, sind die Kollegen fleißig dabei.
Wir müssen uns also noch ein wenig gedulden, und wenn ich einen Termin bekomme, wann die Arbeiten abgeschlossen sind, werde ich mich wieder melden.

Also warte erst einmal noch mit Deinen Umbaumaßnahmen.

Gruß,
Ingo F.

[#21]

@harald57

Hallo Harald,

wir haben nun eine Rückmeldung bekommen. Der Design Assistent ist jetzt tatsächlich voll umfänglich SSL-fähig. Alle Module werden entsprechend nachgeladen.

Den Einwand wegen der Vorgabe https wurde von den Kollegen an die Entwickler weitergegeben.

Viele Grüße Nadine H.

[#22]

Hallo Nadine,

danke für die Info. Das ist eine tolle Nachricht und irgendwie auch eine späte Bestätigung für meine diesbezüglichen Posts. Ich denke, man hätte das auch früher schon kommunizieren können, dass der DA nun doch ssl-fähig wird. Ich bin sicher, es gibt noch immer viele Kunden, die den DA nutzen, und die weder Lust noch Zeit haben, ihre kompletten Seiten umzustellen. Auch wenn die vielleicht nicht ganz dem Zeitgeist entsprechen, der ja morgen bekanntlich schon wieder woanders ist.

Viele Grüße und nochmal danke an die, die sich dafür eingesetzt haben.

Harald

[#23]

@harald57

Hallo Harald,

da muss ich dir beipflichten, es gibt viele Kunden, die auch heute noch den Designassistent für die Bearbeitung Ihrer Homepage nutzen und viele, die extra wegen der SSL-Problematik umgestellt haben. Uns war es hier tatsächlich nicht bekannt, dass der Designassistent SSL-fähig gemacht wird. Nun freuen wir uns darüber, dass es doch noch umgesetzt wurde.

Viele Grüße Nadine H.