Für die IT
Diese Seite fasst zusammen, was eure IT für die Freigabe des Widget Builders braucht. Sie beschreibt den heutigen Stand der App. Wie du den Widget Builder einrichtest, steht unter Registrieren und Anmelden.
Anmeldung
| Weg | Was ihr einrichtet |
|---|---|
| Mit Staffbase anmelden (Standard) | Eure Staffbase-Instanz muss registriert sein. Bei der Registrierung legt eine Person mit der Staffbase-Rolle Admin im Staffbase Studio einen OAuth-Client an. Anmelden dürfen Personen, deren Staffbase-Rolle die Mindestrolle erreicht (ohne Änderung: Admin), und Mitglieder einer freigegebenen Staffbase-Gruppe. |
| Mit Microsoft Entra ID, Google, Okta oder einem OIDC-Anbieter | Optional. Eure Administration registriert bei dem Anbieter eine Anwendung und trägt Anbieter und Client-ID unter Einstellungen → Technik / IT → Authentifizierung ein. Du kannst die Anmeldung auf E-Mail-Domains beschränken. Wer sich über einen solchen Anbieter anmeldet, bekommt nur Zugriff, wenn seine Adresse unter Admin-E-Mails (optional) steht. Anleitung: Login-Provider hinzufügen. |
| Mit Microsoft über die Anmelde-App von JASP | Nur wenn die Installation sie eingeschaltet hat. Keine eigene App-Registrierung. Der Widget Builder sucht über die Mandanten-ID des Microsoft-Tokens die Mandanten, die einen Microsoft-Anbieter mit dieser Mandanten-ID eingerichtet haben. |
| Per E-Mail-Code anmelden | Nichts. Nur wenn die Installation sie eingerichtet hat. Der sechsstellige Code geht an die Kontakt-E-Mail-Adresse des Mandanten, gilt 10 Minuten und wird nach 5 Fehlversuchen abgelehnt. |
Nach der Anmeldung mit E-Mail-Code gilt die Sitzung 8 Stunden. Die Sitzungsdauer bei Staffbase bestimmt Staffbase.
Leser der Widgets melden sich im Standardmodus signed über Staffbase an; der Widget Builder prüft das Token von Staffbase. Ein Administrator kann den Modus unverified einschalten: Dann laden Widgets anonym, und native Widgets können eine nicht überprüfbare Identität aus dem Staffbase-Kontext verwenden. Behandle diese Angaben als fälschbar. Details: Authentifizierungsmodi.
Rechte in Staffbase
Mit der Anmeldung der Person (Staffbase-Token der Person, nicht der Organisation) liest der Widget Builder:
- Rolle und Gruppen der Person (
GET /api/users/{id}), um zu entscheiden, ob sie sich anmelden darf, - die öffentliche E-Mail-Adresse der Person, falls das Token keine enthält,
- Name und Logo der Instanz (
GET /api/branch).
Bei der Registrierung und bei Widgets neu registrieren legt der Widget Builder mit der Staffbase-Anmeldung der Person die Widget-Registrierung der Instanz an und ersetzt sie (POST und DELETE auf /branch/widgets).
Optional: Staffbase-API-Token. Eure Verwaltung kann einen Staffbase-API-Token unter Einstellungen → Technik / IT hinterlegen; wie ihr ihn in Staffbase anlegt, steht unter Staffbase-API-Token. Damit
- registriert der Widget Builder Widgets neu, wenn eine Änderung nicht aus eurem Browser kommt (MCP, KI-Assistent, Import),
- sucht er in Auswahlfeldern nach Nutzern, Gruppen, Kanälen, Seiten und Spaces.
Der Widget Builder prüft den Token beim Speichern gegen eure Instanz (GET /api/branch) und speichert ihn verschlüsselt. Die Schalter unter Verwendung sind nach dem Speichern eingeschaltet. Der Proxy für API-Verbindungen verwendet diesen Token nicht. Wechselt das Konto zu einer anderen Staffbase-Instanz, löscht der Widget Builder den Token. Ein Protokoll zeigt 90 Tage lang jede Registrierung und jede Änderung am Token.
Rechte in Microsoft 365
Der Widget Builder fordert in eurem Microsoft 365 keine Anwendungsrechte an. Im Code des Widget Builders gibt es keinen Aufruf von Microsoft Graph.
Anmeldung mit eigener App. Die Anwendung registriert ihr selbst in eurem Verzeichnis. Der Widget Builder fragt die Scopes an, die ihr in den Einstellungen eintragt; der Standard ist openid profile email (delegiert, im Namen der angemeldeten Person). Welche Rechte die App sonst hat, legt ihr in eurer Registrierung fest.
Anmeldung über die Anmelde-App von JASP (nur wenn eingeschaltet):
| Recht | Art | Wofür |
|---|---|---|
openid | delegiert | Anmeldung der Person |
email | delegiert | E-Mail-Adresse, um Mandanten mit erlaubter Domain zu finden |
SharePoint-Webpart. Das Paket (.sppkg) fordert genau eine Berechtigung an:
| Ressource | Recht | Art | Wofür |
|---|---|---|---|
Widget Builder SharePoint | user_impersonation | delegiert | Das Webpart meldet sich im Namen der angemeldeten Person beim Widget Builder an. |
Wo ihr die Berechtigung genehmigt, steht unter Widgets auf SharePoint. Den Mandanten verbindet eine Person mit der Staffbase-Rolle Admin im Widget Builder, nachdem das Webpart darauf hingewiesen hat. Dabei speichert der Widget Builder die Microsoft-Mandanten-ID, die Kennung der App, den Anzeigenamen, die erlaubten SharePoint-Adressen, den Zeitpunkt des letzten Zugriffs und die Version des Webparts.
Daten
Der Widget Builder speichert Daten, die ihr selbst anlegt, und Daten, die bei Anmeldung und Betrieb anfallen. Was bei einem Abruf über den Proxy durchläuft, speichert er nur im Cache (siehe unten). Fristen mit dem Zusatz „Standardwert“ können in einer Installation anders eingestellt sein; die übrigen stehen fest im Code.
| Was | Wo | Wie lange |
|---|---|---|
| Mandant: Name, Staffbase-Adresse, Kontakt-E-Mail-Adresse, Sprache | Datenbank der App | bis JASP den Mandanten löscht |
| Eure Inhalte: Widgets, API-Verbindungen, Datentabellen mit Zeilen, Freigaben, Anmeldeanbieter | Datenbank der App | bis ihr sie löscht oder JASP den Mandanten löscht |
| Zugangsdaten: Header und Body der API-Verbindungen, Staffbase-API-Token, Client-Secret eines Anmeldeanbieters | Datenbank der App, mit AES-256-GCM verschlüsselt | wie die Inhalte; der Token, bis ihr ihn entfernt |
| MCP-Token: Name, Name der erstellenden Person, die ersten 12 Zeichen; der Token selbst nur als SHA-256-Hash | Datenbank der App | bis JASP den Mandanten löscht; der Token selbst gilt 30 bis 365 Tage (Standard 90), widerrufene und abgelaufene Token bleiben gesperrt gespeichert |
| Einmal-Codes für die Anmeldung per E-Mail: Hash des Codes, E-Mail-Adresse, IP-Adresse, Browserkennung | Datenbank der App | gültig 10 Minuten; gelöscht nach Ablauf oder Einlösung, frühestens 15 Minuten nach dem Anlegen (Aufräumlauf alle 15 Minuten) |
Anmeldungen über zusätzliche Anbieter: Kennung (sub), E-Mail-Adresse, Name, Rolle, Zeitpunkte, Anzahl | Datenbank der App | bis der Anbieter oder der Mandant gelöscht wird |
| KI-Verläufe (nur wenn die KI eingeschaltet ist) | Datenbank der App | bis die Person die Unterhaltung löscht oder JASP den Mandanten löscht |
| Nutzungsereignisse der Widgets: Nutzerkennung, Seite, Land und Region (aus der IP-Adresse, die IP-Adresse selbst nicht) | Ereignis-Datenbank | 180 Tage (Standardwert) |
| Verlauf der Anmeldungen und technischen Vorgänge: Nutzerkennung | Ereignis-Datenbank | 30 Tage (Standardwert) |
| Änderungsprotokoll: Nutzerkennung, IP-Adresse, Browserkennung, Werte vor und nach der Änderung | Ereignis-Datenbank | 180 Tage (Standardwert) |
| Aktive Sitzungen: Nutzerkennung, IP-Adresse, Browserkennung | Ereignis-Datenbank | 60 Tage nach der letzten Aktivität |
| Tageswerte der Statistik | Ereignis-Datenbank | 365 Tage, Aufräumlauf einmal pro Woche |
| Versendete Mails (Willkommens- und Rundmails): Empfänger, Betreff, Text | Datenbank der App | 365 Tage (Standardwert), danach ersetzt ein täglicher Lauf die persönlichen Felder durch leere Werte |
| Mail-Protokoll: jede versendete Mail (Anmeldecodes, Willkommens-, Rund- und Testmails) mit Empfänger, Betreff und Text; Codes und Token darin unkenntlich | Datenbank der App | 30 Tage, Aufräumlauf jede Stunde |
| Aufrufe über den Proxy: Antworten der angebundenen Dienste, nur wenn für die API der Cache eingeschaltet ist (Standard: aus) | Arbeitsspeicher der App | für die eingestellte Cache-Dauer; enthält die Anfrage etwas Persönliches, gibt es eine Kopie je Betrachter |
Eine einzelne Person löschen. Eine Funktion, die die Daten einer einzelnen Person auf einmal exportiert, löscht oder ersetzt, gibt es im Widget Builder nicht. Die Ereignisse der Person laufen nach ihren Fristen ab.
Einen ganzen Mandanten löschen. Das erledigt JASP in der Verwaltung des Widget Builders. Der Widget Builder kündigt zuerst das Abo und löscht dann in einem Schritt die Widgets, die MCP-Token, die Berechtigungsgruppen, die aktivierten Standard-Widgets, den Staffbase-Token samt Protokoll, die API-Verbindungen, die Datentabellen mit Zeilen und Freigaben, die Anmeldeanbieter und Einmal-Codes, die Plugin- und SharePoint-Einrichtung, die KI-Verläufe und die gespeicherten Mails an den Mandanten, zuletzt den Mandanten selbst. Im Mail-Protokoll löscht er danach die Kontakt-E-Mail-Adresse des Mandanten. Das Löschen steht im Änderungsprotokoll. Nutzungsereignisse, der Verlauf der technischen Vorgänge, das Änderungsprotokoll, die Sitzungen und die Tageswerte des Mandanten bleiben bis zum Ablauf ihrer Fristen (siehe Tabelle) in der Ereignis-Datenbank.
Betrieb
- Die Cloud-Version läuft auf Servern, die JASP bei netcup betreibt. Produktion und Test laufen auf getrennten Servern. Die Adresse der Produktion ist
https://app.widgetbuilder.de. - Aufrufe der App laufen über Cloudflare; JASP erreicht die Server für Updates über einen Tunnel von Cloudflare.
- Alle Mandanten teilen sich eine Datenbank (SQLite). Jede Zeile trägt die Kennung ihres Mandanten, und die App prüft bei Zugriffen, dass die Kennung des Datensatzes zu der des angemeldeten Mandanten passt.
- Verschlüsselt gespeichert sind die Zugangsdaten aus der Tabelle oben (AES-256-GCM). MCP-Token und Einmal-Codes liegen nur als Hash in der Datenbank.
- Die App protokolliert im JSON-Format. Zugangs-Header (Authorization, Cookie, Staffbase-Tokens, Referer) und Token in Adressen werden vor dem Schreiben unkenntlich gemacht.
- Fehlerberichte gehen an GlitchTip. Der Widget Builder schickt keine Standard-Personendaten (IP-Adresse, Cookies, Header) mit und macht Berichte vor dem Senden unkenntlich.
- Wenn die Installation es eingeschaltet hat, lädt die Oberfläche des Builders ein Zählskript von Umami (
insights.jasp.eu).
Dienste Dritter
| Anbieter | Wofür | Welche Daten |
|---|---|---|
| Cloudflare | Weg zu den Servern | Aufrufe der App |
| Staffbase, eure Instanz | Anmeldung, Rolle und Gruppen, Widget-Registrierung, optional Suche | siehe „Rechte in Staffbase“ |
| Microsoft Entra ID | Anmeldung über Microsoft; Anmeldung des SharePoint-Webparts | siehe „Rechte in Microsoft 365“ |
| Microsoft Azure Communication Services | Mails: Anmeldecodes, Abo- und Willkommensmails | E-Mail-Adresse, Inhalt der Mail |
JASP Billing (billing.jasp.eu) | Abo, Bezahlung, Rechnungen | Name der Organisation, Kontakt-E-Mail-Adresse |
| KI-Dienst (nur wenn für den Mandanten eingeschaltet) | KI-Assistent im Editor | Unterhaltung und Ergebnisse der Werkzeuge |
| Von JASP konfigurierter Webhook | Meldung einer neuen Registrierung | Name, Kontakt-E-Mail-Adresse, Staffbase-Adresse und -Kennung, Zeitpunkt |
| Die Dienste, die ihr als API anbindet | Daten für eure Widgets | was ihr in der API-Verbindung festlegt, auch Token der Person, wenn ihr sie einbaut |
Den Vertrag zur Auftragsverarbeitung und die Liste aller Dienstleister findet ihr auf der Website von JASP: Vertrag zur Auftragsverarbeitung (öffnet in neuem Tab) und Unterauftragsverarbeiter (öffnet in neuem Tab).