Connect Bundle Laravel Package

Getting Started

Read the archive notice first. This bundle is archived (last release 2019-09-25) and its backend service, SensioLabs Connect (connect.sensiolabs.com), is no longer operational. Before writing any code, confirm that assumption holds for your target environment — if it does, the honest "getting started" step is to stop and pick an alternative.

If you still need to evaluate it:

1. composer require sensiolabs/connect-bundle — expect this to fail or drag in Symfony 2.x/3.x components that conflict with a modern Laravel composer.json (PHP 8.x, illuminate/* 10/11).
2. Look at SensioLabs\Connect\ConnectClient — it is the only piece with portable value: getAuthorizationUrl(), getAccessToken($code), and api('me').
3. Look at SensioLabsConnectBundle and its DI extension — note that it registers a Symfony security firewall factory (connect), not a Laravel guard. This is the first hard stop.
4. Look at the controller/routing the bundle exposes — Symfony routing, not Laravel routes.

First real use case (Laravel): "Log in with SensioLabs Connect" on a Symfony community site. In Laravel you would not use this bundle; you would register a Laravel Socialite custom provider using league/oauth2-client against the same endpoints. The bundle's README is still useful as a spec for the OAuth exchange and the /api/me user shape.

Implementation Patterns

1. Port the flow to Socialite (the recommended pattern). Extend League\OAuth2\Client\Provider\AbstractProvider, point getBaseAuthorizationUrl() at https://connect.sensiolabs.com/oauth/v2/authorize and getBaseAccessTokenUrl() at the token endpoint, then register it with Socialite::extend('connect', ...). You get Laravel-native Socialite::driver('connect')->user() instead of a Symfony firewall.

2. Copy the bundle's client shape, not its classes. ConnectClient is a thin wrapper around the authorization-code grant plus an API client. Reproduce that shape in a small service class rather than trying to autoload the Symfony bundle into Laravel.

3. Keep identity in your own model. Map the Connect user payload (uuid, username, name, badges/certifications) into a local users + social_accounts table keyed on provider + provider_user_id. Never treat Connect's UUID as your primary key — you need to survive provider death, which is exactly what happened here.

4. If you run a hybrid Symfony + Laravel estate: Put the Connect integration in the Symfony app where the bundle natively works, then hand Laravel a signed token or a session cookie. Do not embed Symfony's HttpKernel inside Laravel to make the bundle load; the container/event-dispatcher coupling is not worth it for one OAuth flow.

5. Data-sync pattern instead of login. If you only want a user's badges/projects, prefer a queued job that pulls the public profile into a model on a schedule, tested with Http::fake(). This decouples you from their redirect flow (though not from the API being alive).

6. Testing. Http::fake() the token endpoint and /api/me, and snapshot the payload fixture. The bundle has no test helpers you can reuse from Laravel.

Gotchas and Tips

• No Laravel integration exists. No service provider, no config/connect.php, no php artisan vendor:publish, no facade, no guard. If a tutorial implies otherwise, it is for Symfony.
• The security firewall is the blocker. The bundle's value is a connect firewall factory in security.firewalls. Laravel has no equivalent config surface; bridging requires reimplementing the guard yourself, at which point you have written more code than a Socialite provider.
• Dead endpoints. The authorization redirect, token exchange, and API calls all target a decommissioned service. You will get DNS/connection failures, not clean 4xx responses, which makes "is my code wrong or is the service gone?" debugging annoying. Check the host resolves before blaming your code.
• Composer will fight you. Symfony 2/3 component constraints and PHP version bounds conflict with current Laravel. Forcing it with --ignore-platform-reqs tends to produce a broken autoloader, and both packages define overlapping PSR-4 roots only if you manually add the bundle namespace.
• Naming confusion. Packagist name is sensiolabs/connect-bundle; the README historically referenced SensioLabsConnectBundle and the namespace is SensioLabs\Connect\.... When grepping an inherited codebase, search all three.
• Inherited-project debugging. Check, in order: the firewall entry in config.yml, connect.client.id / connect.client.secret parameters, and the callback URL registered in the Connect app dashboard (now uneditable). A mismatch on the callback is the classic silent failure.
• Migration is the real work. If you have users whose only credential is Connect, you must move them to email/password or another IdP before the service is gone — the bundle cannot help, and there is no token to refresh.
• License is MIT, so copying logic is fine, but the portable logic is a standard OAuth2 authorization-code flow that league/oauth2-client and Socialite already implement better and with active maintenance.
• Extension points are moot. The bundle's useful seams (custom API client, event subscribers) are Symfony-typed and unreachable from a Laravel service container. Treat the package as documentation, not a dependency.