Frequently Asked Questions

Widget-Storm is a modular widget platform that has been in active operation since 2008. The system lets you manage reusable web components (widgets) centrally and embed them into any website through an encrypted interface.

Each widget consists of three layers — PHP, CSS, and JavaScript — that can be loaded and combined independently. We call this concept the Widget Triple Pattern.

Widget-Storm was developed in 2008. At that time, RIJNDAEL-256 (Rijndael with a 256-bit block size) was a common and defensible choice. The reasons in their historical context:

PHP’s mcrypt extension was the standard route. The cryptography library that dominated PHP at the time — mcrypt — offered MCRYPT_RIJNDAEL_256 as a first-class option right alongside MCRYPT_RIJNDAEL_128. The documentation drew no clear distinction regarding standardization. Choosing MCRYPT_RIJNDAEL_256 simply followed the available API.

OpenSSL integration was not yet standard. openssl_encrypt() with clean AES-256-CBC only gained traction with PHP 5.3 (2009) and did not become the recommended alternative until years later. In 2008, mcrypt was the pragmatic route.

AES-NI did not exist yet. Intel’s hardware acceleration for AES (AES-NI) only reached the market in 2010. In 2008, the performance disadvantage of RIJNDAEL-256 compared to AES was marginal on server hardware — both ran purely in software.

No compliance requirements. For a German web project in 2008, FIPS-140 certification was a non-issue. The GDPR did not yet exist, and PCI-DSS was irrelevant for most projects. Using any encryption at all was already above average.

Bottom line: The decision was in line with the state of the art in 2008 — reasonable and by no means negligent. Since the modernization, Widget-Storm additionally supports AES-256-CBC as a modern encryption standard.

Widget-Storm runs a dual-stack architecture: both encryption methods coexist permanently. A central EncryptionNegotiator automatically detects which version a user is on and routes the communication accordingly.

New users automatically receive v2 (AES-256-CBC). Existing users stay on v1 and can be migrated on request — without any interruption to their running operation.

Yes. Widget-Storm protects communication on several levels:

• Transport encryption: All connections run over HTTPS (TLS). HTTP requests are automatically redirected to HTTPS.
• Payload encryption: Widget data is additionally encrypted at the application level before it is transmitted. Every user has their own key.
• Input validation: All input parameters are validated and sanitized on the server side.
• Rate limiting: Automatic protection against excessive requests.
• Request logging: All API accesses are logged in order to detect abuse early.

The security architecture is continuously reviewed and improved. The RIJNDAEL-256 method is not cryptographically broken — the move to AES-256-CBC is being made for reasons of standard conformance and better modes of operation (CBC with IV instead of ECB), not because of a security vulnerability.

wgclient and wghandler are the two files that connect the Widget-Storm system to your website:

• wgclient.php — The entry point. This file is embedded in your website and requests widgets from the Widget-Storm server via HTTP. The wgclient is personalized and contains your credentials (encrypted).
• wghandler.php — The communication layer. This file handles encryption, decryption, and the local widget cache (CodeVault). It is generated automatically and tailored to your key.

You receive both files after registering in the Widget-Storm Station. The keys are rotated with every download.

The wghandler automatically stores fetched widgets in the CodeVault (wgbuilds/). As a result, every widget is loaded directly from disk on the next call — faster than any network round trip. You can also control whether widgets are rendered locally or fetched live from the server.

Every widget in Widget-Storm consists of three independent layers:

1. PHP — Server-side logic and HTML generation
2. CSS — Styling, including a PHP-in-CSS bridge for dynamic values
3. JavaScript — Client-side interactivity

These three layers are loaded separately through the wgclient. That makes it possible to load only the parts of a widget that are actually needed — for example just the CSS for presentation, without unnecessary JavaScript.

Widgets can also be nested recursively: a widget can embed further widgets via special markers (##wgstart##...##wgend##). This is how complex interfaces are built from simple, reusable building blocks.

The CodeVault is not just a cache — it is the primary delivery system for widgets. On the first fetch, the wghandler stores the decrypted widget code as local files in the wgbuilds/ directory on your web server. From that moment on, the widget is loaded directly from the file system — no network round trip, no latency, no dependency on the central server.

Resilient during outages. Even if the central Widget-Storm server is temporarily unreachable, all widgets already stored in the CodeVault keep working without any restriction.

Rendering control. You actively control where the widget code comes from: in standard mode, the wgclient renders straight from the CodeVault (the fastest option). In live mode, the widget is fetched fresh from the server every time — useful during development to see the latest version immediately. In upload mode, you synchronize all widgets from your local wgbuilds/ directory to the server.

Author isolation on upload. The directory structure in the CodeVault is organized by author: wgbuilds/YourName/widget.php. During a batch upload, only widgets assigned to your author account are processed. It is technically impossible to overwrite another author’s widgets — the server validates the assignment on every upload.

Yes. Widgets can build in their own security mechanisms directly — without the host system having to provide anything for it.

Our wg_demo_todo widget shows this in practice: data is stored AES-256-encrypted on the server, access is secured through key-based authentication with brute-force protection, and a preflight system automatically checks all prerequisites before setup. No separate backend, no framework, no database configuration. This widget is free and open — it meets our enterprise guidelines and serves as a reference for the security standard in the Widget-Storm System.

Beyond that, we are working on dedicated enterprise widgets that go past security guidelines and carry self-contained architectural concepts within them — such as integrated business logic, workflow control, or data pipelines as fully autonomous components.

Do you have a question that isn’t answered here? Feel free to write to us at info@widget-storm.de.