Oauth2 Server Client Manager Supervisor Bundle Laravel Package

Getting Started

This bundle is a thin Symfony2 glue layer around spomky-labs/oauth2-server-client-manager-supervisor. It exposes a ClientManagerSupervisor as a container service so that the Spomky OAuth2 server stack can pick from multiple client managers (DB-backed clients, config-backed clients, an in-memory manager for tests, etc.) instead of a single one.

Minimal path:

1. Install via Composer. Expect an abandoned warning — the package has no dependents, no stars, and targets Symfony 2.x:

   composer require spomky-labs/oauth2-server-client-manager-supervisor-bundle
   

2. Register the bundle in app/AppKernel.php alongside SpomkyLabs\OAuth2ServerBundle (this bundle is meaningless without it):

   new SpomkyLabs\OAuth2ServerBundle\SpomkyLabsOAuth2ServerBundle(),
   new SpomkyLabs\OAuth2ServerClientManagerSupervisorBundle\SpomkyLabsOAuth2ServerClientManagerSupervisorBundle(),
   

3. Look first at DependencyInjection/ — the *Extension.php tells you the exact config key and which services it wires. Do not trust blog posts; the surface is tiny and version-sensitive.
4. First use case: keep production clients in your normal ClientManager (DB/Doctrine) and add a second manager that serves hardcoded clients for local dev or fixtures. Register both; the supervisor is what OAuth2ServerBundle actually injects into the authorization endpoint.

If you are starting fresh on modern PHP/Symfony, skip this and use league/oauth2-server or the maintained Spomky bundles directly — see Gotchas.

Implementation Patterns

Registering multiple client managers. Every manager is a regular service implementing the upstream ClientManagerInterface (from spomky-labs/oauth2-server-php). The supervisor collects them via a container tag — confirm the exact tag name in Resources/config/services.xml. The pattern is:

<service id="app.client_manager.api" class="App\OAuth\ApiClientManager">
    <tag name="oauth2_server.client_manager" />
</service>

<service id="app.client_manager.fixtures" class="App\OAuth\InMemoryClientManager">
    <tag name="oauth2_server.client_manager" />
</service>

The supervisor then delegates getClient($clientId) / createClient(...) to the first manager that returns a hit.

Ordering matters. Because the supervisor is a first-match chain, control order with the tag priority attribute (or rely on service definition order if the compiler pass sorts stably). Put deterministic/cheap managers (in-memory, config) before DB ones in tests, and the reverse in production.

Testing. This is the sweet spot for the pattern. Replace your DB manager with an in-memory one in config_test.yml by aliasing the production service to your fixture manager, leaving the tag wiring untouched:

# config_test.yml
services:
    app.client_manager.db:
        alias: app.client_manager.fixtures

Your functional OAuth2 tests then issue tokens against known clients without touching the database.

Decorating the supervisor. To add caching or logging without touching the bundle, decorate the supervisor service (alias the original ID to a .inner-style id and define your own). This is the cleanest extension point and avoids re-tagging managers.

Config-driven clients. If your clients rarely change, a single YAML-backed manager plus the supervisor (for the occasional dynamic client) is often simpler than a Doctrine manager — the supervisor makes the two coexist without code changes in the authorization endpoint.

Gotchas and Tips

• This package is effectively abandoned. Zero score, zero dependents, Symfony 2 era. There will be no security patches. If you inherit a project using it, plan a migration rather than extending it. The realistic replacements are FOSOAuthServerBundle (still Symfony 2/3 only), league/oauth2-server, or the current spomky-labs/oauth2-server packages, which fold a lot of these supervisor concerns into their own manager abstractions.
• Composer will mark it abandoned. Don't fight it; just ensure your composer.json pins a version and that CI doesn't fail on audit. Long-term, replace/vendor the 200 lines of logic if you must keep the behavior.
• It is not standalone. It expects SpomkyLabsOAuth2ServerBundle's services to exist. Loading it alone gives you a supervisor with nothing to supervise and confusing "no client manager" errors.
• Tag name and config key drift between minor versions. Always read Resources/config/services.xml and the Configuration.php in the installed version. There are very few public examples online, and most are for the underlying library, not the bundle.
• First-match delegation is silent. If a client ID is served by two managers, you get whichever is ordered first with no warning. Duplicate client IDs across managers is the classic production bug here — write a test that asserts an unknown client is rejected rather than falling through to a second manager's default.
• Debugging the wiring: in Symfony 2.x use app/console container:debug --tag=<tag> (or debug:container on 2.8+) to confirm which services were tagged and in what order. container:debug <supervisor_service_id> shows the injected arguments; a supervisor with an empty argument array is almost always a missing tag, not a missing service.
• Extension point: overriding service definitions in your app's services.yml after the bundle loads works, but ordering versus the bundle's compiler pass is fragile. Prefer a decorator or, if you control the managers, adding the tag directly to your own service definitions.
• PHP version: the bundle predates PHP 7 typed signatures. If you pin it into a modern codebase, run composer why-not early — you will likely hit transitive symfony/symfony version constraints that force the whole app back to 2.x.