Multi User Bundle Laravel Package

Getting Started

• Treat this as legacy-only. The package is archived, last released 2015-04-27, and built as a profile layer on top of FOSUserBundle. Do not add it to a new Symfony application; use it only when inheriting an existing Symfony 2.x/FOSUserBundle codebase.
• Look first at the README, then DependencyInjection/Configuration.php for the config tree, Resources/config/*.xml for service IDs, and the bundle’s user-discriminator/profile services. Read FOSUserBundle’s docs too, because most behavior is inherited from it.
• In a legacy app, pin PHP/Symfony/FOSUserBundle versions in composer.json before requiring rollerworks/multi-user-bundle. Avoid broad composer update; this package’s constraints are from the Symfony 2 era.
• First practical use case: two user audiences, such as customer and admin, each with its own firewall, user class, registration/login routes, forms, and templates.
• Use config:dump-reference rollerworks_multi_user, debug:router, and debug:container early. They reveal the actual profile service IDs, route names, and firewall mappings.

Implementation Patterns

• Model one profile per user type. Configure each profile with a stable name, matching firewall, user class, form types, templates, and route prefix. Treat the profile name as part of your public contract because it appears in service IDs, routes, and sometimes session/token resolution.
• Use Doctrine inheritance for user classes: a base User entity with a discriminator column and subclasses per profile. The bundle’s discriminator field must be persisted, non-null, and immutable after creation.
• Give each profile its own security firewall, provider, and context. Add access_control rules by URL prefix, and avoid sharing a security context between profiles that use different user classes.
• Use unique route prefixes and route-name prefixes per profile. FOSUserBundle route names are global by default, so collisions are easy. Verify with debug:router.
• Keep registration/profile forms per profile. Do not expose the discriminator field in shared forms. Use profile-specific form types and templates, or app-level template overrides keyed by firewall/request.
• Put shared behavior in a base entity or service and profile-specific behavior in subclasses/services. Hook FOSUserBundle events such as registration confirmation and password reset, resolving the active profile from the firewall/request.
• Test each firewall functionally: login, registration, password reset, access denied, and token provider key/user class assertions. Keep fixtures for every profile.
• Isolate bundle usage behind app-level controllers/services so it can later be replaced by native Symfony multiple firewalls/providers.

Gotchas and Tips

• The package is discontinued: no security fixes, no modern Symfony support, and effectively no dependents. Pin dependencies and plan a replacement rather than trying to modernize it in place.
• Firewall/profile mismatch is the most common failure. The profile’s firewall must match the security firewall name, otherwise user-class resolution, route generation, and token refresh can select the wrong profile.
• Backfill the user discriminator before enabling profiles. Changing a user’s discriminator later will break provider lookup or log them out.
• Route and email-link collisions are common. Confirmation and password-reset emails must generate URLs for the correct profile/firewall, not the default FOSUserBundle route.
• Overriding global FOSUserBundle services affects every profile. Prefer profile-specific service overrides or decoration. Use debug:container to find the real IDs.
• Set distinct security context values per firewall. Sharing remember-me/session context between profiles can authenticate a customer as an admin or silently fail token refresh.
• Custom DQL, repositories, and raw SQL must respect Doctrine inheritance/discriminator filtering. Batch jobs and reports often bypass it.
• Debug with security logging, the profiler Security panel, debug:event-dispatcher, and the user-discriminator service state. Reproduce failures with one firewall at a time.
• Extension points are custom user discriminators, per-profile controllers/forms/templates, and FOSUserBundle event subscribers. Documentation is thin and examples are old, so read the source.
• For new work, use native Symfony security with multiple firewalls/providers and custom user providers. FOSUserBundle itself is abandoned; migrate profile by profile behind adapters.