Backend Security Bundle Laravel Package

Getting Started

This is not a Laravel package — it is a Symfony 2.x-era bundle from the Modera Foundation backend stack, published as a read-only subtree split. Evaluate it before installing anything.

• Check the real source first. The GitHub repo is a [READ-ONLY] mirror; issues, PRs, and documentation live in the parent monorepo modera/ModeraFoundation under src/Modera/BackendSecurityBundle. Read the monorepo, not this repo — there are no issues, no releases after 2016-06-10, and no dependents to learn from.
• Confirm compatibility up front. The bundle targets old Symfony/PHP (roughly Symfony 2.8–3.x, PHP 5.5+). composer require modera/backend-security-bundle will resolve against equally old modera/backend-bundle and foundation packages; expect conflicts on any modern Symfony or PHP 8 project. Prototype in a throwaway VM before touching a real app.
• Register the bundle in app/AppKernel.php (or config/bundles.php on Symfony 3.4+) alongside the other Modera backend bundles, then clear cache and confirm the backend routes appear with bin/console debug:router | grep backend.
• Look first at the bundle's Controller/ and Resources/ directories plus its DependencyInjection/ config. The bundle is mostly backend UI wiring — controllers, ExtJS views, menu registrations — not a security engine.
• First use case: log into the Modera backend (/backend) as an admin, open the Security section, create a group, assign permissions to it, and add a user to that group. The intended win is managing users/groups/permissions through the UI instead of hand-editing security.yml and role hierarchies on every change.
• Realistic expectation: with 0 stars and 0 dependents, treat this as a reference implementation of a Modera backend section, not as a dependency you adopt. If you are on Laravel, there is nothing here to leverage — the equivalent work is Laravel's built-in auth plus a package like spatie/laravel-permission.

Implementation Patterns

Day-to-day you will interact with this bundle through the backend UI and through the entities it persists, not through its PHP API.

• UI-driven administration. Users, groups, and permissions are Doctrine entities managed by the security layer (in modera/security-bundle/foundation). The bundle's job is the screens. Add the section to the backend menu via the Modera backend navigation config rather than editing templates.
• Authorize in your own code, not through this bundle. The bundle records permissions; it does not change how the firewall evaluates them. Continue to use is_granted() / @Security annotations in your application and make sure the roles you grant in the UI match the roles your voters and access_control rules check.
• Model permissions at the group level. Create groups for job functions, attach permissions to groups, and put users in groups. Per-user permission assignments are supported but lead to unauditable sprawl; reserve them for exceptions.
• Provisioning and fixtures. For seeding users or CI environments, write directly to the underlying Doctrine entities/repositories in fixtures. Do not drive the controller actions programmatically — they are form/UI endpoints with CSRF and session assumptions.
• Isolation. Mount the backend on its own firewall/path with an access_control rule restricting it to super-admins. Never expose the security admin section on the same firewall or prefix as customer-facing routes.
• Extending the screens. Follow the standard Symfony bundle override path (app-level Resources/ModeraBackendSecurityBundle/...) for templates and JS, and register any custom menu entries through the backend bundle's navigation extension point rather than patching vendor code.
• Audit trail. If you need to know who changed whose permissions, plan for it yourself — the 2016 bundle predates any logging integration you would expect today. A Doctrine listener on the user/group entities is the pragmatic route.

Gotchas and Tips

• Read-only mirror. Patches must go to modera/ModeraFoundation; this repo will not accept PRs. Vendor-patching here is a dead end.
• Abandoned since 2016. PHP 8, modern Symfony, and current Doctrine will all fight the dependency graph. Composer conflict/replace overrides get messy fast; budget time for this or don't start.
• It does not stand alone. The bundle assumes the Modera backend (ExtJS admin app, backend menu, foundation services) is installed. Dropping it into a stock Symfony application gives you routes that render nothing useful and services that fail to wire.
• No user-facing documentation. There is no README covering setup beyond the monorepo, and the ExtJS UI is undocumented. Expect to read the controllers to understand what a screen actually does.
• Debugging checklist. Missing menu entry → navigation config, not the bundle. 403 in the admin → your access_control/firewall, not the bundle. Route not found → bundle not registered or cache not cleared. Blank screen → missing backend JS assets from the parent bundles.
• Upgrade risk is total. Without releases or maintainers, any override you write is pinned to an unversioned snapshot; there is no upgrade path to plan against.
• Use it as a specimen, not a dependency. The only durable value here is seeing how a Modera backend section is structured (controller + ExtJS view + menu registration). For a live project, use Symfony's native user provider with EasyAdmin/Sonata, or Laravel's auth with spatie/laravel-permission — both are maintained, documented, and have real communities behind them.