Dreamcommerce Sso Client Bundle Laravel Package

Getting Started

This bundle is a thin Symfony 2 bridge around the DreamCommerce SSO client. It has no stars, no dependents, and no visible community, so treat the source as the documentation.

1. Confirm the package is installable. Check Packagist for mijndomein/dreamcommerce-sso-client-bundle and its version constraints before writing code against it. If it is not published, add the GitHub repository as a VCS source in composer.json and pin a specific commit.

   composer require mijndomein/dreamcommerce-sso-client-bundle
   

2. Register the bundle in app/AppKernel.php:

   $bundles = [
       // ...
       new DreamCommerce\Bundle\SSOClientBundle\DreamCommerceSSOClientBundle(),
   ];
   

   The exact class name is the first thing to verify — open the repository root and find the *Bundle.php file.
3. Import routes if the bundle ships any. Look for Resources/config/routing.yml or routing.xml and import it in app/config/routing.yml. If it only provides services, skip this.
4. Configure it. Read DependencyInjection/Configuration.php to find the configuration root key and the supported options. It will look roughly like:

   # app/config/config.yml
   dreamcommerce_sso_client:
       client_id:     "%sso_client_id%"
       client_secret: "%sso_client_secret%"
       redirect_uri:  "%sso_redirect_uri%"
       # endpoint/base_url options as defined by the bundle
   

   Put credentials in parameters.yml (or environment-specific config), never in the committed bundle config.
5. Where to look first, in order:
   • README.md — if it exists at all.
   • DependencyInjection/Configuration.php — the authoritative list of options.
   • DependencyInjection/*Extension.php — how config maps to service arguments.
   • Resources/config/services.yml — service IDs you will inject or override.
   • The bundle class — whether it registers a compiler pass or a security listener.

First use case: inject the SSO client service into a controller and perform the login redirect. The smallest useful slice is:

public function loginAction()
{
    return $this->redirect($this->get('dreamcommerce_sso_client')->getAuthorizationUrl());
}

Then a callback route that exchanges the returned code/token for an identity. Get that round trip working against a sandbox before touching Symfony's security layer.

Implementation Patterns

Inject the client, never instantiate it. The bundle exists to give you a configured service. Use constructor injection in your own services (or $this->get(...) in a Symfony 2 controller) and let the bundle own credentials and HTTP configuration. This also makes the client mockable in tests.

Keep a three-step controller flow.

1. loginAction — generate state, store it in the session, redirect to the IdP.
2. callbackAction — validate state, exchange the code/token for a user identity, then either log the user in or hand off to your own user provisioning.
3. logoutAction — clear the local session and, if the IdP supports it, redirect to its logout endpoint.

Bridge into Symfony security deliberately. Symfony 2 predates Guard, so you have two realistic options:

• A custom authentication listener/provider registered under security.firewalls, or
• A simpler controller-based approach using SecurityContext::setToken() with a UsernamePasswordToken after you have resolved the local user.

Whichever you pick, isolate it in one service so the rest of the app never talks to the SSO client directly:

class SsoAuthenticator
{
    public function __construct(SsoClient $client, UserProviderInterface $users, TokenStorageInterface $tokenStorage) { ... }

    public function authenticate($code)
    {
        $identity = $this->client->fetchIdentity($code); // adapt to actual API
        $user = $this->users->loadUserByUsername($identity->getEmail());
        $this->tokenStorage->setToken(new UsernamePasswordToken($user, null, 'main', $user->getRoles()));
    }
}

Map SSO identity to local users explicitly. Decide up front whether SSO users are auto-provisioned or must already exist. Auto-provisioning needs a strategy for collisions (email already registered locally) and for attribute changes (name, roles) on every login. A small UserManager service that does "find or create, then sync" keeps this out of the controller.

Configuration stays environment-specific. The redirect URI in particular is almost always different per environment (localhost vs staging vs production). Drive it from parameters.yml and set it in the IdP's client registration for each environment.

Override bundled services by ID. If you need a different HTTP client, base URL, or logging, redeclare the bundle's service ID in your app's services.yml (or use a compiler pass). That is the intended extension point for a Symfony 2 bundle and avoids forking.

Test the seam, not the bundle. Unit-test your authenticator with a mocked client service. Integration-test only the callback route, using a stub that returns a fixed identity. You will never get good test coverage inside a third-party bundle you do not control.

Gotchas and Tips

• Symfony 2 is end-of-life. Support ended in 2019. This bundle is not a long-term dependency; plan to replace it when you move to Symfony 5/6. The cheapest insurance is the adapter interface above, so the rest of the app depends on your SsoAuthenticator rather than the bundle's client class.
• Zero adoption signals. No stars, no dependents, and no observable CI means you are the first serious consumer. Read every line of DependencyInjection/ before trusting a config key; do not infer option names from the README.
• Service visibility. In Symfony 2, services default to public, so $this->get('...') in a controller usually works. If the bundle marks services private (or you upgrade later), switch to constructor injection immediately rather than fighting the container.
• Redirect URI mismatches are the number-one SSO failure. Trailing slashes, http vs https, port numbers, and www vs apex all count. Register every environment's exact URI at the IdP and mirror it byte-for-byte in config.
• Implement and validate state yourself. Do not assume the bundle does CSRF protection on the callback. Store a random value in the session at login, compare it at callback, and fail closed.
• Catch transport exceptions. A timeout or 5xx from the IdP should produce a friendly "could not sign you in" page, not an uncaught exception on your login route. Wrap client calls in your authenticator and log the underlying error with a correlation ID.
• Session collisions in development. Sharing one browser across localhost apps on the same domain can leave stale SSO state. Clear cookies/session when debugging the callback, and use distinct cookie names per app.
• No logging out of the box. The underlying client likely logs nothing useful. Add a decorator around the client service that logs request URLs (never secrets) and response statuses; you will need it the first time a callback mysteriously fails.
• Treat the underlying dreamcommerce SSO client as the real dependency. When debugging behavior, drop down into that package's source and version — the bundle is only wiring. Pin both versions in composer.json and review changelogs before bumping.
• Fork-friendly. Given the maintenance profile, assume you may need to fork. Keep your changes in your own services and configuration rather than patching vendor code, so a fork stays a last resort.