Securitybundle Laravel Package

Getting Started

1. Install with Composer, matching your Symfony version constraint:

   composer require ops-talent/securitybundle
   

2. Register the bundle — for Symfony 2/3 add to app/AppKernel.php:

   new OpsTalent\SecurityBundle\SecurityBundle(),
   

   For Symfony 4+ use config/bundles.php (this package is from the 2018 era, so verify the namespace resolves — it may be OpsTalent\SecurityBundle\OpsTalentSecurityBundle).
3. Read the bundle source first. With 0 stars and 0 dependents there is effectively no community documentation, so the authoritative references are:
   • DependencyInjection/Configuration.php — the config tree and every accepted option key.
   • Resources/config/services.yml — service IDs and tags you'll reference.
   • The bundle's own README and Tests/ fixtures.
4. First use case: protect the endpoints generated by opstalent/apibundle. Define a stateless firewall for your API path and a matching access_control rule:

   # app/config/security.yml (Symfony 3 style)
   security:
       firewalls:
           api:
               pattern: ^/api
               stateless: true
               # provider/authenticator keys from the bundle's Configuration.php
       access_control:
           - { path: ^/api, roles: IS_AUTHENTICATED_FULLY }
   

5. Load the bundle's route annotations (if any) before the apibundle routes so the security listeners apply first.

Implementation Patterns

• Stateless firewalls per resource area. Keep stateless: true and avoid sessions for API routes. Split firewalls when you have public (login/register) vs. protected API segments.
• Custom user provider. Wire your user/API-client repository into the bundle's provider service, then reference it via providers.your_provider on the firewall. This is the standard Symfony pattern and the bundle delegates to it.
• Token/credential authenticator. If the bundle ships a guard/entry point service, alias it in your firewall via guard: { authenticators: [...] } (Symfony 3.3+) or override the entry point. Don't hand-roll a parallel authenticator unless the shipped one lacks a feature — you'll fork the bundle's config contract.
• Route-level protection via access_control. Since opstalent/apibundle auto-generates controllers, you generally cannot annotate each action; instead express authorization with ordered access_control patterns (most specific first) keyed to URL prefixes.
• Role naming convention. Centralize API roles (e.g. ROLE_API_USER, ROLE_API_ADMIN) in a config parameter so access_control and the bundle's voter/checker stay in sync.
• Integrate at the kernel level, not the controller. Let the firewall + bundle authenticator reject unauthenticated calls; controllers should only handle authorization beyond authentication ($this->denyAccessUnlessGranted()).
• Testing workflow. Use symfony/phpunit-bridge and functional tests with a mocked token header to assert 401/403 vs. 200. This is the fastest feedback loop for a bundle with no upstream CI.

Gotchas and Tips

• Version/era compatibility. Last release was April 2018; expect Symfony 2.8–3.4 conventions (app/config, web/app_dev.php era). On Symfony 4+/5+ you'll likely need to bridge legacy service definitions, KernelInterface::MASTER_REQUEST constants, and the old security.encoders config.
• No maintenance signal. Zero stars and zero dependents means no upstream fixes for security disclosures. Treat every upgrade of Symfony or the security component as a compatibility review, and be prepared to vendor/fork the bundle if a CVE lands.
• Config is the contract. If a key "does nothing," confirm it exists in DependencyInjection/Configuration.php — older bundles silently ignore unknown keys or fail only on container build.
• Firewall ordering matters. A wildcard firewall placed before the API firewall will swallow requests and bypass auth. Keep the API firewall specific and early.
• Debug authentication with the security log channel. Raise monolog level for the security channel and inspect dev.log for authenticator decisions — the bundle's entry point typically logs to this channel.
• Extension points to prefer over editing vendor code: event subscribers on kernel.request/kernel.exception, a custom user provider, or a compiler pass that decorates the bundle's entry-point/authenticator service. All survive composer update.
• Pin the version. Set an explicit constraint in composer.json (e.g. "ops-talent/securitybundle": "1.*") so a future tag or branch rename doesn't silently change your auth surface.
• Cache clearing after config changes. Because the config tree feeds the container, cache:clear (or rm -rf var/cache) after every security.yml edit — otherwise stale firewall definitions cause confusing 404s on /api.