Sicherheit und täglicher Betrieb - Jira Cloud
Geltungsbereiche und Vererbung
Die Jira-Konfiguration hat zwei Ebenen: Konto und Projekt. Ein Projekt ohne eigene Zugangsdaten erbt Instanzadresse, E-Mail und Token vom Konto - dieselbe Verbindung bedient jedes Projekt, das keinen Grund hat, an eine andere Instanz zu berichten. Das interne Konto von Dock hat zusätzlich Zugriff auf die Plattformkonfiguration: Das ist der einzige Fall, in dem ein Projekt ohne eigene und ohne Kontokonfiguration auf Einstellungen zurückfällt, die ein Superadmin eingetragen hat. Abonnenten sehen die Plattformkonfiguration nie - dieselbe Grenze wie bei Slack, Mattermost, Discord und Notion.
Wer Zugriff hat
Die Jira-Bildschirme verlangen die Berechtigung zur Projektverwaltung. Wer ein Projekt in DockRay bearbeiten kann, kann auch dessen Jira-Integration verbinden oder trennen - eine eigene Berechtigung nur für Jira gibt es nicht, weil sie zur selben Verantwortung gehört.
Das API-Token und sein Schutz
Das API-Token liegt verschlüsselt in der Datenbank und kehrt nie ins Formular zurück - ein leeres Feld in den Einstellungen bedeutet kein leeres Token, sondern „das bereits gespeicherte behalten". Die Instanzadresse selbst ist auf öffentliche HTTPS-Adressen in der Domain *.atlassian.net beschränkt, und der Jira-Projektschlüssel geht direkt in den Anfragepfad ein, deshalb wird nur seine echte Form akzeptiert:
^[A-Z][A-Z0-9_]*$Ohne diese Regel würde eine Zeichenkette wie ../ als Projektschlüssel die Anfrage aus dem vorgesehenen Jira-API-Endpunkt hinausführen.
Was an Jira geht - und was nie
In die Ticketbeschreibung geht der relevante Ausschnitt des Stacktrace ein - Frames aus dem eigenen Code der Client-Anwendung, oder bei deren Fehlen die Spitze des Stacks. Nie hineingehen dagegen die Werte lokaler Variablen, Anfrage-Header, Benutzerdaten oder die Query-String - die Adresse wird auf den reinen Pfad gekürzt, weil Token und Schlüssel meist in Query-Parametern unterwegs sind. Das ist dieselbe Grenze, die auch für MCP und Notion gilt, denn eine einzige Stelle im Code entscheidet, was aus einem Fehler nach außen geht. „Vorkommen" und „erstes Vorkommen" in der Faktenliste beziehen sich auf einen einzigen Tag - so viel, wie eine Zeile in der Fehlertabelle fasst.
Ein leeres Feld: „löschen" oder „unverändert lassen"
Ob ein leeres Formularfeld einen gespeicherten Wert löscht oder unverändert lässt, entscheidet der Einstellungsbildschirm, nicht das Schreiben in die Datenbank selbst. Das zählt beim Umschalten eines Projekts von eigenen Zugangsdaten auf die Vererbung vom Konto: Das Löschen der Instanzadresse muss auch das alte Token löschen, damit das Projekt wirklich zu vererben beginnt, statt nur so auszusehen, während heimlich ein fremdes Token gespeichert bleibt.
Token rotieren und Teammitglieder, die gehen
Das API-Token gehört dem Atlassian-Konto, das es erzeugt hat, nicht der Person, die technisch das Formular in DockRay ausgefüllt hat. Verliert diese Person den Zugriff auf das Atlassian-Konto oder verlässt sie das Team, muss das Token in den Atlassian-Einstellungen neu erzeugt und in DockRay eingefügt werden - die Integration erkennt das nicht von selbst, denn aus ihrer Sicht funktioniert das Token einfach nicht mehr, sobald die erste Anfrage fehlschlägt. Der Verdacht, dass ein Token abgeflossen ist, genügt, um es sofort auf Atlassian-Seite zu widerrufen, unabhängig davon, wann jemand die Konfiguration im Panel aktualisiert.