Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.
Auszug

Das Release 7.35.0 Build 1700 wurde im Juni 2020 veröffentlicht. Dieses Release umfasst:

  • Weitere Anpassungen für Cloud-Betrieb

  • Secure- und SameSite-Flag für Cookies

  • Verbesserung in der CSE

Weitere Anpassungen für Cloud-Betrieb

Newsletter Versandaufträge in die Datenbank synchronisieren

Für Setups in der Cloud gibt es nun die Option, die Warteschlange der Newsletter Versandaufträge – das Verzeichnis UM/cmsbs-work/listen/ – in die Datenbank zu synchronisieren. Somit entfällt dann an dieser Stelle die Notwendigkeit, ein persistentes Speichervolume einzurichten.

Um die neue Funktion zu nutzen, muss die folgende globale Option gesetzt werden:

Codeblock
cmsbs.directory.listen.syncWithVfs = true

Ausgehende E-Mails zählen

Ausgehende E-Mails werden ab jetzt intern pro Tag und pro Kalendermonat gezählt. Jeden Tag erfolgt nach Berechnung der Statistiken – gewöhnlich um Mitternacht – eine kurze Ausgabe im cmsbs-work/sys.log, die Auskunft über die Anzahl der versendeten E-Mails und die Anzahl der gespeicherten Einträge gibt:

Codeblock
2020-06-10 00:00:01,597 [Statistics] INFO cmsbs: Usage summary: {"month": "2020-06", "outgoingEmailsInMonth": 7074, "totalEntries": 350, "timestamp": "2020-06-10|00:00:01"}

Soll die Anzahl der pro Monat versendeten E-Mails beschränkt werden, kann mit folgender Option die Obergrenze pro Monat festgelegt werden:

Codeblock
cmsbs.quota.outgoingMailsPerMonth = 50000

Ist diese Option gesetzt, erfolgt zusätzlich eine Fehlermeldung in der Logdatei, falls um Mitternacht eine Überschreitung für den laufenden Monat festgestellt wurde. Eine tatsächliche Beschränkung des E-Mailversand findet jedoch nicht statt.

Darüber hinaus wird bei gesetzter Option unter Extras / System der aktuelle Stand und der erlaubte monatlich Wert angezeigt:

Image RemovedImage Added

Der Link führt auf das Diagramm mit den täglichen Versandzahlen:

Dieses neue Feature ist i.A. für on-premise-Installationen nicht relevant, da dort überlicherweise keine Beschränkung der Anzahl der versendeten E-Mails gewünscht ist.

/cmsbs/rest nicht mehr in der GUI verwenden

Wenn der UM öffentlich erreichbar im Internet steht (z.B. bei einer typischen Installation in der Cloud), sollte aus Sicherheitsgründen der Pfad /cmsbs/rest/ für den Zugriff von außen gesperrt werden. In einem solchen Setup dient der REST-Proxy dazu, gezielt einzelne Endpunkte, die sonst unter /cmsbs/rest/… erreichbar wären, von außen zugänglich zu machen.

Aus historischen Gründen gab es bisher noch einzelne GUI-Funktionen, die teilweise auf Endpunkte unter /cmsbs/rest zugegriffen haben:

  • Dashboard

  • Entry-Overview

  • Anzeige der Icons unter Extras / Apps

Mit dem Update auf UM 7.35.0 wurden diese drei o.g. Endpunkte nach /cmsbs/Custom verschoben, so dass nun /cmsbs/rest für den Zugriff von außen komplett gesperrt werden kann. Dies kann z.B. durch entsprechende Regeln in einem vorgeschalteten Reverse-Proxy oder Load-Balancer realisiert werden.

Hinweis

Projekte, in denen eigene Dashlets in das Dashboard oder die Eintragsübersicht (Entry Overview) integriert wurden, müssen vor dem Update überarbeitet werden!

Dabei müssen die bisher im rest-Scope implementierten Dashlets in den wizard-Scope verschoben werden. Dort müssen sie dann ggf. als Wizard registriert und URLs angepasst werden.

Neue Konfigurationsoptionen

Secure-Flag für Cookies

Bei Verwendung des embedded Tomcat kann nun global eingestellt werden, dass alle (Session-) Cookies, die vom Tomcat zum Client gesendet werden, das Secure-Flag bekommen sollen:

Codeblock
cmsbs.server.cookies.secure = true

Der Default ist false, was in aktuellen Browsern unter bestimmten Umständen zu Warnmeldungen führen kann.

SameSite-Attribut für Cookies

Bei Verwendung des embedded Tomcat kann nun global eingestellt werden, dass alle (Session-) Cookies, die vom Tomcat zum Client gesendet werden, ein bestimmtes SameSite-Attribut bekommen sollen.

Codeblock
cmsbs.server.cookies.sameSite = "None"

Erlaubte Werte:

Wert

Beschreibung

Unset

SameSite-Option wird nicht gesetzt. (Default im UM)

None

Für Cross-Domain-Anwendungen; ermöglicht, dass Cookies auch bei Cross-Origin-Requests mitgesendet werden.

Erfordert, dass das Secure-Flag (siehe oben) gesetzt ist.

(Ist teilweise noch der Default der führenden Browser; Stand Mai 2020.)

Lax

Cookies sollen bei Cross-Origin-Requests nicht mitgesendet werden.

(Wird zukünftig der Default der führenden Browser werden.)

Strict

Cookies sollen bei Cross-Origin-Requests mitgesendet werden, allerdings nicht beim ersten Aufruf der Ursprungsseite über einen Link von einer Cross-Origin-Seite.

Da das SameSite-Attribut noch nicht in allen gängigen Browsern richtig behandelt wird, muss dieses Feature als experimentell angesehen werden.

Siehe auch:

Eingebettete H2-Datenbank im Server-Modus starten

Die häufig in Entwicklungsumgebungen verwendete eingebettete H2-Datenbank kann nun optional im Server-Modus gestartet werden, so dass während der Laufzeit des UM im eingebetteten Tomcat von außen mit einem externen DB-Tool (z.B. DbVisualizer) per JDBC auf die Datenbank zugegriffen werden kann.

Dazu muss folgende globale Option gesetzt werden:

Codeblock
cmsbs.server.h2.port = 9092

Damit wird die H2-Datenbank beim Start des eingebetteten Tomcat auf localhost:9092 erreichbar gemacht. Die JDBC-URL wird bei jedem Start ausgegeben, z.B.:

Codeblock
* Starting H2 server on port 9092, JDBC URL: jdbc:h2:tcp://localhost:9092//UM/cmsbs-work/db.h2

In DbVisualizer kann die Verbindung mit folgenden Einstellungen hergestellt werden:

  • Database Driver: H2 embedded

  • Settings Format: Database URL

  • Database URL: (wie im Log angegeben)

  • Database Userid: sa

  • Database Password: (leer)

One-Click-Unsubscribe

Der UM unterstützt nun One-Click-Unsubscribe nach RFC 8058. Dabei werden in einem versendeten Newsletter zwei zusätzliche Header gesetzt, so dass Mail-Clients eine automatisierte Abmeldung auslösen können.

Dazu ist es notwendig, beim Newsletterversand eine Verknüpfung zu einer Newsletter App-Instanz herzustellen. So kann eine Abmeldung gemäß den Einstellungen aus der Newsletter App durch den Mail-Client des Empfängers ausgelöst werden.

Zunächst muss die Funktion durch Festlegen der URL des neuen One-Click-Unsubscribe-HTTP-Endpunkts aktiviert werden:

Codeblock
cmsbs.mail.one_click_url = http://my-domain.com/p/de.pinuts.cmsbs.newsletter.OneClick

Dieser neue HTTP-Endpunkt muss in die Whitelist des REST-Proxy eingetragen werden; z.B.:

Codeblock
cmsbs.restproxy.limit.controller.whitelist.1 = "de.pinuts.cmsbs.newsletter.OneClick"

Sind diese Einstellungen erfolgt, erweitert sich der Wizard für den Newsletterversand um ein neues Feld zur Zuordnung der Newsletter App-Instanz:

Bei der Erstellung eines Event-Files kann die Zuordnung wie folgt vorgenommen werden:

Codeblock
languagexml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<event …>
    <data>
        <appInstance name="985fb277-2451-471a-a747-2ba074f70569" oneClickUnsubscribe="true" />
        <email … >

Beim Newsletterversand setzt der UM dann entsprechend den Einstellungen die folgenden Header:

Codeblock
List-Unsubscribe: <http://my-domain.com/p/de.pinuts.cmsbs.newsletter.OneClick/unsubscribe?name=985fb277-2451-471a-a747-2ba074f70569&msgid=1F1D8.2CID4.F77FB27D94479A2CB87BDC8C7A01AD64>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Laut RFC wird eine DKIM-Signierung der ausgehenden E-Mails vorausgesetzt.

Bislang unterstützen nur sehr wenige Mail-Clients den neuen Standard.

Verbesserungen in der Core Scripting Engine

Dateiendung .mjs

In ES6 (oder einem neueren JavaScript-Dialekt) geschriebene CSE-Skripte können nun statt der Dateiendung .es6 auch die Endung .mjs verwenden. Letztere scheint sich im Node-Umfeld als Standard für JavaScript-Dateien zu etablieren, die JavaScript Modules – also import und export – verwenden.

CSE- und REST-API-Dokumentation

Über das Hilfe-Menü sind ab sofort immer eine fertig generierte CSE- und REST-API-Dokumentation verfügbar.