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
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:

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:

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:

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:

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.

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:

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.

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:

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.:

* 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:

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.:

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:

<?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:

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.

Universal Messenger 7.35.0