Weave Code
Consent Bundle Laravel Package
setono/consent-bundle
Setono Consent Bundle is a Symfony bundle for managing user consent, including cookie and GDPR compliance. It provides consent storage, checks, and integrations to help your application respect visitor privacy choices.
Setono Consent Bundle provides a flexible consent management layer for Symfony applications, letting you record, check, and revoke user consents—such as cookie or marketing permissions—in a GDPR-friendly way. It ships with sensible defaults while staying easy to extend.
- Store and version consents per user or session
- Pluggable consent types and storage backends
- Twig helpers and services for checking consent state
- Symfony DI configuration out of the box
Frequently asked questions about Consent Bundle
- Can I use setono/consent-bundle in a Laravel application?
- Not as a drop-in package. It is a Symfony bundle that relies on Symfony's DI extension, configuration tree, event subscribers, and Twig helpers, and Laravel has no Bundle::boot() equivalent. The portable part is setono/consent-contracts, which you can wrap in your own Laravel service provider if a short spike confirms it has no Symfony kernel assumptions.
- What is the difference between setono/consent-bundle and setono/consent-contracts?
- The contracts package is a framework-agnostic PHP abstraction for asking whether a visitor has consented to a category. The bundle wires those contracts into Symfony with service definitions, config, events, and Twig helpers. For Laravel, treat the contracts as the useful dependency and the bundle as a Symfony-specific reference implementation.
- How do I integrate consent contracts into Laravel 10, 11, or 12?
- Budget a one-to-two day spike first: require setono/consent-contracts in a scratch Laravel 10, 11, or 12 app with PHP 8.1+ and implement one adapter. Bind the contract interfaces in a ConsentServiceProvider behind a ConsentManager facade, then add a Blade directive such as @whenConsented('analytics') and middleware like EnsureConsent:analytics for route gating. Record the spike result as an ADR before committing to the dependency.
- Does setono/consent-bundle require Symfony's kernel or DI container at runtime?
- The bundle layer does: it is a Symfony DI extension with configuration, service definitions, event subscribers, and Twig helpers. The contracts layer may be usable standalone, but that is the go/no-go question to verify in a spike. Do not assume composer require setono/consent-bundle just works in Laravel.
- Where is consent state persisted, and does it provide a GDPR audit trail?
- The provided overview does not specify whether state lives in a cookie, the session, or a database, nor whether it records timestamp, policy version, and subject identifier. Treat persistence and audit evidence as must-verify items during your spike. A consent library that silently fails open is worse than no library, so confirm default-deny behavior and evidence logging yourself.
- Does this package block tracking scripts or only expose a consent query API?
- The overview describes configurable consent types and integrations so your app can respect visitor choices, but it does not prove enforcement of script blocking. Blocking is the part that carries real compliance weight, so verify whether the package gates tags or only answers queries. In Laravel, plan to enforce gating yourself via Blade directives and route middleware.
- Is setono/consent-bundle production-ready given its low adoption and maintenance risk?
- Treat it as high-risk for production: the assessment cites 4 stars, 0 dependents, a score of 0.02, and single-maintainer bus factor, despite a fresh 2025 release. Symfony major-version and PHP pins can also collide with Laravel's transitive Symfony components. Use the contracts as an optional boundary, keep a swap path to a JS CMP with server-side verification, and do not let consent fail open.
- Will setono/consent-bundle Composer constraints conflict with Laravel's Symfony dependencies?
- There is a classic transitive-constraint trap: the bundle constrains Symfony 5, 6, or 7 plus PHP versions, while Laravel already pulls its own Symfony components such as HttpFoundation. Inspect composer.json exactly and test resolution in a scratch app before adding it to a real project. The contracts-only path is likely simpler to constrain than the full bundle.
- How do I test default-deny consent behavior in Laravel?
- Implement a fake ConsentChecker in tests and assert that unknown or expired consent denies access by default. Add feature tests for the EnsureConsent middleware and the Blade directive, including policy-version changes that should trigger re-consent. Also test that no code path silently treats missing consent as granted.
- What alternatives should I consider for GDPR consent in Laravel?
- Consider a JavaScript CMP such as OneTrust, Cookiebot, or Osano with server-side verification, a Laravel-specific consent package, or a small in-house ConsentManager built around the contracts idea. Keep any vendor abstraction at the boundary so swapping to a CMP is a single-class change. The valuable idea is typed consent categories and a decoupled checker, not the Symfony bundle itself.
Weaver
How can I help you explore Laravel packages today?