Weave Code
Multi User Bundle Laravel Package
pugx/multi-user-bundle
PUGX MultiUserBundle extends FOSUserBundle so Symfony applications can support several distinct user types. It provides separate user entities with shared registration, login, form, controller, and profile handling, simplifying multi-role account management without duplicating authentication code.
An extension for FOSUserBundle to handle users of different types. Compatible with Doctrine ORM.
Frequently asked questions about Multi User Bundle
- Can I install pugx/multi-user-bundle in a Laravel application?
- No. Despite being listed alongside Laravel packages, pugx/multi-user-bundle is a Symfony bundle that depends on FOSUserBundle, Symfony's security firewall, the DI container, and the event dispatcher. A Laravel app cannot consume it meaningfully through Composer. Treat it as a design reference and reimplement the pattern natively in Laravel.
- What does PUGXMultiUserBundle actually do?
- It extends FOSUserBundle so a Symfony application can support several distinct user types with separate entities but one shared authentication surface. A user discriminator maps a single login form to N user classes, delegating registration, profile editing, and password reset per type. The goal is multi-role account management without duplicating controller and form code.
- Which Symfony, PHP, and Doctrine versions does it support?
- It targets the Symfony 2.x/3.x era and expects FOSUserBundle, which is itself unmaintained. The code is PHP 5.x/7.0-era, so Composer 2 and modern PHP versions will likely refuse dependency resolution outright. Doctrine ORM is the supported persistence layer; other Doctrine mappings are not part of the stated scope.
- Is pugx/multi-user-bundle still maintained?
- No. The repository is archived, has no active maintainer, and shows effectively no community footprint, so there is no security patching path. Any CVE affecting the bundle or its FOSUserBundle dependency becomes your responsibility to fix in a fork. That alone rules it out as a production dependency for authentication.
- Is it safe to use for authentication in production?
- Authentication is the highest blast-radius domain in any application, and adopting unmaintained auth code is a risk you own entirely. There is no CVE feed, no patching cadence, and no maintainer to escalate to. If you must run it on a legacy Symfony stack, freeze the dependency, name an owner for the fork, and budget a security review before adoption rather than after.
- How do I implement multiple user types in Laravel without this package?
- The recommended approach is a single users table with a user_type column plus a custom UserProvider that scopes resolution by type, combined with per-type guards and policies. This has the lowest operational cost and is sufficient unless your user types have materially divergent schemas. A two to three day design spike reproducing the discriminator and provider pattern is enough to validate the shape.
- What is the multi-table chained provider pattern and when should I use it?
- Instead of one table with a type column, each user type gets its own table, and a delegating provider tries each type's Eloquent provider in order until one resolves the credentials. This mirrors the PUGX model more closely and suits genuinely heterogeneous actors such as patients, clinicians, and admins with different fields. The tradeoff is higher migration and query complexity, so only choose it when schemas really diverge.
- How much work is a native reimplementation or migration?
- A design spike takes roughly two to three days, and a production-grade implementation lands around one to two sprint-weeks. Budget feature tests covering login, registration, password reset, and profile edit for every user type, because discriminator and mapping errors surface at login rather than at boot. On a legacy Symfony app, inventory user classes and discriminator mappings before planning the framework upgrade.
- What are the alternatives to PUGX MultiUserBundle?
- On modern Symfony, native UserProviderInterface with ChainUserProvider or MakerBundle-generated security already covers the use case the bundle was written to solve. On Laravel, use native guards, polymorphic authenticatables, or a user_type discriminator with a custom UserProvider. Avoid carrying FOSUserBundle forward in any scenario, since it is unmaintained as well.
- My legacy Symfony app already depends on it. What is the migration path?
- Freeze the dependency, inventory every user class and the discriminator mapping, then port to Symfony's native chain providers as part of your next framework upgrade. Do not attempt to carry FOSUserBundle forward into a modern Symfony release. Assign a named maintainer for the interim fork and give the security team a review budget before you commit to the timeline.
Weaver
How can I help you explore Laravel packages today?