Laravel Stateless Session Laravel Package

Product Decisions This Supports

• Client-side auth flow architecture (SPA / mobile / hybrid): This package exists to solve one narrow problem — getting a CSRF token to a non-server-rendered client via an HTTP header rather than an embedded Blade meta tag. That decision (header-based token fetch vs. cookie-based double-submit vs. a BFF pattern) is an architecture choice with security and maintenance consequences, and this package is a candidate implementation of one branch of it.
• Build vs. buy for security plumbing: CSRF token delivery looks trivial and is not. A maintained package with route-level middleware hooks is usually cheaper than an in-house route + controller + test suite, provided the surface area stays small enough to audit.
• 1.1.0 specifically — extensibility as a roadmap signal: The new custom middleware support on the csrf-header route means teams can now attach their own concerns (rate limiting, auth/session gating, CORS, request logging, custom response shaping) to the token endpoint without forking. For a PM this converts the package from "it does exactly one thing, take it or leave it" into "it does one thing and composes with our platform standards." That is the difference between a dependency an engineering team tolerates and one it will actually adopt.
• Security hardening backlog: The token endpoint is a pre-auth-adjacent surface. Middleware support makes throttling and origin restriction a configuration task rather than a code change — worth slotting into the security workstream as a low-effort item.
• Risk posture: 1.1.0 is a minor, additive release with no documented breaking changes. No migration work, no roadmap impact, no customer-visible behavior change unless you opt into the middleware.

When to Consider This Package

Consider adopting when:

• You have a first-party JS client (Vue/React/Inertia/Alpine) or a mobile app that needs a CSRF token and you do not want to scrape it from a meta tag or manage cookie semantics by hand.
• You want the token endpoint to be governed by standard Laravel middleware — throttling, auth, CORS, logging — rather than a bespoke route you maintain.
• You are standardizing CSRF handling across multiple Laravel applications and want one auditable, versioned implementation instead of N copy-pasted routes.
• Your team is small and you would rather spend the security review budget once, on a dependency, than on every app.

Look elsewhere when:

• Your architecture is server-rendered Blade only — the framework's built-in @csrf and session handling already cover you; this adds a surface for no gain.
• You use a pure token-based API (Sanctum personal access tokens, OAuth) where CSRF is not the threat model. Do not add stateful CSRF machinery to a stateless API.
• Your security policy forbids third-party packages on request/response paths, or requires vendor code review you cannot resource. The package is small, so review is feasible — but decide that explicitly rather than by default.
• You need guarantees this release does not speak to: no evidence here about maintained-version support, test coverage, or a security disclosure process. Verify those before treating it as infrastructure.
• The middleware hook is the only thing you need — if your real requirement is custom token issuance (rotation, per-device tokens, signed tokens), this package is likely too narrow and you should build the endpoint yourself.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, single-purpose open-source component that lets our JavaScript and mobile clients obtain the security token they need to submit forms safely. Version 1.1.0 adds the ability to attach our standard platform controls — rate limiting, access checks, logging — to that token endpoint through configuration rather than custom code. It is an additive, non-breaking release: no migration, no user-visible change, no cost. Adopting it reduces the amount of bespoke security code we write and maintain, and reduces the number of places our CSRF handling can drift out of policy. The decision it supports is whether to standardize CSRF token delivery on one vetted component or keep reimplementing it per application.

For engineering (the practical case): 1.1.0 lets you register custom middleware against the csrf-header route, which means token issuance can inherit the same throttling, auth gating, CORS, and observability stack as the rest of the app — no fork, no wrapper route, no divergence from platform conventions. It is a minor, additive change; upgrading is a composer bump. Two asks before you commit: pin the version and confirm the package's supported Laravel range and test/CI signal, since a token endpoint is a security-relevant surface and we should not adopt it on the strength of a changelog alone. If it clears that bar, it replaces roughly a day of route-plus-controller-plus-tests work per app and gives us a single place to audit CSRF delivery.