Kritische Aktionen stoppen bevor sie ausgeführt werden.

Nein. Laravel-Richtlinien (Policies) bleiben für die Autorisierung zuständig. ActionGuard prüft dagegen fachliche Voraussetzungen und Invarianten vor kritischen Aktionen. Beide Mechanismen ergänzen sich, ersetzen sich aber nicht.

Nein. Die Laravel-Validierung prüft Eingabedaten. ActionGuard entscheidet, ob eine konkrete Aktion unter dem aktuellen fachlichen Zustand ausgeführt werden darf. Validierung, Richtlinien (Policies), Datenbank-Constraints und ActionGuard bilden unterschiedliche Schutzebenen.

Ist fail_closed=true aktiviert, blockiert ActionGuard eine Operation auch dann, wenn während eines Checks ein technischer Fehler auftritt. Ein unbekannter oder fehlerhafter Zustand führt damit nicht automatisch zur Ausführung einer kritischen Aktion.

Prüfungen werden mehrfach ausgewertet: beim Öffnen beziehungsweise Vorbereiten der Aktion und erneut unmittelbar vor der tatsächlichen Ausführung. Maßgeblich ist die letzte Auswertung.

ActionGuard stellt mehrere Standardprüfungen zur Verfügung: RequiredFieldCheck, NotEmptyCheck, RelationshipCheck, MediaCheck, ConditionCheck und CallbackCheck.

Ja. Eigene Prüfungen implementieren den ActionGuardCheckContract und liefern ein CheckResult zurück. Klassen können über den Laravel-Service-Container aufgelöst und damit auch mit eigenen Diensten und Domänenkomponenten kombiniert werden.

PASS erlaubt die weitere Verarbeitung. Ein erforderlicher FAIL blockiert die Operation. Ein optionaler FAIL kann als Warnung behandelt werden. ERROR blockiert bei aktiviertem Fail-Closed-Verhalten ebenfalls die Ausführung.

Der Schutz von Modellregeln integriert sich in den Eloquent-Lebenszyklus saving. Dadurch können definierte Modellregeln bei save() und update() erneut geprüft werden – unabhängig davon, ob der Schreibvorgang ursprünglich über eine Filament-Aktion ausgelöst wurde.

Nein. Direkte Massenänderungen wie Model::where(...)->update(...) lösen keine Eloquent-Modellereignisse aus und umgehen damit den Schutz von Modellregeln.

Kritische Massen-Schreibpfade sollten deshalb über geladene Models, kontrollierte Anwendungsdienste oder Datenbank-Constraints implementiert werden.

Nein. Datenbank-Constraints bleiben für technische Datenintegrität wichtig. ActionGuard arbeitet auf einer höheren fachlichen Ebene und schützt Geschäftsaktionen und Modellzustände innerhalb der Anwendung.

Ja. Allerdings ist der die kontrollierte Ausnahme standardmäßig deaktiviert: allow_bypass=false.

Kontrollierte Ausnahmen sind für bewusst gesteuerte Sonderfälle gedacht und sollten nur aktiviert werden, wenn deren Einsatz organisatorisch und technisch nachvollziehbar ist.

Bei aktivierter Protokollierung kann eine kontrollierte Ausnahme als strukturiertes Ereignis erfasst werden. Dafür existiert unter anderem: filament-actionguard.bypass_used.

Aktuell stehen drei zentrale Ereignistypen zur Verfügung:

• filament-actionguard.action_evaluated
• filament-actionguard.invariant_blocked
• filament-actionguard.bypass_used

ActionGuard ist bewusst datensparsam entwickelt. Datensatz-IDs, Akteur-IDs, Prüfmeldungen und beliebige Modellattribute werden nicht automatisch protokolliert.

Auch Modellklassen und Statuswerte sind standardmäßig deaktiviert und benötigen separate explizite Freigaben.

Nein. ActionGuard erzeugt strukturierte Protokollereignisse, stellt aber kein unveränderbares oder revisionssicheres Archiv bereit.

Anwendungen mit entsprechenden Anforderungen an Nachweisführung und Regelkonformität sollten den verwendeten Protokollkanal beispielsweise an ein zentrales SIEM- oder Nachweissystem anbinden.

Eine pauschale Aussage wäre technisch und rechtlich nicht korrekt. ActionGuard ist datensparsam entwickelt.

Die DSGVO-Konformität der Gesamtanwendung hängt unter anderem von Rechtsgrundlage, Berechtigungssystem, Hosting, Protokollierung, Aufbewahrung, Löschkonzepten und organisatorischen Maßnahmen des Betreibers ab.

Das Plugin selbst überträgt keine Datensatzdaten an externe Dienste.

Externe Übertragungen können jedoch durch die Hauptanwendung oder die konfigurierte Protokollierungsinfrastruktur entstehen und müssen dort separat bewertet werden.

Standardmäßig erlaubt ActionGuard lokale absolute Pfade sowie HTTPS-URLs. Unsichere HTTP-URLs sind blockiert.

HTTP kann nur über eine explizite Konfiguration für kontrollierte Sonderfälle freigeschaltet werden.

Nein. Technische Ausnahmen aus Prüfungen werden nicht ungefiltert im Benutzerinterface angezeigt.

Die Benutzeroberfläche erhält eine generische Fehlermeldung beziehungsweise Korrelationsinformation, während technische Details serverseitig behandelt werden können.

Ja. ActionGuard ist als 100% eigenständiges Open-Source-Plugin unter der MIT-Lizenz konzipiert und benötigt keine externen Kernsysteme oder proprietären Erweiterungen.

Für Fragen, Feedback oder individuelle Erweiterungen können Sie direkt Kontakt mit dem Entwickler Aleksey Krivonos über sein LinkedIn-Profil aufnehmen.

Die aktuelle Spezifikation definiert folgende Zielplattform:

• PHP 8.3–8.5
• Laravel 11.28–13.x
• Filament 5.x

Der dokumentierte Freigabekandidaten-Stand wurde unter anderem mit folgenden Qualitätsprüfungen geprüft:

• 133 Pest-Tests
• 315 Prüfassertionen
• PHPStan-Stufe 8
• Laravel Pint
• Composer-Metadatenprüfung
• Abhängigkeitsprüfung

Ja. Die CI berücksichtigt stabile Abhängigkeiten, niedrigste kompatible Versionen sowie Installationen mit gesperrten Versionen.

Dadurch wird nicht ausschließlich gegen aktuelle Abhängigkeitsversionen getestet, sondern auch die deklarierte Kompatibilitätsuntergrenze überprüft.

Ja. Da ActionGuard Richtlinien (Policies), Validierung und Datenbank-Constraints ergänzt statt ersetzt, kann die Einführung inkrementell erfolgen.

Ein sinnvoller Einstieg sind besonders kritische Prozesse wie Löschen, Freigaben, Statuswechsel, Exporte oder irreversible Geschäftsaktionen.

Besonders geeignet sind Aktionen, deren Ausführung von mehreren fachlichen Voraussetzungen abhängt – beispielsweise Löschen, Statusänderungen, Freigaben, Publikationen, Exporte oder irreversible Prozessschritte.