Origin-Konfiguration

Der Webclient-Wire validiert jede eingehende postMessage gegenüber einem vertrauenswürdigen Origin, bevor irgendetwas als vertrauenswürdig gilt. Diese Seite deckt beide Vertrauensmodi, die Desktop-App-Origin-Gruppe und die zusätzliche Schutzschicht (Sender-Validierung) ab, die Origin-Prüfungen alleine nicht leisten.

1. Die beiden Vertrauensmodi

expectedOrigin (DashletOptions.expectedOrigin) ist der Origin des Webclient-Hosts, der Nachrichten senden darf — pro Deployment konfiguriert, nie hartkodiert, und niemals "*".

1.1. Strenger Modus (konfigurierter Origin)

Mit einem nutzbaren konfigurierten Wert läuft der Wire streng: der konfigurierte Origin ist der Vertrauensanker ab der allerersten Nachricht; jede empfangene Nachricht wird gegen ihn validiert (Schema
Host + Port müssen übereinstimmen; die file-Origin-Gruppe wird als eine Gruppe gematcht, s. u.). Das Konfigurieren eines Origins deaktiviert das Origin-Lernen — und bricht als Konsequenz die Desktop-App in beiden Richtungen (unten). Verwenden Sie den strengen Modus, wenn das Dashlet von einem einzigen bekannten Webclient-Deployment ausgeliefert wird.

1.2. Lernmodus (kein konfigurierter Origin, das iframe-Standardverhalten)

Ohne konfigurierten Origin und in einem iframe startet der Wire unverankert und lernt den vertrauenswürdigen Origin aus der ersten onInit-Nachricht — Webclient und Desktop-App senden beim Dashlet-Load beide onInit. Regeln:

  • nur ein onInit darf verankern (ein Vor-Anker-onUpdate oder eine Antwort wird ignoriert);

  • der Anker ist der Origin-String wie er ankommt und ist unveränderbar (kein erneutes Ankern);

  • jede spätere Nachricht — onUpdate, Methoden-Antworten — wird gegen den erlernten Origin validiert, genau wie gegen einen konfigurierten.

Ein Dashlet, das nicht in einem iframe läuft (Top-Level-Fenster), lernt niemals: Es degradiert nach Ablauf der Erkennungs-Obergrenze in den Standalone-Zustand (Standalone-Betrieb). So kann eine einzige Dashlet-Definition Webclient im Browser und Desktop-App bedienen, ohne einen pro-Deployment-Origin-Umschalter.

2. Die "null" / file:// Desktop-App-Origin-Gruppe

Der Desktop-App-Host (Electron, intransparenter Origin) präsentiert dem Dashlet den String "null" — die Serialisierung des intransparenten Origins durch die Engine (gemessen auf 12.0.28 / Electron 41; die file://-Handhabung der Commlib ist toter Code aus einer Legacy-Generation). Die Legacy-Serialisierungen file://, file:/// und file bleiben in derselben Gruppe.

Der Matcher behandelt file://, file:///, file und "null" als eine Origin-Gruppe, bidirektional, für die Eingangs-Validierung — und jedes Mitglied wird auf jedem Ausgangs-Post in das Ziel-Token "" überführt. (Gemäß der postMessage-Spec ist "null" nie ein gültiges Ziel-Origin — es wirft in jeder Engine SyntaxError; nur "", "/" und absolute URLs sind gültige Ziel-Tokens. Ein konkreter https-Ziel- Origin wird vom Browser zugestellt, aber stillschweigend von der Desktop-App verworfen — deshalb ist "*" das einzige zuverlässig zustellbare Ziel für einen Dual-Ziel-Post. Der Post geht weiterhin an das einzige Eltern-Fenster, und die Eingangs-Validierung bleibt unverändert.)

Hinweis: Das "null"-Gruppenmitglied deckt auch nicht-file- intransparente Origins ab (z. B. sandboxete iframes oder data:-Frames ohne allow-same-origin). Der strenge Modus mit einem konkreten Origin ist die Kontrolle, wenn ein Deployment solche Sender ausschließen muss.

3. Sender-Validierung

Origin-Validierung allein kann einen Geschwister-Frame des Hosts nicht stoppen: Er teilt den Origin des Hosts, ist aber nicht das Fenster, an das das Dashlet postet. Der Wire prüft daher zusätzlich die Sender-Referenz: eine eingehende postMessage, deren event.source vorhanden ist und ein anderes Fenster als window.parent ist, wird vor jeder Origin-Verarbeitung verworfen — kein Origin-Anker, kein Init, kein Update, keine Antwort-Korrelation. Eine Nachricht ohne Sender-Referenz kann weiterhin akzeptiert werden (minimale Test-Doubles und exotische Engines lassen sie aus); echte Geschwister-Frames tragen immer eine.

4. Install-time-Ablehnungen

"*" wird bei der Installation mit TypeError abgelehnt, ebenso wie jedes expectedOrigin, das weder eine gültige absolute URL noch ein Mitglied der file-Origin-Gruppe ist — ein solcher Wert könnte niemals ein gültiges postMessage-Ziel-Token sein. Die Ablehnung erfolgt zu Install-Zeit, nicht zu Post-Zeit.

installDashletGlobal({
    expectedOrigin: 'https://enaio.example.com', // Webclient-Host-Origin
    timeoutMs: 5000, // Standard-Host-Antwort-Timeout
    pollIntervalMs: 50, // Rich-Client-Bridge-Poll-Intervall
    detectionTimeoutMs: 5000, // Obergrenze, bevor der Standalone-Zustand gemeldet wird
});

5. Die dokumentierte Sicherheits-Abnahme

Im Lernmodus wird der Vertrauensanker zu "dem ersten Host, der uns einbettet". Das ist im enaio-Dashlet-Kontext akzeptabel (eine Dashlet-URI ist keine allgemeine Web-Seite; die einbettende Seite ist definitionsgemäß der Host); strenge Deployments behalten den konfigurierten-Origin-Weg.