Versuch mal, das in einem Compliance-Review zu beantworten: Warum genau hat deine Anwendung Account 4127 im März erlaubt, diese Rechnung freizugeben? Nicht ob, das klärt das Access-Log. Warum. Welche Regel gegriffen hat, welche Rolle den Ausschlag gab, was der Voter in dem Moment tatsächlich gesehen hat. Für die meisten Symfony-Apps war die ehrliche Antwort bisher ein Boolean und ein Schulterzucken, denn ein Voter liefert true oder false und nimmt seine Begründung mit ins Grab. Diese Ära geht zu Ende, und ich finde, wir sollten die Workarounds gleich mit beerdigen.

security:
    access_decision_manager:
        strategy_service: App\Security\WeightedComplianceStrategy

Du weißt, welchen Workaround ich meine, weil du ihn vermutlich selbst geschrieben hast. Ein $logger->info()-Aufruf in jedem Voter, jeder ein bisschen anders formatiert, keiner verlässlich mit der Entscheidung verknüpft, die der Access Manager am Ende trifft. Audit-String-Formatierung mitten in der Autorisierungslogik, also ungefähr am letzten Ort, an den sie gehört. Symfony 7.3, ausgeliefert im Mai 2025 mit PR #59771 von Nicolas Grekas, hat diese Krücke überflüssig gemacht: VoterInterface::vote() und Voter::voteOnAttribute() bekamen ein nullable Vote-Argument, und ein einzelnes $vote?->addReason('why I said no') legt die Erklärung genau dorthin, wo die Entscheidung fällt. Diese Reasons tauchen im Profiler auf, in der Log-Ausgabe und auf Exception-Seiten, und die Basisklasse Voter schreibt das Ergebnis granted, denied oder abstain von selbst ins Vote. Deine Subklasse erklärt sich einfach selbst.

Reasons sind Prosa für Menschen. Der Teil, der ändert, wie ich Autorisierung entwerfe, kam im November 2025 mit 7.4 und 8.0: extraData, beigesteuert von Roman Joly, auf GitHub Eltharin, in PR #60085. Ein Vote kann jetzt ein Array transportieren, oder ein ganzes Objekt, wenn du darauf bestehst, mit maschinenlesbarer Payload. Ein Score, eine Policy-Referenz, ein Risk-Flag. Kombinier das mit AccessDecisionStrategyInterface und der strategy_service-Config, die es beide schon lange vor 7.4 gab, und plötzlich hat eine eigene Strategy in decide() etwas Lesenswertes vor sich. Symfonys Voting war immer strikt egalitär, jeder Voter zählt gleich viel, was in dem Moment schlecht passt, in dem die Freigabe eines CFO bei einer großen Rechnung mehr wiegen soll als die eines Praktikanten. Jetzt kann ein Voter sein Gewicht mitschicken, und eine Strategy kann pro Request einen einzigen strukturierten Audit-Eintrag schreiben, der jedes abgegebene Vote abdeckt. Kommt im nächsten Sprint ein zehnter Voter dazu, bewegt sich das Audit-Format keinen Millimeter.

Die Template-Ebene hat auch aufgeholt. Florent Destremaus PR #61379 stellt access_decision() und access_decision_for_user() neben die rein booleschen is_granted()-Funktionen. Beide geben ein AccessDecision-Objekt zurück, das den Strategy-Namen, isGranted, das votes-Array und eine getMessage()-Methode offenlegt, und die for_user-Variante prüft einen bestimmten Account statt des aktuellen Tokens, genau das, was ein Admin-Screen braucht, der die Berechtigungen von jemand anderem vorab anzeigen soll. Eine Falle verdient eine rote Markierung: getMessage() setzt nur die Reasons der Votes zusammen, die mit dem finalen Ergebnis übereinstimmen. Ein Voter, der widersprochen oder sich enthalten hat, verschwindet aus dieser Message, egal wie sorgfältig er sich erklärt hat. Für das vollständige Bild öffnest du weiterhin den Profiler.

Jetzt das Zugeständnis, denn es ist ein echtes. Die meisten Anwendungen sind mit der affirmative-Strategy und einem schlichten Ja oder Nein bestens bedient, und keine der eingebauten Strategien, affirmative, consensus, unanimous oder priority, liest extraData überhaupt. Schreib Scores in deine Votes, während affirmative läuft, und du hast wunderschön strukturierte tote Daten produziert, die nichts ändern. Es gibt ein reales Risiko, eine kleine Rules Engine zu bauen, nach der niemand gefragt hat, mit Gewichten, die im Code-Review niemand rechtfertigen kann. Und ein Reason-String, geschrieben für einen internen Profiler-Tab, kann eine Geschäfts-Policy beim Namen nennen, die du ganz sicher nicht auf einer kundenseitigen Seite gerendert sehen willst. decision.message ohne Nachdenken über das zweite Publikum direkt in Twig zu leiten ist eine neue Bug-Klasse, frisch verfügbar.

Ich lande trotzdem klar auf der Seite der Adoption des Vote-Objekts, und das Argument ist nicht Compliance, sondern Debugging am Dienstagnachmittag. Sieben Voter registriert, ein Request liefert 403, und vor 7.3 durftest du sie mit Dumps oder Breakpoints halbieren, während eine Kollegin wartete. addReason() kostet eine Zeile pro Branch und macht aus dieser Stunde einen Blick in den Profiler. Meine Go schreibenden Kollegen bauen so einen Decision-Trace von Hand aus Context-Values und Middleware zusammen und halten das für normal. Wir bekommen ihn als Framework-Primitiv mit einem nullable Argument. Diesen Tausch nehme ich jederzeit.

Kurz die Versionsrechnung. extraData und die zwei Twig-Funktionen brauchen 7.4 oder 8.0. Symfony 7.4 ist die LTS, läuft ab PHP 8.2 und bekommt Bugfixes bis November 2028 mit Security-Patches bis November 2029; 8.0 will PHP 8.4 und fährt auf dem kürzeren Zyklus, unterstützt bis Juli 2026. Wenn du auf 7.3 geparkt bist, hast du addReason() bereits und solltest es heute benutzen. Meine Adoptionsregel ist simpel: Reasons überall, sofort, weil sie nichts kosten. extraData erst an dem Tag, an dem eine eigene Strategy es tatsächlich liest.

Bleibt die Frage, die ich immer wieder hin und her wende: Wo ziehst du die Exposure-Linie? Ist decision.message strikt ein Backoffice-Artefakt für Admins und Auditoren, oder würdest du dem Endnutzer, der gerade geblockt wurde, jemals eine gefilterte Version zeigen, damit er weiß, dass es die Rechnungsschwelle war und kein Bug? Sag mir, wo dein Team landet, und ob da draußen irgendjemand in Produktion wirklich gewichtete Votes gebraucht hat statt unanimous plus einer gut geschriebenen Reason.