- Is fsi/admin-security-bundle a Laravel package?
- No. It is a Symfony bundle from the fsi-open namespace, registered through Symfony's kernel and bundle mechanism and built on top of symfony/security-bundle. It exists to connect Symfony's Security component to FSi AdminBundle admin resources. There is no Laravel service provider, facade, or Illuminate integration of any kind.
- Can I install fsi/admin-security-bundle in a Laravel application?
- Not meaningfully. The package ships no Laravel service provider, no Auth::extend hook, no custom guard or user provider, no Eloquent integration, and no publishable config stub in the Laravel sense. Its value lives in Symfony's access decision manager and voter events, which have no Laravel analogue. Installing it via Composer would add dead weight rather than working authorization.
- What does FSi Admin Security Bundle actually do?
- It adds a security layer to admin panels built with FSi AdminBundle, integrating admin resources with Symfony's Security component. That covers role- and permission-based access control, protection of admin routes and actions, and user-aware authorization decisions. It also allows configurable security policies per admin panel.
- Which Symfony and PHP versions does fsi/admin-security-bundle support?
- The bundle targets PHP 8.x on a Symfony 5/6-era kernel with Doctrine ORM and FSi AdminBundle present. The Security component version range matters a great deal here, because the authenticator API changed materially between pre-5.4 and 6.x. You should intersect its Composer constraints with your root composer.json for Symfony, Doctrine, and PHP before assuming compatibility, and pin an exact tag rather than floating on dev-master for anything in the auth path.
- Do I need fsi-open/admin-bundle to use this security bundle?
- Yes. AdminSecurityBundle is a thin security layer on top of FSi AdminBundle and cannot be adopted independently; it will resolve to a hard dependency on the admin layer anyway. AdminBundle in turn assumes Symfony, Doctrine ORM, and a Sonata-style admin CRUD model. If AdminBundle is not already in your stack, the transitive adoption cost dominates the whole evaluation.
- Is fsi/admin-security-bundle actively maintained and production-ready?
- Treat it as unproven. It has roughly 0 dependents and 4 stars, so there is effectively no production validation to lean on. It is single-vendor code authored for FSI's internal admin product, meaning roadmaps follow their needs rather than yours. For security code specifically, that means you become the de facto QA team.
- Why does the package show a future release date like 2026-04-09?
- The latest release is listed with a date that falls in the future relative to any plausible audit window, which is anomalous. It could be a backdated or retagged tag, a repository metadata quirk, or a scoring artifact. Do not accept "recently released" as a liveness signal here; verify the actual tag graph in the repository before drawing any maintenance conclusion.
- How do you install and configure fsi/admin-security-bundle in Symfony?
- Adoption sequence is AdminBundle first, then verify its Doctrine and entity conventions against your schema, then layer AdminSecurityBundle for authentication and authorization. Installation is a Composer require followed by bundle registration in the Symfony kernel and security configuration for roles, permissions, and access rules. Do not attempt to adopt the security bundle on its own ahead of the admin layer.
- How should I test authorization when using this bundle?
- Write functional tests that exercise the actual admin routes and assert both allowed and denied outcomes per role, since the bundle's behavior is expressed through Symfony's access decision manager rather than a simple API. Cover your voter logic and role hierarchy explicitly, including the current-user cases the bundle advertises. Pin the exact tag under test so results stay reproducible across upgrades.
- What are the Laravel alternatives to FSi Admin Security Bundle?
- In Laravel you would use the framework's own gates and policies, optionally with spatie/laravel-permission for role and permission storage, plus your admin panel's built-in authorization (Filament, Nova, or Backpack). Building a bridge is not worthwhile: an adapter would require reimplementing Symfony's voter semantics on top of Laravel gates, at which point you own the code and gain nothing from the dependency. If Laravel is a hard requirement, record this package as framework-incompatible rather than rejected on quality.