Repository navigation
security
Customer Service Portal · Startseite · Installation · Konfiguration · Betrieb
Die Standard-Module des Portals und deren API-Routen haben keine Anmeldung. Hotline, Teamkontakte, E-Mail-Adressen, Schichten, Alert-Beschreibungen, Status und statische Inhalte sind öffentlich, sobald die betreffenden Plugins aktiviert sind. Inhalte und Kontakte deshalb vor einem produktiven Deployment auf ihre Eignung zur Veröffentlichung prüfen.
CSP_ALLOWED_ORIGINS begrenzt Browser-CORS-Zugriffe und ist keine Authentifizierung. Auch vCards und Team-Avatare sind öffentlich; die API beschränkt deren IDs auf das konfigurierte Team.
Die Vite-Konfiguration lädt Umgebungswerte, aber publicConfig exportiert nur explizit ausgewählte öffentliche Felder. Provider-Schlüssel gehören in Runtime-Secrets des API-Hosts. Sie dürfen nicht in VITE_*, öffentliche GitHub-Variablen, Kundeninhalte oder Bild-/Frontend-Artefakte aufgenommen werden.
Öffentliche URL-Konfiguration akzeptiert HTTP(S) oder erlaubte absolute URL-Pfade und lehnt eingebettete Zugangsdaten ab. Inhaltstexte unterstützen Markdown ohne HTML-Ausführung. Kunden-.env-Dateien bleiben außerhalb von Git und Docker-Images.
SIGNL4 wird lesend verwendet: Team und Bilder über GET, Schichten und Alerts über lesende POST-Abfragen. Das Portal bestätigt keine Signls und verändert keine Schichten. Kuma verwendet veröffentlichte Statusseiten-Endpunkte.
Der Chat lädt Wissensquellen ausschließlich aus der eigenen Instanz. Ausgewählte statische und Live-Daten sowie der übergebene Gesprächsverlauf werden an OpenAI, Azure OpenAI oder Ollama übertragen. OpenAI/Azure erhalten store: false; daraus folgt keine allgemeine Zusicherung über die Aufbewahrung beim Provider. Dessen Betrieb und Datenverarbeitung separat passend zur Kundeninstanz konfigurieren.
Quellen und Benutzertexte werden als Daten behandelt. Die Systemanweisung beschränkt Antworten auf den Quellkontext, kennzeichnet fehlende/veraltete Daten und verbietet behauptete Aktionen. Der Chat selbst hat keine ausführenden Tools und keine Ticket-/Alert-Mutationen. KI-Antworten können dennoch fehlerhaft sein; für dringende Störungen den direkten Kontakt verwenden.
Mit WebMCP rufen Agenten im Browser Tools des Portals auf (WebMCP). Die Tools sind lesend, nutzen nur die öffentlichen Routen und die öffentliche Konfiguration und enthalten keine Schlüssel. Einzige Ausnahme in der Wirkung ist chat_ask: Es ändert keine Daten, verbraucht aber Chat-Kontingent und Limits und sendet den übergebenen Verlauf wie der Chat an den konfigurierten Provider.
Standardmäßig ist WebMCP an. Teamnamen, E-Mail-Adressen und Telefonnummern sind ohnehin öffentlich, werden dadurch aber für beliebige Agenten im Browser maschinenlesbar. public.webmcp: false beziehungsweise CSP_WEBMCP=false schaltet die Registrierung ab. Texte aus Alerts, Inhalten und Chat-Antworten stammen aus externen Quellen und sind für den Agenten Daten, keine Anweisungen; entsprechende Ergebnisse tragen ein notice. Veraltete Daten werden nie als bestätigt ausgegeben. Es gibt keine Tools, die Tickets anlegen, Alerts bestätigen oder Schichten ändern. Die Schnittstelle ist ein Browser-Vorschauangebot; ohne sie bleibt das Portal unverändert nutzbar.
Live-Caches und Chat-Limits liegen im Speicher des API-Prozesses. Ohne Support-Plugin speichert das Portal Gesprächsverläufe weder in einer Datenbank noch im Browser-Storage. Das Frontend hält den aktuellen Verlauf im Arbeitsspeicher und speichert lediglich die Designpräferenz unter csp-theme. Statische PWA-Inhalte/Assets werden gecacht; API-/Chat-Antworten nicht.
TLS am Host/Reverse-Proxy bereitstellen. CSP_TRUST_PROXY bleibt standardmäßig aus; nur für einen vertrauenswürdigen Proxy einschalten. Chat besitzt IP- und Parallelitätslimits je Prozess. Bei mehreren API-Replikas ist zusätzlich eine gemeinsame Limitierung am Gateway erforderlich. Der API-Body ist auf 64 KiB begrenzt; Providerabfragen und Streams besitzen Zeitlimits.
Weiter: Konfiguration, API, Betrieb.
Das optionale Teams-Plugin verlangt verifizierte Entra-API-Tokens und trennt Gespräche anhand Tenant-/Nutzer-ID. PostgreSQL speichert Verlauf und Übernahme, standardmäßig 30 Tage ohne Aktivität. MSAL-Anmeldeinformationen liegen im Session-Storage; die PWA speichert API-Inhalte nicht. Teams erhält eine eigene Verlaufskopie; deren Aufbewahrung ist unabhängig. Supportrechte werden über Graph bei jeder Aktion geprüft. RSC gilt teamweit, die Verarbeitung wird auf den konfigurierten Channel begrenzt. Vollständiger Datenfluss und Grenzen: Teams-Support.
Slack nutzt dieselbe Entra-Eigentümerprüfung und PostgreSQL-Aufbewahrung wie Teams. Supportrechte erfordern explizit erlaubte Slack-Nutzer-IDs, aktuelle Channel-Mitgliedschaft und einen aktiven menschlichen Nutzer des konfigurierten Workspaces. Slack-Request-Signaturen schützen beide Callback-Routen; App-, Workspace-, Channel- und Thread-Zuordnung werden geprüft. Die Allowlist wird nicht aus Namen oder E-Mail-Adressen abgeleitet. Slack-Scope-Rechte und Slack-Verlaufskopien sind weiter als der lokale Gesprächsbestand; den Bot nur in geeignete Channels einladen. Datenfluss und Installation.
Telegram verwendet die gemeinsame Gesprächs-Eigentümerprüfung mit Entra oder signierten anonymen Besuchersitzungen. Webhooks erfordern das konfigurierte Secret im Header; fehlende oder falsche Secrets werden vor Body-Verarbeitung abgewiesen. Telegram-Supportrechte erfordern numerische Nutzer-IDs aus einer expliziten Allowlist und aktuelle Gruppenmitgliedschaft; Bot-, weitergeleitete und anonyme Gruppen-Nachrichten werden ignoriert. Button-Aktionen müssen zur gespeicherten Bot-Karte und zum Gesprächs-Thema passen. Eine dedizierte private Forum-Gruppe begrenzt die Leserschaft, der Bot benötigt Administratorrechte zum Verwalten von Themen. Telegram-Verlaufskopien werden nicht durch die PostgreSQL-Aufbewahrung entfernt. Bot-Tokens stehen technisch im Telegram-API-URL: Fehler werden ohne diesen URL neu erzeugt; Reverse-Proxy-/HTTP-Tracing darf Secrets ebenfalls nicht protokollieren. Einrichtung und Grenzen.
Customer Service Portal · Quellcode · Releases · Fehler melden · MIT-Lizenz
Diese Dokumentation stammt aus docs/ des im Wiki-Abgleich verwendeten Release-Tags. Änderungen bitte im Produktrepo vornehmen; verwaltete Wiki-Seiten werden beim nächsten Abgleich überschrieben.
Customer Service Portal