Häufig gestellte Fragen

Widget-Storm ist eine modulare Widget-Plattform, die seit 2008 aktiv betrieben wird. Das System ermöglicht es, wiederverwendbare Web-Komponenten (Widgets) zentral zu verwalten und über eine verschlüsselte Schnittstelle in beliebige Websites einzubinden.

Jedes Widget besteht aus drei Schichten — PHP, CSS und JavaScript — die unabhängig voneinander geladen und kombiniert werden können. Dieses Konzept nennen wir das Widget Triple Pattern.

Widget-Storm wurde 2008 entwickelt. Zu dieser Zeit war RIJNDAEL-256 (Rijndael mit 256-Bit Blockgröße) eine gängige und vertretbare Wahl. Die Gründe im historischen Kontext:

PHP’s mcrypt-Extension war der Standard-Weg. Die damals vorherrschende Kryptografie-Bibliothek in PHP — mcrypt — bot MCRYPT_RIJNDAEL_256 als erstklassige Option direkt neben MCRYPT_RIJNDAEL_128 an. Die Dokumentation machte keinen deutlichen Unterschied bezüglich der Standardisierung. Wer MCRYPT_RIJNDAEL_256 wählte, folgte schlicht der verfügbaren API.

OpenSSL-Integration war noch nicht Standard. openssl_encrypt() mit sauberem AES-256-CBC kam erst mit PHP 5.3 (2009) richtig in Fahrt und wurde erst Jahre später zur empfohlenen Alternative. 2008 war mcrypt der pragmatische Weg.

AES-NI existierte noch nicht. Intels Hardware-Beschleunigung für AES (AES-NI) kam erst 2010 auf den Markt. Der Performance-Nachteil von RIJNDAEL-256 gegenüber AES war 2008 auf Server-Hardware marginal — beides lief rein in Software.

Keine Compliance-Anforderungen. Für ein deutsches Web-Projekt 2008 war FIPS-140-Zertifizierung kein Thema. Die DSGVO gab es noch nicht, PCI-DSS war für die meisten Projekte irrelevant. Überhaupt Verschlüsselung einzusetzen war bereits überdurchschnittlich.

Fazit: Die Entscheidung war dem Stand der Technik von 2008 entsprechend — nachvollziehbar und keineswegs fahrlässig. Seit der Modernisierung unterstützt Widget-Storm zusätzlich AES-256-CBC als modernen Verschlüsselungsstandard.

Widget-Storm betreibt eine Dual-Stack-Architektur: Beide Verschlüsselungsverfahren koexistieren permanent. Ein zentraler EncryptionNegotiator erkennt automatisch, welche Version ein Nutzer verwendet, und leitet die Kommunikation entsprechend weiter.

Neue Nutzer erhalten automatisch v2 (AES-256-CBC). Bestehende Nutzer bleiben auf v1 und können auf Wunsch migriert werden — ohne Unterbrechung ihres laufenden Betriebs.

Ja. Widget-Storm schützt die Kommunikation auf mehreren Ebenen:

• Transportverschlüsselung: Alle Verbindungen laufen über HTTPS (TLS). HTTP-Anfragen werden automatisch auf HTTPS umgeleitet.
• Payload-Verschlüsselung: Widget-Daten werden zusätzlich auf Anwendungsebene verschlüsselt, bevor sie übertragen werden. Jeder Nutzer hat einen eigenen Schlüssel.
• Input-Validierung: Alle Eingabeparameter werden serverseitig validiert und sanitiert.
• Rate-Limiting: Automatischer Schutz gegen übermäßige Anfragen.
• Request-Logging: Alle API-Zugriffe werden protokolliert, um Missbrauch frühzeitig zu erkennen.

Die Sicherheitsarchitektur wird kontinuierlich überprüft und verbessert. Das RIJNDAEL-256-Verfahren ist kryptografisch nicht gebrochen — die Modernisierung auf AES-256-CBC erfolgt aus Gründen der Standardkonformität und besserer Betriebsmodi (CBC mit IV statt ECB), nicht wegen einer Sicherheitslücke.

wgclient und wghandler sind die beiden Dateien, die auf Ihrer Website das Widget-Storm-System anbinden:

• wgclient.php — Der Einstiegspunkt. Diese Datei wird in Ihre Website eingebunden und stellt Widgets per HTTP-Anfrage beim Widget-Storm-Server ab. Der wgclient ist personalisiert und enthält Ihre Zugangsdaten (verschlüsselt).
• wghandler.php — Die Kommunikationsschicht. Diese Datei übernimmt Verschlüsselung, Entschlüsselung und den lokalen Widget-Cache (CodeVault). Sie wird automatisch generiert und ist auf Ihren Schlüssel zugeschnitten.

Beide Dateien erhalten Sie nach der Registrierung in der Widget-Storm Station. Die Schlüssel werden bei jedem Download rotiert.

Der wghandler speichert abgerufene Widgets automatisch im CodeVault (wgbuilds/). Dadurch wird jedes Widget beim nächsten Aufruf direkt lokal geladen — schneller als jeder Netzwerk-Roundtrip. Sie können auch steuern, ob Widgets lokal gerendert oder live vom Server abgerufen werden sollen.

Jedes Widget in Widget-Storm besteht aus drei unabhängigen Schichten:

1. PHP — Serverseitige Logik und HTML-Generierung
2. CSS — Styling, inklusive PHP-in-CSS Bridge für dynamische Werte
3. JavaScript — Clientseitige Interaktivität

Diese drei Schichten werden getrennt über den wgclient geladen. Das ermöglicht es, nur die Teile eines Widgets zu laden, die tatsächlich benötigt werden — etwa nur das CSS für die Darstellung, ohne unnötiges JavaScript.

Widgets können zudem rekursiv ineinander verschachtelt werden: Ein Widget kann über spezielle Marker (##wgstart##...##wgend##) weitere Widgets einbetten. So entstehen komplexe Oberflächen aus einfachen, wiederverwendbaren Bausteinen.

Der CodeVault ist nicht nur ein Cache — er ist das primäre Auslieferungssystem für Widgets. Beim ersten Abruf speichert der wghandler den entschlüsselten Widget-Code als lokale Dateien im Verzeichnis wgbuilds/ auf Ihrem Webserver. Ab diesem Moment wird das Widget direkt vom Dateisystem geladen — kein Netzwerk-Roundtrip, keine Latenz, keine Abhängigkeit vom zentralen Server.

Resilient bei Ausfällen. Selbst wenn der zentrale Widget-Storm-Server vorübergehend nicht erreichbar ist, funktionieren alle Widgets, die bereits im CodeVault liegen, ohne Einschränkung weiter.

Rendering-Kontrolle. Sie steuern aktiv, woher der Widget-Code kommt: Im Standard-Modus rendert der wgclient direkt aus dem CodeVault (schnellste Option). Im Live-Modus wird das Widget jedes Mal frisch vom Server abgerufen — nützlich während der Entwicklung, um sofort die neueste Version zu sehen. Im Upload-Modus synchronisieren Sie alle Widgets aus Ihrem lokalen wgbuilds/-Verzeichnis auf den Server.

Autoren-Isolation beim Upload. Die Verzeichnisstruktur im CodeVault ist nach Autoren organisiert: wgbuilds/IhrName/widget.php. Beim Batch-Upload werden ausschließlich Widgets verarbeitet, die Ihrem Autoren-Konto zugeordnet sind. Es ist technisch unmöglich, Widgets eines anderen Autors zu überschreiben — der Server validiert die Zuordnung bei jedem Upload.

Ja. Widgets können eigene Sicherheitsmechanismen direkt einbauen — ohne dass das Hostsystem etwas dafür bereitstellen muss.

Unser wg_demo_todo Widget zeigt das in der Praxis: Daten liegen AES-256-verschlüsselt auf dem Server, der Zugang wird über schlüsselbasierte Authentifizierung mit Brute-Force-Schutz abgesichert, und ein Preflight-System prüft vor der Einrichtung automatisch alle Voraussetzungen. Kein separates Backend, kein Framework, keine Datenbank-Konfiguration. Dieses Widget ist kostenlos und open — es erfüllt unsere Enterprise-Richtlinien und dient als Referenz für den Sicherheitsstandard im Widget-Storm System.

Darüber hinaus arbeiten wir an dedizierten Enterprise-Widgets, die über Sicherheitsrichtlinien hinausgehen und eigenständige architektonische Konzepte in sich tragen — etwa integrierte Geschäftslogik, Workflow-Steuerung oder Datenpipelines als vollständig autarke Komponenten.

Haben Sie eine Frage, die hier nicht beantwortet wird? Schreiben Sie uns gerne an info@widget-storm.de.