Login Bundle Laravel Package

Getting Started

Framework check before anything else. forci/login-bundle is a Symfony bundle, not a Laravel package. The -bundle suffix, Kernel registration flow, and security.yaml-driven configuration are Symfony artifacts. There is no ServiceProvider, no package auto-discovery entry, no publishable config or migrations, and no guard driver for Laravel's AuthManager. Laravel's session guard / Eloquent provider and Symfony's firewall / authenticator / token-storage stack are parallel abstractions with no seam between them.

Where to look first (as reference code, not a dependency):

• DependencyInjection/ extension and bundle class — what is actually configurable.
• The security configuration block (firewalls, form_login, providers) — the real feature surface.
• The login controller/form and any event listeners — session handling, redirect behavior, success/failure flow.
• composer.json — PHP/Symfony constraints and whether Doctrine is a hard dependency.

Two legitimate starting paths:

1. You own a Symfony app where this bundle targets your framework version. Register it in config/bundles.php, wire a firewall and a user provider in security.yaml, point it at your login/logout routes. This is the only path where installation makes sense — and only if the license is cleared.
2. You are on Laravel. Do not composer require. Read the flow in a scratch branch, write down the auth requirements it surfaces (form login, remember-me, throttling, redirect handling, session fixation, multi-guard), then map each to first-party Laravel: Fortify (login/2FA/throttling), Breeze (scaffolding), Sanctum (API tokens), Passport (OAuth2), Socialite (providers).

First use case that actually pays off: requirements extraction for your auth spec. It's a free checklist of what a login module owns, and it clarifies scope boundaries (authentication vs. authorization vs. MFA vs. SSO vs. account recovery) at zero integration cost.

Hard gate before any code enters your tree: the license is NOASSERTION. Legal must clear it in writing — do not treat "public on GitHub" as a grant to reuse.

Implementation Patterns

Because there is no supported Laravel integration, the practical daily-use patterns are all reference, bridge, or fork workflows.

Pattern A — Reference implementation (recommended).

• Fork to a disposable branch, read the login flow end-to-end, convert findings into a requirements list, delete the branch.
• Do not copy code until the license is resolved; reimplement from the requirements instead.

Pattern B — Native Symfony usage (only if the target is Symfony).

• Everything is config-driven via security.yaml: define a firewall, a form_login authenticator with check/login/logout routes, a user provider (Doctrine entity or custom), and success/failure redirect behavior.
• Customization happens by overriding the authenticator or the form template, not by touching Laravel-style container bindings — there aren't any.
• Keep a test harness around the flow: successful login, failed login, remember-me persistence, logout invalidation, and redirect loops.

Pattern C — Fork and vendor (only if it's your own IP or rights are secured in writing).

• Pin the upstream commit, freeze the branch, add CI + a test harness around login, take ownership of dependency bumps and PHP/Symfony upgrades, and record an ADR.
• Budget ongoing maintenance (~10–15% of one engineer) and manual advisory monitoring — SCA tooling won't flag a package with no advisory coverage.
• Pilot behind a feature flag on a non-critical tenant with an instant fallback to the existing auth path.

Pattern D — Isolate as a service (last resort).

• If the bundle encapsulates protocol logic you don't want to rebuild (e.g. a niche IdP integration), stand it up as a standalone identity broker exposing OIDC/SAML and consume it from Laravel.
• Cost: a network hop, a second runtime to operate, and a new failure domain on the hot path. Choose this only if rebuild cost clearly exceeds the operational tax.

Do not attempt: booting Symfony Security inside a Laravel app (dual kernel, dual container, dual session semantics — a known anti-pattern), or writing a custom guard/provider bridge for an unmaintained component.

Requirement → Laravel mapping table to drive your spec:

Gotchas and Tips

• Naming trap. "login-bundle" reads like a package but is Symfony Kernel packaging. At intake, classify "Laravel/PHP package" as two separate categories so this doesn't get re-evaluated every quarter.
• License is a hard legal gate. NOASSERTION means GitHub couldn't map the repo to a recognized SPDX identifier. For commercial distribution or SaaS, this blocks adoption and blocks code reuse — get verbatim terms and copyright ownership in writing first.
• Adoption signal is absent. 1 star, 0 dependents, score 0.005. No downstream compatibility testing, no community triage, no advisories. You will be the only person finding its bugs, and auth is a Tier-0 path — a defect is either a tenant-wide lockout or an auth bypass.
• The integration failure mode is conceptual, not class-level. Session, CSRF, and firewall semantics collide before any namespace does. A 2–3 day spike confirms this fast; timebox it.
• Check Doctrine adjacency. If Doctrine is a hard dependency, coexisting with Eloquent in one app is a tax you almost never want to pay.
• Unknown version ranges. Verify declared PHP and Symfony constraints (^5/^6/^7) against your runtime before assuming fit; an uninspected transitive graph compounds supply-chain risk.
• No equivalent Laravel debugging surface. Symfony's profiler and security data collector help if you're actually running Symfony; in Laravel you have nothing comparable for this bundle — you cannot reason about its caching or locking behavior under retry storms without reading the source.
• Extension points live in security.yaml and authenticator overrides, not in config files you can vendor:publish.
• Auth is Tier-0: design the kill-switch first. Any pilot needs a per-tenant feature flag, an instant fallback to the existing auth path, and alerting on auth success rate and p95 latency.
• Onboarding cost recurs. No StackOverflow corpus, no community examples — expect 2–3× the ramp-up of a supported Laravel package, again for every engineer who touches the flow.
• Bottom line for day-to-day leverage: treat as prior art. Mine it for a requirements checklist, implement with Fortify/Sanctum/Breeze/Socialite, and re-open the adoption question only if the license is clarified, provenance is confirmed, and no first-party component covers the need.