Audit-Protokoll-API

Listet die Konfigurationsänderungen des Projekts auf, neueste zuerst: wer was wann und von welcher Oberfläche geändert hat, mit dem Vorher und Nachher auf Feldebene, in jedem Tarif 400 Tage aufbewahrt.

Nach actor (id), actor_kind, source, resource_type und resource_id, action (exakt oder ein Präfix, das auf * endet), field (ein JSON-Pointer-Präfix wie /label) und einem since/until-Zeitfenster filtern; mit cursor blättern. format csv, xlsx oder pdf schreibt das gefilterte Protokoll mit dem Berichts-Renderer als Datei (eine Zeile pro geändertem Feld, älteste zuerst, die letzten 30 Tage, sofern since nichts anderes angibt, Kettenkopf und Aufbewahrungsgrenze in der Datei, damit sie als Anker für audit verify dient).

Geheimnisse (Token, Schlüssel, Passwörter, Webhook- und Quellen-Zugangsdaten) erscheinen als (redacted); jeder andere Wert ist der gespeicherte Wert. Einträge werden von den Diensten in der Transaktion geschrieben, die die Änderung vornimmt; nichts schreibt, aktualisiert oder löscht einen Eintrag.

Erfordert die Projektberechtigung; eine Dashboard-Sitzung liest es als Projektinhaber, Organisationsadministrator oder als Mitarbeiter, der das Projekt mitverfolgt. Das Lesen und Exportieren des Protokolls fällt unter das Audit-Protokoll, das der Enterprise-Plan enthält; ein Projekt, dessen Plan dies nicht enthält, wird mit feature_not_in_plan (402) abgelehnt. In jedem Plan werden die Änderungen aufgezeichnet.

Der Kopf der Audit-Kette des Projekts (seq und hash des letzten verketteten Eintrags), die Aufbewahrungsuntergrenze, ab der die Kette beginnt, und wie viele Einträge noch auf die Verkettung warten. Bewahren Sie einen Kopf als Anker auf und übergeben Sie ihn später an GET /api/audit/verify, um zu belegen, dass davor keine Historie umgeschrieben oder entfernt wurde.

Teil des Audit-Protokolls, das der Enterprise-Plan enthält; ein Projekt, dessen Plan dies nicht enthält, wird mit feature_not_in_plan (402) abgelehnt.

Berechnet die Audit-Hash-Kette über einen Bereich neu und meldet, was falsch ist, falls etwas falsch ist.

Der Hash jedes verketteten Eintrags wird aus seinem gespeicherten Inhalt neu berechnet, jeder Eintrag muss mit dem vorherigen verbunden sein, seq muss ab der Aufbewahrungsgrenze lückenlos sein, und der letzte Eintrag muss der Kettenkopf sein. anchor (SEQ:HASH aus einem früheren Export oder von head) beweist zusätzlich, dass der Eintrag an diesem seq unverändert ist und die Kette nicht darunter gekürzt wurde.

Ein Aufruf prüft höchstens 5000 Einträge; mit from_seq ab next_seq fortsetzen. Teil des Audit-Protokolls, das der Enterprise-Plan enthält; ein Projekt, dessen Plan dies nicht enthält, wird mit feature_not_in_plan (402) abgelehnt.

Ein Audit-Eintrag mit seinen Änderungen auf Feldebene. Teil des Audit-Protokolls, das der Enterprise-Plan enthält; ein Projekt, dessen Plan dies nicht enthält, wird mit feature_not_in_plan (402) abgelehnt.