Download the PHP package pushery/legal-consent-for-laravel without Composer

Legal Consent for Laravel

Court-proof, versioned legal consent for Laravel. It is a document-acceptance ledger: the package renders and proves your legal texts — it does not own them.

Why this exists

A registration does three legally distinct things, and treating them as one (a single "I accept everything" checkbox) is a common — and real — GDPR violation:

This package keeps them separate by design, and proves acceptance the way the law requires (Art. 7(1); EDPB 05/2020 §108): it stores the exact text a user was shown, its version and hash, and the server-side context — not just a timestamp.

Highlights:

• Append-only audit ledger — every acceptance/acknowledgement/withdrawal is one immutable row with denormalized proof (hardened by a DB trigger on Postgres/MySQL and an app-layer guard everywhere).
• Versioned documents — a SHA-256 hash detects a change; you classify how it must be communicated (its notice mode); only a core contract change forces active re-consent.
• Four notice modes — an editorial change is silent; an info-only change (a § 675g payment-contract update, a material privacy notice) is announced but never blocks; a minor contract change can bind by silence with an objection window (Zustimmungsfiktion, § 308 Nr. 5 BGB); only a material core change gates — each with durable-medium delivery proof.
• Interchangeable content sources — Markdown files (default), the database, or any foreign CMS via a small resolver.
• Fortify-optional — record consent three ways (a trait, an event listener, or a headless JSON API). laravel/fortify is never required.
• Optional, off by default — a tamper-evidence hash chain (legal-consent:verify-ledger), an Art. 8 age gate, and multi-tenancy scoping — each a single config switch.
• Optional reactive UI — plain Blade stubs by default; opt-in Livewire components and a WireKit-flavored variant when you want them (no hard Livewire/Flux dependency).

Compatibility

Every database-touching path is tested against real PostgreSQL and real MySQL 8.4 (not just SQLite), so it runs on Laravel Cloud (serverless Postgres + MySQL 8.4 LTS) out of the box. PostgreSQL is primary, but the append-only and one-active-version guarantees are enforced portably in the app layer on every engine.

Installation

The service provider is registered automatically. Publish the config and run the migrations:

Quick start

1. Write your texts as Markdown with frontmatter at resources/legal/{type}/{locale}.md:

   version drives the ledger and decides what counts as a major change. Two optional keys, announce_at and enforce_at (or effective_at), let the text itself carry its schedule — the publish flags below override them. How a change is classified is never taken from the file: that is a decision you make per publish, at the command line.

2. Publish a version (freezes it into the ledger; you must classify the change):

   An initial version takes effect at once — there is nothing to give notice of yet. A later material change is a different act: it must be announced ahead of its effective date, with the advance period its regime requires (see Change classes & notice modes).

3. Give any model a consent ledger with the trait:

4. Enforce re-consent by adding the middleware to your authenticated routes:

   It redirects to your legal.consent route (or returns 409 legal_consent_required for JSON) when a mandatory document has an outstanding new major version.

Recording consent (three ways)

All three write the same ledger through one recorder and share an idempotency flag, so they never double-write.

Way A — Fortify CreateNewUser trait (strongest proof context):

Way B — the Registered event listener (no Fortify): it is registered automatically; toggle it with legal-consent.registration.listen_to_registered_event.

Way C — the headless JSON API (opt-in via legal-consent.routes.api):

Or use the facade / manager directly:

Objecting and terminating

Two rights need their own record, because a change can be answered without accepting it:

Each appends one immutable ledger row and fires an event — ConsentObjected or ConsentTerminated — because only your app can act on it: the package cannot know which processing an Art. 21 objection must stop, or how your contract ends. Listen and act:

The delivery proof

Every pushed change notice writes an append-only legal_notices row (unless you turn durable_medium.proof off): who was informed, when, on which medium, the exact text sent, its hash, and whether the notice carried its mandatory content. That is the evidence a durable-medium notice actually went out (CJEU C-375/15) — audit it like any model:

The proof is append-only and holds personal data, so legal-consent:prune covers it on the same retention rule as the consent ledger: superseded and orphaned rows past the period go, while the newest notice per subject and document is kept — it is what proves the change behind their current standing was lawfully announced.

Change classes & notice modes

A change to a legal text is not one thing. The package models the four ways a change is communicated and enforced — NoticeMode — so a change gets exactly the notice the law requires and never more:

legal-consent:dispatch-notices routes each mode to the matching notification — LegalChangeInformational ("no action required"), DeemedConsentNotice (carrying the § 308 Nr. 5 lit. b "silence counts as consent" warning), or ReconsentRequired — and, with durable_medium.proof on, writes an append-only row to legal_notices proving the notice was delivered. Only ActiveReconsent ever blocks access.

The invariants (never violated)

• A privacy notice is acknowledged, never consented, and is never gated — a material privacy update is InfoPush, announced but non-blocking (WP260 rev.01).
• A real consent is never refreshed by silence or deemed consent; a material scope change needs a fresh, active opt-in (EDPB 05/2020).
• Deemed consent lives only in the contract type, and only for minor changes (BGH XI ZR 26/20, EuGH C-287/19).
• Advance-notice periods are per regime, never one global value (see notice_periods).

Worked example — an info-only contract change ("no action required")

A payment-contract change your users only need to be told about:

Once the announcement date passes, dispatch-notices emails each affected subject a LegalChangeInformational ("we've updated our contract; no action is required"), records a durable-medium proof row, and the change takes effect on the effective date — no one is blocked. Render the dismissible heads-up banner from ConsentBanner:

Worked example — deemed consent with an objection window

A minor contract change where silence may bind, provided the subject gets an adequate window to object and the § 308 Nr. 5 lit. b warning.

The statutory period is measured to the objection deadline, not to the effective date — the subject must have the full period to actually object — and it is never waived, not even for an immediate change. So the deadline must be at least deemed_consent_min_days after the announcement, and the change takes effect after it:

dispatch-notices sends a DeemedConsentNotice carrying the warning and the free-termination right. A subject who does nothing is bound: once the objection deadline passes, legal-consent:close-objection-windows (hourly, auto-scheduled) records a DeemedAccepted row — silence, made provable. A subject who objects or terminates in time is recorded instead, and the fiction never applies to them.

Active re-consent (a material core change)

A material change to the core of the contract still requires active agreement, with the full grace period and a hard gate at the deadline:

Both dates are validated — you cannot smuggle a short lead by omitting --announce-at, and the minimum period is per regime (§ 675g's two months is hard). From enforce_from, the middleware blocks the subject until they re-accept the new major version. A SHA-256 hash detects any text change; a human classifies it (the notice mode) at publish time; the gate compares major_version only.

Content sources

Each document declares a source in config/legal-consent.php:

• markdown (recommended) — git-diffable, PR-reviewable .md files.
• database — the active legal_documents row (edit via your own admin UI).
• cms — a foreign CMS. Implement Pushery\LegalConsent\Content\CmsResolver (or pass an inline closure) that returns a RawDocument; the package never learns what a "page" is.

Commands

legal-consent:publish flags

Exactly one mode flag per publish; the rest are optional metadata.

A major version bump forces its mode. The publisher refuses --info/--deemed on a major bump of a contract — a material core change cannot ride on silence or mere information (BGH XI ZR 26/20) — and refuses anything but --info on a major privacy bump, because a privacy notice is acknowledged, never gated. Publish a change that needs --info/--deemed as a minor or patch bump of the source version.

UI

The core is headless — it renders and proves, and never forces a UI framework on you. Three levels, pick one:

1. Plain Blade stubs (default, no dependency) — the consent checkboxes, the grace-period banner, and a settings page. Publish and restyle them freely:

2. Livewire components (opt-in) — reactive, drop-in versions of the interactive screens: <livewire:legal-consent.reconsent-form /> and <livewire:legal-consent.consent-settings /> — one-click accept, withdraw (Art. 7(3)), object, and terminate. They register automatically only if you have livewire/livewire installed, so the package stays dependency-free otherwise.

3. WireKit-flavored variant — if your app uses WireKit, publish the WireKit-themed stubs to override the plain ones:

   These are a themed starting point; a fully WireKit-native companion package is planned.

Every variant bakes in the non-negotiable anti-dark-pattern rules: checkboxes are never pre-checked (Planet49 C-673/17), a real consent is never required (Kopplungsverbot Art. 7(4)), and the full text is always linked and retrievable (clickwrap, § 305 II BGB).

Bundled translations. Every string the package renders — the grace-period banner, the consent and settings stubs, the re-consent notification, the validation messages, and the acceptance wording — ships translated in seven locales out of the box: German, English, Spanish, French, Italian, Dutch, and Portuguese. Override any of them by publishing the language files:

This is independent of legal-consent.locales, which is the set of locales you publish your own legal documents in — leave it at [de, en] even while the UI is available in all seven.

Configuration

Everything lives in config/legal-consent.php. The keys you are most likely to touch:

Optional features (each off by default)

• tamper_evidence (false) — turn on the append-only hash chain. Every new ledger row links to the subject's previous one, so a later edit, deletion, or reorder is detectable. Audit it with php artisan legal-consent:verify-ledger (non-zero exit on a break); combine with the DB append-only trigger for the strongest guarantee.

• age_gate (enabled: false, threshold: 16) — Art. 8 DSGVO. When on, registration additionally requires an age_confirmed attestation. The package gates on the attestation; verifying the actual age stays your app's job.

• tenancy (enabled: false, column: tenant_id) — scope documents and consents per tenant. Register a resolver in a service provider's boot():

  Each tenant gets its own active version of a (key, locale); admin sweeps (prune, dispatch-notices) run across all tenants.

Upgrading

0.2.x → 0.3.0

Backward-compatible: existing code, config, and ledger rows keep working. Run the migrations and you are done.

What they do:

• Add the notice-model columns to legal_documents (notice_mode, change_class, regime, notice_period_days, offers_termination, keeps_unmodified_offered, objection_deadline, objection_closed_at). Existing versions are backfilled: one that required re-consent becomes ActiveReconsent, one that did not becomes SilentEditorial — the behaviour they already had.
• Create the append-only legal_notices delivery-proof table.
• Drop the legal_consents.document_id foreign key (PostgreSQL/MySQL only). Its ON DELETE SET NULL fought the append-only guarantee: deleting a superseded legal_documents row aborted on PostgreSQL and silently rewrote a ledger row on MySQL. The column and the document() relation stay; the relation resolves to null once the document is gone. Present since 0.1.0 — this is a fix, and nothing you must act on.

Then, optionally:

• --material still works; it is now an alias of --active. New publishes can classify more precisely with --info, --deemed, or --editorial.
• legal-consent:close-objection-windows is auto-scheduled (disable via schedule.close_objection_windows). It only does anything once you publish a --deemed change.
• requires_explicit_optin was removed from the published config's documents entries. It was never read — the value is derived from legal_basis. Delete it from your published config if you like; leaving it is harmless.

Testing

Security

Please review the security policy and report vulnerabilities privately rather than opening a public issue.

Built by Pushery

This package is built and maintained by Pushery — a Berlin-based studio building Laravel applications, SaaS products, and open-source tools.

Building a Laravel UI? WireKit, Pushery's open-source Livewire component kit, gives you a polished component library out of the box. Browse the rest of our work at pushery.com.

License

The MIT License (MIT). See LICENSE for details.