Audit Logger Bundle Laravel Package

Getting Started

First, the critical caveat: this is a Symfony bundle, not a Laravel package. The Bundle suffix, the minvws (Dutch Ministry of Health) namespace, and the nl-rdo-* repo naming all point to the Symfony ecosystem. If you're evaluating it for a Laravel codebase, treat it as a reference implementation rather than a composer require-and-go dependency. There is no AuditLoggerBundleServiceProvider, no config publish command, and no facade.

That said, the underlying concepts (PSR-3 logging, immutable audit records, event-driven capture) are framework-agnostic, so you can vendor the logic or write a thin adapter.

Minimal first steps:

1. composer require minvws/audit-logger-bundle — expect it to pull in symfony/framework-bundle, symfony/http-kernel, and likely psr/log. In a Laravel app these will sit alongside your existing Symfony components (Laravel already ships several), so check for version conflicts with composer why-not.
2. Open the repo README (not the Packagist page — there are zero dependents, so Packagist metadata will be stale). Read src/ for the audit record model, the event subscriber(s), and any interfaces intended for extension.
3. Look at the bundle's DependencyInjection/ folder for the configuration tree — that tells you exactly what is tunable (log sinks, redaction rules, user-context resolvers). As of 1.1.0, AuditLoggerInterface is now wired into the bundle's configuration automatically — this is the central contract you should read first, because it names the method(s) every audit sink must implement.
4. First real use case: pick one high-value audit event — typically an authentication or PHI-access event — and wire it end-to-end on a branch. Don't try to instrument the whole app on day one; the value is in proving the record shape and retention path.

Implementation Patterns

Because this is a Symfony bundle, the natural integration pattern in Laravel is not to boot it but to extract its domain pieces:

• Audit record as a value object. Look for a data class in the bundle representing an audit event (actor, action, target, timestamp, outcome, correlation ID). Port that shape into app/Audit/AuditEvent.php and mirror the field semantics exactly — the bundle is presumably designed against NL-RDO / NEN 7510 audit requirements, and mismatched field names make downstream compliance reporting painful.
• AuditLoggerInterface is the seam. 1.1.0 makes explicit what the bundle expects: an AuditLoggerInterface registered in the DI config. In Symfony this resolves to a concrete PSR-3-backed logger; in Laravel, implement the same interface (or a Laravel-native parallel) and bind it in a service provider — $this->app->bind(AuditLoggerInterface::class, LaravelAuditLogger::class). This is the single most portable piece of the bundle.
• Event capture via Laravel events, not Symfony listeners. In Symfony the bundle will register kernel event subscribers (e.g. on kernel.request / kernel.response). In Laravel, the equivalents are middleware or model observers. A common pattern:
  • app/Http/Middleware/AuditRequest.php for request-scoped audit (actor, route, IP, outcome).
  • Model observers (AuditObserver) on models that represent sensitive resources — hook created, updated, deleted, and capture the diff with explicit allow-listing of attribute keys.
  • Event::listen for authentication (Login, Logout, Failed) via Laravel's built-in auth events.
• Sink abstraction. The bundle writes through AuditLoggerInterface (now auto-registered as of 1.1.0). In Laravel, bind that interface to a dedicated channel (config/logging.php → audit channel, likely a separate file or a stream to a central collector) so audit records never get mixed with application debug logs. Do not reuse the default stack channel.
• Correlation IDs. Propagate a request/correlation ID through every audit record. The bundle will likely have a notion of context; in Laravel, generate it in middleware and stash it in a scoped container binding or Context (if you're on Laravel 11's Context facade).
• Actor resolution. Symfony bundles typically expose a "user context" interface you implement against Security. In Laravel you'd implement the same interface against Auth::user(), and inject a NullUser for CLI/queue jobs where there is no authenticated actor (but still log the system actor).

A realistic day-to-day workflow looks like: model change → observer constructs AuditEvent → event pushed to a queue (ShouldQueue) for async write → dedicated audit logger serializes to JSON → shipped to WORM storage or SIEM. Keep the synchronous write path for auth events only; everything else queues.

Gotchas and Tips

• The framework mismatch is the dominant risk. Every hour you spend trying to make Symfony's DI container and Laravel's service container cooperate is likely wasted. Vendor the audit domain classes (MIT/EUPL-2.1-friendly, so copying is permitted with attribution) and rewrite the integration layer. The 1.1.0 change — registering AuditLoggerInterface in DI config — is a Symfony-side fix and does nothing to bridge that gap for you.
• Don't confuse "auto-registered in DI" with "usable in Laravel". 1.1.0 makes the interface resolvable inside the Symfony kernel. It does not expose it to Laravel's container; you still need your own binding.
• Zero stars, zero dependents, no community. There is no Slack channel, no Stack Overflow corpus, no blog posts. When something breaks, you are reading source. Budget for that.
• Release date is in the future (2026-04-14 at time of prior assessment). Treat Packagist metadata as unreliable until you verify the tag on the GitHub repo directly. Pin to a commit SHA, not a version constraint, until you've confirmed the release is real.
• EUPL-1.2 is a copyleft license. It's compatible with most internal use, but if you're distributing software that embeds the bundle, you have obligations. Legal review is warranted for a health-sector codebase — this is not MIT.
• Compliance semantics matter more than code quality. The bundle exists to satisfy Dutch healthcare audit requirements (NEN 7510, potentially GDPR Art. 30). If you port the logic, preserve the exact event taxonomy and field names; don't "improve" them. Downstream auditors will check against the spec, not your nicer naming.
• Redaction is a footgun. Audit logs of PHI must not leak the phi itself. Check whether the bundle's config tree has a redaction/filtering layer; if it does, port it wholesale. If it doesn't, implement redaction before the record hits the logger — retroactive redaction of an audit log defeats the audit trail.
• Async queuing changes ordering guarantees. If you push audit writes onto a queue, records can arrive out of order or be lost on worker crashes. For auth events and access-to-record events, write synchronously; queue only high-volume background mutations where eventual consistency is acceptable.
• Debug by inspecting the raw payload first. Before blaming the transport, dump the serialized audit record and diff it against the bundle's expected schema. Most integration bugs here are field-name mismatches, not logic errors.
• Extension points to look for in the bundle source: AuditLoggerInterface (confirmed real and central as of 1.1.0), the user/actor resolver, the record serializer, and the log handler. Those four are what you'll reimplement for Laravel — everything else is glue.