- Is jafar/guarded-authentication-bundle a Laravel package?
- No. It is a Symfony bundle: a Bundle subclass plus a DI extension registered with a kernel, and the Laravel/PHP catalog framing is a misclassification. Laravel has no bundle concept and no kernel autoconfiguration mechanism that would consume this code. If you arrived here looking for a Laravel authentication package, this is not one.
- Can I use jafar/guarded-authentication-bundle in a Laravel application?
- Not without a rewrite. Laravel's auth surface is Illuminate\Auth (AuthManager, guards, Auth::extend) plus middleware, while this package targets Symfony's authenticator and passport-badge system. There is no adapter, and the realistic path is one to two weeks building a Laravel-native JWT guard on lcobucci/jwt or firebase/php-jwt instead. At that point you have written your own package and gained nothing from this dependency.
- How do I install jafar/guarded-authentication-bundle?
- It is distributed on Packagist under the name jafar/guarded-authentication-bundle, so installation is a Composer require into a Symfony project followed by registering the bundle in your kernel configuration. The v4.0.0 release notes ship no changelog or upgrade guide, so open composer.json directly to confirm the exact PHP and symfony/* constraints before installing. Note that the project has no visible CI pipeline and zero dependents.
- Which PHP and Symfony versions does v4.0.0 require?
- v4.0.0 targets Symfony 6.x, which itself floors at PHP 8.0.2 or 8.1 depending on the minor version. The description's "php 8 or later" is a loose paraphrase rather than a real constraint, so you must read composer.json to see whether the floor is ^8.0, ^8.1, or ^8.2. Do not infer compatibility from the one-sentence release note.
- What changed between v3 and v4 of guarded-authentication-bundle?
- Symfony 6.0 removed the Guard component, so any package claiming Symfony 6 support has necessarily rewritten its authentication path onto the modern authenticator and passport-badge system. That is a substantive auth-code rewrite shipped with a one-sentence release note and no changelog, migration guide, or security section. Algorithm pinning, aud/iss validation, expiry handling, and key handling can all change silently in a rewrite like that. Treat "works with Symfony 6" as an assertion, not evidence.
- Does the bundle support JWT, and which signing algorithms does it accept?
- The evaluation flags an unverified JWT/JWS implementation sitting directly on the authentication path, and the algorithm allowlist is not documented anywhere in the release notes. Read the verifier source to confirm alg is pinned server-side, that "none" is rejected, and that HMAC/RSA confusion is prevented. Key storage, kid rotation, revocation and denylist behaviour are similarly undocumented. Those are the first four things to grep for before you consider depending on it.
- How do I protect routes and controllers with guards and access checks?
- The bundle exposes configurable guards plus an access-check layer, so protection means binding a guard to a route or controller instead of hand-rolling credential verification inside each action. Credential verification, session handling, and access decisions all sit behind the guard abstraction, which is the design's main selling point. Because there is no v4 changelog, verify the guard configuration keys against the current source rather than copying older examples.
- Can I implement a custom guard or user provider?
- In principle yes: the package ships extensible interfaces intended for custom user providers and guards, so you can swap the authentication strategy without touching controllers. In practice, with 8 stars, 0 dependents, and no CI, you would be among the first to exercise the v4 interfaces. Budget time to write your own tests around anything you extend.
- Is jafar/guarded-authentication-bundle safe to use in production?
- Risk is high. The package has no CI, no CVE monitoring, no stated disclosure process, and no dependents to surface defects, and v4.0.0 shipped after roughly three and a half years of silence. A single release after that gap reads as a one-off maintenance pulse rather than a maintained project. Watch issue triage and a follow-up release before treating the project as alive, and never put it on an authentication path in production without an independent audit.
- What are the Laravel-native alternatives to this bundle?
- Laravel's built-in Illuminate\Auth (AuthManager, guards, Auth::extend) plus middleware covers most of what this bundle offers, with Sanctum for SPA and API token auth and Passport for full OAuth2. For JWT specifically, build a guard on lcobucci/jwt or firebase/php-jwt, roughly one to two weeks of work, rather than porting a Symfony bundle. You end up with framework-supported maintenance, a real disclosure process, and a test suite that exists.