Gdpr Bundle Laravel Package

Getting Started

Reality check first: this is a Symfony bundle, not a Composer package you can composer require into a Laravel app and expect to work. There is no service provider, no facade, no Blade views, and no Laravel-native configuration loader. "Using" it from a Laravel codebase means one of three things: (a) you are actually working in a Symfony app, (b) you are running a small Symfony sidecar that renders/serves the consent UI, or (c) you are reading it as a reference implementation and reimplementing the cookie-catalog + consent-banner pattern in Laravel. Decide which before you install anything.

If you are genuinely in Symfony (the only case where the package runs as designed):

1. composer require nucleos/gdpr-bundle — note the last release is 2024‑08‑14 and the repo is archived, so pin the version explicitly and vendor it if you need long-term stability.
2. Register Nucleos\GDPRBundle\NucleosGDPRBundle in config/bundles.php.
3. Import the bundle routing (the bundle exposes controller routes for the consent endpoint) in config/routes.yaml.
4. Publish/copy the bundle's Twig templates and JS assets into your app if you need to restyle the banner — don't edit inside vendor/.
5. Configure your cookie catalog (group name, cookie name, purpose, lifetime, whether it's strictly necessary) in config/packages/nucleos_gdpr.yaml.

Where to look first, in order: the bundle's DependencyInjection/Configuration.php (this is the authoritative schema for the YAML config — the README will be thinner than the config tree), then the Twig templates, then the controller that handles consent submission. Those three files tell you the entire contract.

First use case to aim for: render the cookie information panel with two groups — strictly necessary (always on, not toggleable) and analytics (opt-in) — and gate a single analytics snippet behind the stored consent. Get that end-to-end before touching categories, i18n, or cookie scanning.

Implementation Patterns

Config-as-catalog. The bundle's core idea is that your cookie inventory lives in configuration, not scattered across templates. Treat that YAML as the single source of truth: every cookie your app sets should have an entry with purpose and retention, and your privacy policy page should be generated from or kept in sync with the same list. In Laravel terms this is a config/gdpr.php array of CookieGroup objects — mirror the shape even if you don't use the bundle.

Banner as a rendered partial, consent as a separate concern. Keep the UI (a Twig include / Blade component) stateless, and let a single controller endpoint persist the decision. The frontend toggles should never be the source of truth — they post to the backend, which validates against the configured categories and stores the accepted group set plus a timestamp. Anything the browser sends that isn't in your catalog should be rejected, not silently accepted.

Gate scripts at render time, not just at click time. The common failure mode is a banner that visually blocks analytics but the <script> tag is still in the HTML. Wrap analytics/marketing includes in a server-side check of the stored consent ({% if consent.allows('analytics') %} or a Blade @consent('analytics') directive), so a user with JavaScript disabled or a cached page never loads a non-consented tag. This is the pattern most worth copying into Laravel regardless of whether you keep the bundle.

Versioned consent records. Store the consent payload with (i) the catalog version/hash, (ii) timestamp, (iii) the accepted group list. When you add a new cookie category, bump the catalog version — your middleware then treats old consents as stale and re-prompts only for the new groups. Without this, you either never re-prompt (non-compliant after a policy change) or re-prompt everyone on every deploy (user-hostile).

Middleware over controller checks. In Laravel, a EnsureCookieConsent middleware or a view-shared ConsentService keeps the gating logic out of individual controllers. In Symfony the bundle's Twig extension plays this role. Either way, one injection point, one place to debug.

Symfony-sidecar pattern. If you must use the actual bundle from a Laravel shop, run it as a tiny Symfony app on a subdomain that serves /consent and the banner assets, and have Laravel read the resulting consent cookie (same parent domain, SameSite=Lax, not HttpOnly if the frontend needs to read it). This is more moving parts than it's worth for a banner — only do it if you already operate Symfony services.

Gotchas and Tips

• Archived is the headline risk. No security patches, no Symfony 8 / PHP 8.5 compatibility work coming. Audit the JS and templates yourself, pin the exact version, and have an exit plan (it's small enough to vendor-fork or reimplement in an afternoon).
• The package is a bundle, not a Laravel package. There is no laravel/gdpr-style equivalent here and no service provider. Any tutorial that tells you to add it to config/app.php providers is wrong. The 0 dependents and 11 stars reflect exactly this — it was never a cross-framework tool.
• Configuration schema drift. The README frequently lags the Configuration.php tree. When a config key "doesn't work," run bin/console config:dump-reference nucleos_gdpr and trust that output over the docs.
• Asset publishing is manual. Twig templates and the banner JS live in the bundle. If you override them in templates/bundles/NucleosGDPRBundle/, Symfony's bundle-override resolution means a typo in the path silently falls back to the vendor version — you'll "fix" the banner and see no change. Verify with the Symfony profiler's template panel.
• Consent is not authentication. Don't tie the consent record to a logged-in user only; anonymous visitors need consent too, which means a cookie or session key. Decide up front whether consent survives logout — GDPR-wise the consent record should, but the identifier shouldn't leak identity.
• Strictly-necessary toggles are a compliance bug. Some banner implementations render all groups as switchable. Necessary cookies must be displayed but not disableable; if the bundle lets you configure that wrongly, you can ship a non-compliant UI that looks fine. Test by trying to disable the necessary group.
• Cookie lifetime ≠ consent lifetime. The consent cookie's max-age and the retention period stated in your policy are two separate values. Keep them consistent and document the retention in the catalog entry, or an auditor will find the mismatch.
• Re-prompting on catalog changes needs a stable hash. Compute the hash from the semantic catalog (group names + purposes), not from the serialized YAML — otherwise a whitespace change or a comment triggers a re-prompt for every user.
• Cached pages break consent. If you full-page cache with the analytics include already rendered for consented users, you'll serve it to unconsented ones. Either vary the cache on the consent cookie or keep gated scripts out of the cached HTML entirely (client-side injection gated on a cookie read).
• Extension points worth using: the Twig extension (for allows() checks in templates) and the cookie-catalog config are the two stable seams. The controller and templates are the parts you're most likely to replace wholesale — so customize by overriding templates and the route target, not by forking bundle internals.
• Test the negative path. The only test that matters for a GDPR banner is: fresh session, no cookies accepted, every third-party request blocked. Assert on network requests in a headless browser, not on the presence of a banner <div>.