Vanio User Bundle Laravel Package

Getting Started

This is a Symfony2-era bundle, not a Laravel package. If you're coming from Laravel, map the concepts roughly to laravel/socialite (HWIOAuthBundle side) + laravel/breeze/fortify (FOSUserBundle side). Before installing anything, verify the project is actually on Symfony 2.7/2.8 — this bundle will not work on Symfony 3+, let alone 4/5/6. Given it has ~1 star, zero dependents, and no recent activity, treat it as a reference for reading source, not a foundation for new code.

Minimal steps:

1. Baseline dependencies first. You need FOSUserBundle (~1.3|~2.0) and HWIOAuthBundle (~0.6) already wired up. The bundle assumes both are present.
2. Install via Composer (composer require vanio/vanio-user-bundle:dev-master — no stable tags worth relying on). This will pull/expect old versions of Doctrine, Symfony, and the two peer bundles.
3. Register in app/AppKernel.php (after FOSUser and HWI):

   new Vanio\UserBundle\VanioUserBundle(),
   

4. Look first at Resources/config/ (services + defaults), then Model/ (the base User you're meant to extend), then DependencyInjection/ (what config keys it actually honors).
5. Create your User entity extending the bundle's base model and map it with Doctrine. Point fos_user.model.user.class (or the bundle's equivalent config) at it.
6. First real use case: enabling "sign in with Google/GitHub" alongside email/password, where an OAuth callback either logs in an existing linked user or creates/links one. Confirm the default security.yml firewall chain from the bundle's docs before writing your own — that chain is where most of the "sane defaults" live.

Implementation Patterns

Extend the base model, don't fork it.

class User extends Vanio\UserBundle\Model\User
{
    // your extra fields, relations, timestamps
}

Keep the bundle's fields (username, email, enabled, social IDs) intact; the FOS/HWI bridges read them via getters/setters.

OAuth login vs. OAuth linking. The typical workflow the bundle targets:

• hwi_oauth_connect firewall path → user is already authenticated, callback links a provider account to the current user.
• Regular hwi_oauth path → callback looks up by provider user id, falls back to email match, else creates a user (often "disabled" pending email confirmation).

Use these two distinct firewall/path configurations rather than inventing a custom controller — that's the whole point of the bundle.

Registration flow. If you need custom registration, extend the FOSUser RegistrationFormType and the controller's form handling; the bundle mostly supplies defaults and templates. Override templates under app/Resources/VanioUserBundle/views/ (and FOSUserBundle/HWIOAuthBundle overrides similarly) rather than editing vendor files.

Integration tips.

• Subscribe to FOS events (FOSUserEvents::REGISTRATION_CONFIRM, SECURITY_IMPLICIT_LOGIN) for post-registration logic such as creating profiles or sending transactional mail.
• Keep provider names in config.yml (e.g. google, github) exactly matching the resource owner service ids and the paths in routing.yml — the bundle wires these by string.
• For "same email, different provider," decide explicitly whether to auto-link or force an auth challenge. The bundle's default behavior here is the thing you'll most likely override.
• If migrating logic forward to a modern Symfony app, the port targets are KnpUOAuth2ClientBundle + symfony/security-bundle's authenticator system + symfonycasts/reset-password-bundle — read this bundle's Model/ and connect controller as a spec.

Gotchas and Tips

• It's abandoned and version-locked to Symfony 2. No Symfony 3+ support, PHP 7 typed code will break it, and peer constraints will fight modern Composer. Do not start a project on it.
• Zero dependents and ~1 star mean no community safety net: no StackOverflow answers, no issue triage, no security patches. Budget time to read the source.
• Order matters in AppKernel and security.yml. Register VanioUserBundle after FOSUser and HWI; put the connect firewall before the main OAuth firewall, otherwise linking silently routes to login.
• Doctrine inheritance is the #1 source of "user not found" bugs. Make sure the mapped superclass config and fos_user.resetting.token_ttl, registration.confirmation.enabled, and your entity's table name all line up. A missing @ORM\Table on the concrete entity frequently produces duplicate-table or missing-column errors during doctrine:schema:update.
• HWIO callback/redirect URI mismatches are 90% of OAuth failures. Check the profiler's request log, confirm redirect_uri in the provider console exactly matches the route generated by hwi_oauth_redirect, and confirm the resource owner's client_id/client_secret are read from the right config node.
• Config keys are sparse and loosely documented. Grep DependencyInjection/Configuration.php before assuming a key exists; unknown keys are dropped silently by Symfony's config tree in some versions.
• Extension points: override the bundle's services (app/config/services.yml with the same id), override forms and templates, and listen to FOS/HWI events. Avoid subclassing controllers — the bundle predates final controller classes and that pattern will bite you during upgrades.
• If you're genuinely in a Laravel codebase, stop here: use laravel/socialite + laravel/fortify (or Breeze with social login) instead. Port the flow (register → confirm → link provider) rather than the code.