Bewährte Vorgehensweisen für Rainbow Extensions

Sie können diesen Artikel als Checkliste verwenden, bevor Sie ein benutzerdefiniertes Manifest erstellen, testen oder in der Produktion bereitstellen. Nutzen Sie ihn, um Ihr Manifest wartbar, sicher und leichter zu beheben zu halten.

Erstellung

• Beginnen Sie mit einer von Rainbow Desktop exportierten Vorlage oder einem bereits validierten Manifest.
• Entfernen Sie ungenutzte Erweiterungspunkte vor der Bereitstellung in der Produktionsumgebung.
• Behalten Sie die Version „2“ und den jsonType „Rainbow-custo-manifest“ bei.
• Definieren Sie nicht mehr als 3 Aktionen für denselben Erweiterungspunkt.
• Vermeiden Sie fest codierte Pfade vom Entwicklerrechner. Verwenden Sie ${custo.path} und packen Sie die Ressourcen in ein ZIP-Archiv.

Sicherheit

• Deklarieren Sie vor der Bereitstellung alle REST- und iframe-Ursprünge in den Custo-Manifest-Domänen.
• Bevorzugen Sie HTTPS-Endpunkte mit stabilen DNS-Namen.
• Konfigurieren Sie für REST-APIs CORS explizit und testen Sie die Preflight-Anfragen des Browsers.
• Überprüfen Sie bei Servern in lokalen/privaten Netzwerken das Verhalten von Rainbow Web anhand der Regeln für den lokalen Netzwerkzugriff.
• Betten Sie geheime Daten nicht direkt in ein Manifest ein, das an Ihre Benutzer verteilt wird. Bevorzugen Sie nach Möglichkeit serverseitige Token oder kurzlebige Anmeldedaten.

Variablen

• Verwenden Sie die engste für den Erweiterungspunkt verfügbare Variable.
• Testen Sie Variablen mit realistischen Aufrufen, Kontakten und Bubbles; manche Werte sind leer, wenn der Kontext fehlt.
• Verwenden Sie reguläre Ausdrücke nur für einfache Transformationen. Komplexe Transformationen sollten serverseitig erfolgen.
• Überprüfen Sie die Formate von Telefonnummern in Cloud PBX-, OmniPCX Enterprise- und OXO Connect-Bereitstellungen.

Adaptive Cards

• Halten Sie die Karten kurz und konzentrieren Sie sich auf die Benutzeraktion.
• Testen Sie die Darstellung auf Rainbow Web und Desktop.
• Vermeiden Sie nicht unterstützte Elemente von Adaptive Cards 1.6+, es sei denn, die Zielversion des Rainbow-Clients unterstützt diese ausdrücklich.
• Stellen Sie bei „Action.Submit“ sicher, dass der Ziel-Endpunkt idempotent ist, und geben Sie dem Nutzer ein eindeutiges Feedback.

Validierung vor der Produktion

• Überprüfen Sie die JSON-Syntax.
• Testen Sie den lokalen Import vor der zentralen Bereitstellung.
• Testen Sie das Manifest im Web und auf dem Desktop, wenn beide Clients als Zielplattformen vorgesehen sind.
• Überprüfen Sie alle vertrauenswürdigen Domänen, CORS-Header und iframe-Header.
• Stellen Sie das Manifest zunächst für einen Pilotnutzer oder ein Pilotprofil bereit, bevor Sie es in größerem Umfang einführen.
• Bewahren Sie eine Kopie des vorherigen Manifests auf, damit ein Rollback sofort möglich ist.