Weave Code
Laravel Cookie Guard Laravel Package
scify/laravel-cookie-guard
Laravel Cookie Guard is a configurable cookie consent package for Laravel. It adds a GDPR-friendly banner, lets visitors accept or reject cookie categories, remembers their choices, and helps load scripts conditionally through simple Blade helpers and middleware.
A Laravel package that provides a Cookies consent floating window and publishes the Cookies for all consent categories
Frequently asked questions about Laravel Cookie Guard
- How do I install and publish Laravel Cookie Guard?
- Install it with composer require scify/laravel-cookie-guard and let Laravel auto-discover the service provider. Publish the package config, views, assets, and translations, then commit the published files because the package is designed to be forked at install time. Review the cookie categories and route configuration before enabling the banner, and track upstream changes manually when you re-publish.
- Which Laravel versions and application types does scify/laravel-cookie-guard support?
- Check the package composer.json for the exact Laravel and PHP constraints before upgrading, because version support is defined there rather than in marketing copy. Architecturally it fits server-rendered Laravel monoliths using Blade, Livewire, Inertia, or Turbo. It is not intended for headless or API-only backends with non-Laravel front ends. Treat minor releases as changelog-required because v5.1.0 contained behaviorally breaking changes.
- How do I customize the cookie consent banner markup and translations?
- Publish the package views, assets, and translations into your application, then edit the Blade component and language files you own. Keep the root data-* attributes and JavaScript markup in sync with the published assets, because the new JS depends on the new markup. If you republish assets without updating views, you can get silent degradation such as erasure not working and a 365-day lifetime. Assign an owner for merging upstream markup changes.
- How do I load scripts conditionally based on cookie consent categories?
- Use the package Blade helpers and middleware to check the visitor's consent categories before rendering analytics, marketing, or other non-essential scripts. Declare the cookie names for each category in config so acceptance and rejection map to the correct behavior. Do not rely on client-side hiding alone for sensitive scripts; gate server-rendered output where possible. Verify that the consent cookie is present and current before trusting it.
- Why does the cookie consent banner stay open after a visitor saves choices?
- In v5.1.0 the banner hides only after the server confirms the save to POST /guard-settings/save. A missing or invalid CSRF token, broken session, proxy or Secure-cookie misconfiguration, or payload validation failure such as a 422 can leave the banner blocking the UI. Confirm the route is running in the web group with sessions and CSRF, and check logs for 419 or 422 responses. Test behind your load balancer with TrustProxies and X-Forwarded-Proto configured correctly.
- What breaking changes should I check before upgrading to v5.1.0?
- The save route now enforces CSRF inside the web group, so first-party code posting to it must send a token. Consent cookie lifetime now follows cookie_lifetime instead of a hardcoded 30 days, which is a compliance-relevant change. Rejecting or withdrawing a category now erases matching cookies on the host and parent domains down to the registrable domain. Also audit for the removed enabled config key, the se to sv locale move, and the removed cookies_consent_selection cookie. Read the changelog and treat the minor release as potentially breaking.
- Does rejecting a cookie category delete cookies, and on which domains?
- Yes, in v5.1.0 rejecting or withdrawing a category erases cookies whose names are declared in that category. The erasure applies on the host and every parent domain down to the registrable domain, so subdomain-per-tenant and shared-parent-domain estates have a wider blast radius. Audit your app cookie names against the declared category names before enabling this behavior. Run a staging verification because any colliding cookie name on any subdomain can be affected.
- Is cookie consent state stored server-side for auditability?
- Based on the package context, consent choices are persisted in a cookie and there is no documented server-side consent record. That limits auditability to the client cookie plus any application logs you add yourself. If you need a durable audit trail, implement custom logging or persistence around the save endpoint. Also confirm how the cookie_lifetime change affects your documented consent renewal period.
- How should I test Laravel Cookie Guard before production?
- Use a staging environment to verify the CSRF path, session behavior, banner closing, and 422 validation responses. Write feature tests that post to /guard-settings/save with a valid CSRF token and assert the consent cookie and category behavior. Explicitly test cookie erasure on the host and parent domains, especially if you use subdomains. Check route caching and Secure-cookie behavior behind your proxy before rollout.
- What production concerns should I review for /guard-settings/save?
- The endpoint is now a session-bearing web route, so confirm route caching still works and consider rate-limiting it at the edge. Monitor for 419 CSRF failures and 422 validation errors because either can leave the banner blocking the UI. Ensure Secure cookie flags are correct behind your load balancer using TrustProxies and X-Forwarded-Proto. Add the historical CSRF-exempt write endpoint to your security register and review logs as part of the upgrade.
Weaver
How can I help you explore Laravel packages today?