Weave Code
Cookie Laravel Package
delight-im/cookie
Modern cookie management for PHP. A clean, secure API for setting, reading, and deleting cookies, with support for SameSite, HttpOnly and Secure flags, cookie prefixes, and session handling—helping you follow browser security best practices without boilerplate.
Modern cookie management for PHP
Frequently asked questions about Cookie
- Is delight-im/cookie a Laravel package?
- No. It is a framework-agnostic, dependency-free PHP utility library with two main classes: a static Cookie facade over PHP's native setcookie() and a Session helper for cookie hardening. It has no service provider, config file, middleware, or Laravel integration. Inside Laravel it creates a parallel cookie authority alongside the native cookie factory and EncryptCookies middleware, so it should be treated as an edge utility rather than a Laravel component.
- How do I install delight-im/cookie in a Laravel project?
- Installation is mechanically trivial with composer require delight-im/cookie: it is MIT licensed, has no transitive dependencies, and needs no service provider or published config. The hard question is whether you should install it inside a standard Laravel app at all, because Laravel already ships equivalent cookie and session semantics. Use it only where you have a genuine out-of-framework boundary, and run a short spike before committing.
- Does delight-im/cookie support SameSite, HttpOnly and Secure flags?
- Yes. It provides first-class SameSite, HttpOnly and Secure handling, plus path, domain and expiry normalization and cookie prefix support. That explicit SameSite handling is its main value proposition, especially for older code that predates browsers defaulting to SameSite=Lax. However, Laravel already exposes secure, http_only and same_site in config/session.php and its cookie config, along with encryption and signing through the web middleware group.
- Which Laravel and PHP versions does delight-im/cookie support?
- It is not Laravel-versioned; it is a framework-agnostic PHP library, so support depends on the PHP constraint in its composer.json. Treat PHP 8.1 implicit nullable parameters and dynamic properties, PHP 8.2 readonly and string interpolation changes, and setcookie() signature changes across PHP 7.3 and 8.x as live risks. Test it against the PHP floor of your Laravel 9 to 11 stack before adopting it.
- Should I use delight-im/cookie instead of Laravel's cookie facade?
- For a normal Laravel web application, no. Laravel's cookie factory, EncryptCookies middleware and AddQueuedCookiesToResponse already provide encryption, signing and response integration that a static setcookie() wrapper cannot match. delight-im/cookie is only justified at a non-Laravel edge, such as a standalone script or legacy service, or when a package must remain framework-independent.
- Can delight-im/cookie handle session cookies and cookie prefixes?
- Yes. It includes a Session helper that centralizes session cookie hardening, and its Cookie facade supports cookie prefixes such as __Host- and __Secure-. You should still verify that this hardening does not conflict with Laravel's session configuration and EncryptCookies behavior. Because the library writes through setcookie(), it bypasses Laravel's response-centric cookie queue and middleware.
- How do I test delight-im/cookie in a Laravel application?
- Test it as a static global-state dependency rather than as a Laravel-native component. Output buffering and headers already sent errors are invisible to Laravel's response model, so isolate the tests and assert on emitted headers. Add regression tests for SameSite defaults, cookie prefixes and deletion semantics, since those are the behaviors most likely to drift.
- Is delight-im/cookie safe for production authentication and session handling?
- Be cautious. Cookie and session handling sit directly in the authentication and session-fixation blast radius, and this is a small single-maintainer library with weak downstream pressure-testing. Pin a version and a commit SHA, read the source before it touches session-bearing code, and prefer Laravel's native session hardening where it meets the requirement. Treat any adoption as a security review item, not a routine dependency.
- What are the best alternatives to delight-im/cookie for Laravel?
- The natural alternatives are Laravel's native cookie factory and session configuration, or Symfony HttpFoundation cookie classes if you need framework-neutral cookie objects. If your real requirement is a consistent cookie policy across frameworks, writing roughly 40 lines of in-house code may deliver most of the value at a lower total cost. Reading the library as a reference for SameSite and session-hardening patterns is often more valuable than depending on it.
- Is delight-im/cookie actively maintained, and should I fork it?
- Single-author projects of this shape tend to have long quiet periods, and there is no security policy, CVE feed or LTS commitment to rely on. If you adopt it, fork and vendor it under your own namespace and accept full ownership rather than depending on unmaintained upstream code. Otherwise treat it as a reference implementation for SameSite defaults and session cookie hardening.
Weaver
How can I help you explore Laravel packages today?