Get the MOST

Vor knapp eineinhalb Jahren haben wir gezeigt, wie man die Aktualisierung verwendeter Drittkomponenten mit GitHub Actions automatisieren kann.

Zwischenzeitlich sind wir hierbei auf den Dependabot umgestiegen. Dieses Tool wird bei GitHub schon länger zum Aufspüren und Melden von Sicherheitsproblemen verwendet. Es ist damit jedoch auch möglich, Updates zu suchen und bereitzustellen.

Im Gegensatz zu dem früheren Vorgehen gibt es dabei folgende Unterschiede und Vorteile:

• Für jede Komponente wird ein eigener Pull Request erstellt. So lassen sich mögliche Probleme in den Builds unabhängig erkennen und die Updates lassen sich selektiv mergen.
• Die enthaltenen Commits sowie etwaige Release Notes und Changelogs werden direkt im Pull Request zur Verfügung gestellt, um die damit einhergehenden Änderungen transparent zu machen.
• Die Pull Requests werden bei Änderungen im Zielbranch automatisch via Rebase aktualisiert, um Merge-Konflikten vorzubeugen.
• Gibt es für eine Komponente eine neue Version, wird ein möglicherweise noch offener Pull Request mit einer früheren Version automatisch mit einem entsprechenden Kommentar (Superseded by #123) geschlossen.
• Wie im Screenshot zu sehen ist, kann man in Form von Kommentaren mit Dependabot interagieren und so das Verhalten steuern.
• Es gibt ein einheitliches Interface für unterschiedliche Arten von Paketmanagern. So werden nicht nur Composer, npm und yarn unterstützt, sondern zum Beispiel auch Maven, pip, Terraform und auch GitHub Actions.

Ein Beispiel

Mit der folgenden Konfiguration wird Dependabot die Aktualisierungen für PHP-Vendors (composer), JavaScript-Vendors (npm) und die in den CI-Builds verwendeten Komponenten (github-actions) übernehmen:

Um zu verhindern, dass eine Entwicklungs- oder Testumgebung eines Systems von unbefugten Personen, Suchmaschinen oder anderen Bots aufgerufen wird, bietet sich ein Kennwortschutz an. Eine einfache Möglichkeit hierfür stellt die sogenannte Basic Authentication dar. Diese Variante der HTTP-Authentifizierung ist sowohl mit Apache als auch mit Nginx schnell eingerichtet und reicht für viele Anwendungszwecke aus.

Bei der Verwendung mit Shopware 6 stellt man allerdings fest, dass das Backend nicht mehr korrekt funktioniert. Nach einiger Recherche sind wir auf eine Lösung gestoßen: der Ansatz besteht hierbei darin, die Authentifizierung für die API-Routen zu deaktivieren. Die Art der Umsetzung hängt hierbei naturgemäß vom benutzten Webserver ab.

In vielen Weblayouts ist es notwendig, unterschiedliche Ausprägungen einer bestimmten kosmetischen “Stellschraube” zu realisieren. So können etwa einzelne Akzentfarben je nach Unterseite, Kategorie oder Jahreszeit abweichen. Dies sorgt oftmals für unschönen Boilerplate-Code, welcher jedoch mit SASS/SCSS einfach eingespart werden kann.

Erst einmal ausführlich

Angenommen, je nach body-Klasse sollen alle Artikel-Überschriften in der zweiten Ebene eine andere Farbe erhalten. Dies könnte mit reinem CSS zum Beispiel so aussehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

body.spring article h2 {
    color: green;
}
body.summer article h2 {
    color: yellow;
}
body.autumn article h2 {
    color: brown;
}
body.winter article h2 {
    color: blue;
}

Für diesen einen Fall fällt die Redundanz vielleicht nicht ins Gewicht, aber wenn sich solche Ausprägungen durch ein ganzes Layout ziehen, wird der Wunsch nach einer überschaubareren Alternative stärker.

Kürzlich erreichte uns eine Anfrage bezüglich des NextCloud-Systems eines Kunden: in einem Ordner ließen sich keine PDF-Dateien mehr öffnen. Statt der gewohnten integrierten PDF-Darstellung erschien lediglich eine Fehlermeldung:

PDF.js v2.5.207 (build: 0974d6052) Message: Missing PDF “https://cloud.domain.de/.../files/User/Ordner/Ein%2520Unterordner/und/so/weiter.pdf".

Eine Recherche in dem NextCloud-Repository auf GitHub führte zu einem entsprechenden Patch.

Hintergrund ist, dass in dem Pfad ein Leerzeichen enthalten war (im Beispiel: Ein Unterordner), was offenbar in der neuesten Version nicht korrekt behandelt wird. Nach Einspielen der gepatchten Datei und dem Leeren des Browser-Caches funktioniert es wieder.

Vor zwei Tagen wurde Symfony 5.3.0-BETA4 veröffentlicht. Dies nehme ich zum Anlass, um einmal einen Überblick über die wichtigsten neuen Funktionen zu geben, auf die wir uns im Rahmen dieses Updates freuen können. Im Folgenden sind die bisher veröffentlichten Blog-Beiträge thematisch nach Komponente sortiert.

Config

Config Builder Klassen

Console

Negierbare Command-Optionen

Verbesserte Debug-Commands

Lazy Command Description

DependencyInjection

Mehrere Environments in einer Datei konfigurieren

Service Autoconfiguration und Attribute

Service Autowiring mit Attributen

Form

Tailwind CSS Form Theme

Form Handler Helper

Sortierung für Formularfelder

HttpFoundation

Session Service Deprecation

Logging

Logging-Verbesserungen (Messenger, Deprecations)

Notifier

Notifier-Integrationen

OptionsResolver

Prototype Optionen

PasswordHasher

Neue PasswordHasher Komponente

Runtime

Neue Runtime Komponente

Security

Verbesserter Schutz gegen Breach-Angriffe

Serializer

Inlined Serialization Context

Twig Serialize-Filter

Translation

Translation Providers

Uid

Uid-Verbesserungen

Hugo ist ein Generator für statische Seiten, welcher auf der Programmiersprache Go basiert. Die Inhalte werden mit Markdown verwaltet und dynamisch in HTML umgewandelt. Dies ist für die meisten kleineren Projekte interessant, weil ausreichend und im Vergleich zu einem dynamischen Content Management System einfacher zu handhaben; zudem sind statische Seiten auch in Bezug auf Sicherheit und Performanz unschlagbar (siehe auch: Vorteile statischer Seiten).

Der Build lässt sich dann z. B. mit GitHub Actions durchführen (zum Einsatz kommt hierfür z. B. diese Action), wobei die resultierende Seite direkt mit GitHub Pages betrieben werden kann. Wer den Komfort einer UI zur Pflege der Inhalte nicht missen möchte, kann ein entsprechendes Frontend obendrauf packen.

Im Symfony Messenger gibt die Möglichkeit, fehlgeschlagene Nachrichten an eine failed queue zu leiten. In diesem Sammelbecken können diese dann inspiziert und nach Korrektur des zu Grunde liegenden Problems erneut verarbeitet werden.

Schlagen sie dabei erneut fehl, landen sie allerdings per Standard nicht wieder in der failed queue, sondern werden verworfen. Dies hat damit zu tun, dass die Nachricht bereits einen SentToFailureTransportStamp besitzt.

Möchte man jedoch die Nachricht immer wieder auffangen, bietet es sich an, diesen Stamp einfach vorher wieder zu entfernen. Dies kann mit der folgenden Middleware getan werden.

In Zikula gibt es eine Besonderheit zu beachten, welche Einfluss darauf nimmt, wie die aus einem Request resultierende Response zum anfragenden Client gelangt.

Per Standard wird die Response in Symfony im Rahmen einer Controller-Aktion erstellt und zurückgeliefert. Gegebenfalls wird die Response noch von einem oder mehreren Event Subscribern verändert.

Bei Zikula wird noch eine Theme-Schicht dazwischen geschaltet, welche den Inhalt der Response in eine neue Response überführt, um den Layout-Rahmen sowie damit einhergehende, zusätzliche Blöcke usw. zu rendern.

Zu den grundlegenden Aufgaben automatisierter Builds zählen unterschiedliche Prüfungen: so bietet es sich an, die Einhaltung der Coding-Styles zu überwachen, Qualitätsmetriken zu erheben und die Testabdeckung zu messen. Auch die regelmäßige Aktualisierung verwendeter Drittkomponenten kann perfekt automatisiert werden, wie wir es in diesem Beitrag für GitHub Actions gezeigt haben.

Ein nützliches Werkzeug, das anhand einer composer.lock Datei etwaige Sicherheitslücken in verwendeten Vendors aufgezeigt hatte, war der SensioLabs Security Checker. Dieser hat die entsprechenden Versionen mit einer Datenbank auf security.symfony.com abgeglichen und entsprechende Probleme gemeldet. Der entsprechende Datenbestand befindet sich ebenfalls auf GitHub.

Im Rahmen der GitHub Konferenz “Universe” wurden neue Funktionen und Verbesserungen vorgestellt. Für jeden dürfte hier etwas dabei sein.

Nachfolgend die für mich wichtigsten Neuerungen in der Kurzübersicht:

• Das Mergen von Pull Requests kann automatisiert werden, basierend auf vordefinierten Erforderlichkeiten, wie etwa notwendige Reviews und Prüfungswerkzeuge.
• Mit den Discussions lässt sich nun auch jedwede, von Aufgaben/Tickets unabhängige Kommunikation, wie Support und sonstige Abstimmungen, auf der GitHub Plattform durchführen.
• GitHub unterstützt jetzt offiziell einen Dark Mode.
• Auch Unternehmen können ab sofort GitHub Sponsors nutzen, um Open Source Projekte zu unterstützen.
• Workflows können mit einer Visualisierung übersichtlicher dargestellt werden (siehe auch diesen Beitrag).

Eine Gesamtliste mit allen anstehenden Veränderungen kann direkt auf GitHub angeschaut werden.