Drittanbieter-Komponenten

1. Warum Ephraim Drittanbieter-Komponenten gesondert verwaltet

Drittanbieter-Komponenten sind Programmteile, die nicht von Ephraim selbst stammen, aber im Produkt mit ausgeliefert werden. Sie laufen im Sicherheitskontext der Anwendung: JavaScript- und CSS-Komponenten beeinflussen die Darstellung im Browser, PHP-Komponenten erzeugen E-Mails, PDFs oder serverseitige Vorlagen. Ein Fehler in einer solchen Komponente berührt deshalb nicht nur Komfort, sondern auch Sicherheit, Datenschutz, Exportqualität und Betriebssicherheit.

Ephraim behandelt diese Komponenten als kontrollierte Lieferkette. Ein externer Versionshinweis ist keine Installationsfreigabe. Ein Download ist kein geprüfter Zielstand. Eine technische Prüfung ist noch keine Entscheidung. Erst ein freigegebener, erneut geprüfter und vorbereiteter Paketstand wird installiert.

2. Welche Komponenten zum Inventar gehören

Das Inventar umfasst lokal gebündelte Browser- und PHP-Komponenten des Frontends. Nicht dazu gehören Betriebssystempakete, Datenbankserver, PHP selbst, Webserver, Container, die Spark-Dienste, externe Inferenzsysteme oder Browser der Nutzerinnen und Nutzer. Diese Grenze ist wichtig: Die Adminseite beantwortet die Frage, welche in Ephraim ausgelieferten Bibliotheken gepflegt werden.

Die Liste ist bewusst klein und namentlich bekannt. Ephraim durchsucht keine beliebigen Ordner nach unbekannten Bibliotheken und übernimmt keine Komponenten aus Nutzereingaben. Jede inventarisierte Komponente hat einen festen Namen, eine feste fachliche Aufgabe und eine definierte Methode zur lokalen Versionserkennung.

3. Was die Übersicht zeigt

Die Adminübersicht ist die tägliche Kontrollfläche. Sie liest den lokalen Stand, zeigt intern freigegebene Zielstände und stellt den zuletzt gecachten externen Hinweis daneben. Dadurch sehen Admins in einer Tabelle, ob Ephraim eine Komponente erkennt, ob eine Quelle neuere Informationen gemeldet hat und ob bereits eine interne Freigabe existiert.

4. Warum Ephraim keine Paketregister automatisch nutzt

Die Komponentenpflege fragt keine allgemeinen Paketregister ab. Ephraim nutzt für diesen Prozess kein npm, kein Packagist, keine CDN-Autoupdates, keine frei eingebbaren Download-URLs, keine privaten Repositories und keine Zugangsdaten zu externen Quellen. Diese Entscheidung reduziert die Angriffsfläche: Admins tragen keinen beliebigen Link in die Anwendung ein und installieren daraus keinen Code.

Externe Informationen sind Hinweise. Sie stammen aus fest erlaubten öffentlichen GitHub-Projekten oder ausdrücklich erlaubten Projektseiten. Die Anwendung übernimmt daraus zunächst nur Metadaten wie einen gemeldeten Versionsstand. Der normale Adminseitenaufruf wartet nicht auf eine externe Abfrage. Eine manuelle Prüfung speichert eine Anforderung; der Wartungslauf verarbeitet diese Anforderung im Hintergrund und aktualisiert den gecachten Stand.

5. Rollen und Zuständigkeiten

Der Workflow trennt Lesen, Vorschlagen, Entscheiden und Installieren. Dadurch entstehen klare Zuständigkeiten und keine einzelne Oberfläche führt unbemerkt ein vollständiges Update aus.

Die gleichen fachlichen Grenzen gelten auch für terminalgestützte Adminarbeit und berechtigte Automationsclients. Der technische Zugang nutzt denselben Komponentenworkflow; er ist keine Abkürzung um Rollen, Bestätigungen oder Prüfbedingungen herum.

6. Der Freigabe-Workflow im Überblick

Der Freigabe-Workflow besteht aus fünf getrennten Zuständen. Jeder Schritt erzeugt eine eigene fachliche Aussage: Ein Vorschlag sagt, welcher externe Stand betrachtet wird. Die technische Prüfung sagt, ob genau dieser Stand aus einer erlaubten Quelle reproduzierbar und mit Hashwerten belegbar ist. Die Freigabe sagt, dass ein Super-Admin diesen geprüften Stand als Ephraim-Zielstand akzeptiert. Vorbereitung und Installation prüfen das Paket erneut, bevor Dateien ersetzt werden.

7. Erlaubte Paketquellen und Paketmodi

Eine installierbare Paketquelle entsteht nicht durch einen Klick in der Adminoberfläche. Sie wird als Wartungsentscheidung hinterlegt und ist für Ephraim nur lesbar. Darin steht, welches öffentliche Projekt, welcher Tag- oder Versionsmechanismus, welcher Host, welcher Zielbereich, welche Einstiegspunkte und welcher Paketmodus für eine konkrete Komponente zulässig sind. Hashes stehen dort nicht fest vorgegeben; Ephraim berechnet sie während der technischen Prüfung selbst.

Wenn für eine Komponente nur eine Hinweisquelle existiert, bleibt sie im Workflow lesbar. Die UI zeigt dann Wartungsbedarf oder blockierte Installation. Das ist kein Fehlerzustand, sondern eine Schutzregel: Ein Hinweis auf eine neue Version reicht nicht aus, um ausführbaren Code in Ephraim zu übernehmen.

8. Was bei der technischen Prüfung passiert

Die technische Prüfung macht aus einem Vorschlag ein reproduzierbares Paket. Ephraim prüft den Komponentenschlüssel, die Version, den Quelltyp, den Anbieter, den Zielbereich und den Paketmodus. Danach lädt die Anwendung das erlaubte öffentliche Artefakt über HTTPS, begrenzt Zeit, Dateigröße und Umleitungen und verwirft Quellen, die nicht zur erlaubten Hostliste passen.

Anschließend wird das Archiv normalisiert. Ephraim akzeptiert keine Pfade, die aus dem Zielbereich ausbrechen, keine Symlink-Tricks, keine unerwarteten Einstiegspunkte und keine Pakete oberhalb der definierten Größen- und Dateigrenzen. Aus dem Archiv entstehen Datei-Hashes, ein Paket-Hash und ein Archiv-Hash. Diese Werte werden gespeichert und später erneut verglichen.

Die PHP-Smoke-Tests sind absichtlich klein und ohne externe Nebenwirkungen: PHPMailer wird geladen und instanziiert, ohne E-Mail zu versenden. TCPDF erzeugt eine minimale PDF-Ausgabe im Speicher. Twig lädt lokal, liest die Version und rendert ein minimales Template. Zusätzlich werden die PHP-Dateien syntaktisch geprüft.

9. Freigabe, Vorbereitung und Installation

Die Freigabe speichert keinen abstrakten Begriff wie „neueste Version“, sondern eine konkrete Version mit Quelle, Tag oder Referenz, Paketdaten, Hashes und Akteur. Damit bleibt später nachvollziehbar, welcher Stand gemeint war. Nach der Freigabe beginnt noch keine Installation. Die Vorbereitung lädt das Artefakt erneut und vergleicht es mit den gespeicherten Hashes. Weicht der Download ab, stoppt der Vorgang.

Vor der Installation prüft Ephraim die Produktionsbedingungen: Direkte Updates müssen aktiviert sein, Staging- und Backupbereiche müssen beschreibbar und außerhalb öffentlich ausgelieferter Bereiche liegen, benötigte PHP-Erweiterungen müssen verfügbar sein und bei PHP-Vendor muss ein echter PHP-CLI-Syntaxcheck laufen. Fehlt eine Bedingung, zeigt die Oberfläche den Blocker und führt keinen Dateitausch aus.

Beim Installieren erstellt Ephraim zuerst ein Backup des betroffenen Komponentenbereichs. Danach werden nur die im Manifest erlaubten Dateien ersetzt. Direkt nach dem Tausch prüft Ephraim die aktivierten Dateien gegen die freigegebenen Datei-Hashes. Erst danach wird das Paket als installiert markiert und das Inventar aktualisiert.

10. Rollback und Fehlerverhalten

Rollback ist kein improvisiertes Zurückkopieren. Ephraim nutzt ein selbst erzeugtes und validiertes Backup-Manifest. Dieses Manifest beschreibt, welcher Komponentenbereich vor der Installation gesichert wurde und welche Dateien wiederhergestellt werden. Ohne gültiges Backup bleibt Rollback gesperrt.

Schlägt eine Installation fehl, versucht Ephraim automatisch, aus dem gerade erzeugten Backup wiederherzustellen. Das Ereignis wird als fehlgeschlagene Installation mit Rollback protokolliert. Schlägt auch das Rollback fehl, meldet die Anwendung diesen Zustand ausdrücklich, weil dann ein manueller Betriebseingriff erforderlich ist.

11. Wartungslauf, Badge und Super-Admin-Mails

Der Wartungslauf inventarisiert die Komponenten regelmäßig und verarbeitet manuelle Prüfanfragen. Als Mismatch gelten erkannte Update-Hinweise, freigegebene aber lokal noch nicht erreichte Zielstände und Erkennungsfehler. Die Anzahl erscheint als Badge im Admin-Dashboard, damit offene Komponentenpflege nicht in der Unterseite verborgen bleibt.

Bei Mismatches informiert Ephraim Super-Admins per E-Mail, sofern E-Mail-Adressen hinterlegt sind. Die Benachrichtigung nutzt einen Fingerprint der Mismatch-Liste. Wiederholte Mails entstehen erst, wenn sich der relevante Zustand ändert. Dadurch erhalten Super-Admins Hinweise auf neue Arbeit, ohne bei unverändertem Stand dauerhaft gleiche Meldungen zu bekommen.

12. Nachvollziehbarkeit und Audit-Spur

Der Komponentenworkflow speichert Vorschläge, technische Prüfungen, Zielstandsfreigaben, Paketdaten, Jobs, Backup-Manifeste und relevante Ereignisse. Zu den gespeicherten Informationen gehören Akteur, Zeitpunkt, Komponente, Version, Status, Quelle, Prüfergebnis und Hashdaten. Diese Audit-Spur beantwortet später drei zentrale Fragen: Wer hat welchen Stand vorgeschlagen? Wer hat ihn freigegeben? Welches Paket wurde installiert oder zurückgerollt?

Die Protokollierung ist nicht nur für Fehlersuche nützlich. Sie macht den Umgang mit Drittanbieter-Code gegenüber Schulleitung, Datenschutzbeauftragten und technischen Prüfern erklärbar. Die Protokolle zeigen, dass Komponenten nicht zufällig aus dem Internet geladen wurden, sondern einem mehrstufigen internen Prozess folgten.

13. Entscheidungshilfe für Admins und Super-Admins

Komponentenpflege verlangt keine tägliche Aktivität, aber klare Entscheidungen, wenn die Oberfläche einen neuen Stand meldet. Admins und Super-Admins verwenden die folgenden Regeln:

14. Bewusste Grenzen des Systems

Die Komponentenverwaltung ist kein allgemeiner Software-Updater. Sie aktualisiert keine Serverpakete, keine Container, keine Datenbank, keine Spark-Dienste und keine Betriebssystembibliotheken. Sie löst auch keine Lizenzbewertung und keine fachliche Kompatibilitätsprüfung automatisch. Sie liefert die technische Grundlage, damit ein geprüfter Komponentenstand sicherer und nachvollziehbarer übernommen wird.

Ebenso ersetzt eine grüne technische Prüfung keine fachliche Abnahme. Nach Updates an Rendering-Komponenten werden Chatnachrichten, Mathematik, Codeblöcke, Visualisierungen und Exportpfade geprüft. Nach Updates an PHP-Komponenten werden E-Mail-Versand, PDF-Erzeugung oder Template-Ausgaben passend zur Komponente geprüft. Die Adminfunktion kontrolliert die Lieferkette; die Betriebspraxis kontrolliert die konkrete Wirkung in Ephraim.