Weave Code
Authentication Bundle Laravel Package
smartbooster/authentication-bundle
SmartBooster Authentication Bundle is a PHP package that simplifies user authentication and access control, providing configurable login, registration, and security components to reduce boilerplate and speed up secure auth integration.
Common utils to handle user authentication
Frequently asked questions about Authentication Bundle
- Is smartbooster/authentication-bundle a Laravel package?
- No. Despite being listed alongside PHP and Laravel tooling, it ships as a Symfony bundle with a DI extension and bundles.php registration, so it will not drop into a Laravel application the way a package with a service provider would. Confirm your target framework before adopting it, because the integration steps differ substantially.
- How do I install smartbooster/authentication-bundle?
- Require smartbooster/authentication-bundle through Composer, pinning v1.1.3, then register the bundle in bundles.php and configure the mailer plus any services your admin extension relies on. The v1.1.3 release note implies no schema migrations, routing changes, or config changes. Resolve and validate the dependency set against your application lockfile in a non-production environment first.
- What does SendAccountCreationEmailTrait actually do?
- It encapsulates the admin.extension.action_send_account_creation_email behavior so host applications can compose the send account creation email action into admin extension classes instead of reimplementing it on every surface. It is a thin convenience layer over existing account-creation and mailer flows, not a replacement for your core authentication stack. Adoption is per admin extension class, so you can scope it to one surface at a time.
- Which Symfony and PHP versions does this bundle support?
- The published evaluation does not record the exact version constraints, so read the composer.json in the repository for the supported PHP and Symfony matrix before installing. Also confirm that transitive dependencies such as admin extension packages and the mailer resolve cleanly in your application's lockfile. Treat that check as the first step of any integration spike.
- Does upgrading from v1.1.2 to v1.1.3 break anything?
- v1.1.3 is patch-level and additive: it introduces the trait without deprecations or removals, so no breaking change is signaled. Downgrading is equally safe while the trait remains unused. A broader backward-compatibility policy for patch versus minor releases is not documented, so ask the maintainers if you need long-term stability guarantees.
- What must be configured before using the trait?
- You need a working mailer transport, an account-creation service or flow, and the admin extension mechanism that exposes the action_send_account_creation_email action. Confirm whether the mailer abstraction is Symfony Mailer or legacy Swiftmailer before committing. Without those pieces in place, the trait has nothing to compose into.
- Is the trait opt-in, or does registering the bundle change admin behavior?
- The trait itself is strictly opt-in: you include it in an admin extension class when you want the send account creation email action. However, registering the bundle may still affect default admin behavior indirectly, so verify in a non-production environment whether any actions appear or change. The release note only describes the additive trait.
- Can I use this package in a Laravel application?
- Not directly. It is a Symfony bundle, so using it from Laravel would require an adapter layer, and the assessment explicitly flags this as a stack mismatch. Budget for an adapter only if you genuinely need this specific action contract; otherwise prefer a Laravel-native authentication package. Forcing the bundle into a Laravel estate is not recommended.
- How should I test the account creation email flow?
- Wire the trait into a single admin extension class in a non-production environment and validate email delivery, templating, and error paths end to end. Check whether the trait has test coverage and an explicit contract covering method names, return values, and exceptions before spreading it across surfaces. Keeping adoption isolated to one class makes removal trivial if the contract proves unsuitable.
- What are the main risks and alternatives?
- Overall risk is low: the change is patch-level, additive, and comes from a small-maintainer OSS project with low churn. Residual risks include trait name or behavior collisions with in-house traits and implicit coupling to the admin extension action contract and mailer configuration. Alternatives are your own account-creation action implementation or a framework-native package; once validated, codify the pattern in your platform template so future admin extensions inherit it consistently.
Weaver
How can I help you explore Laravel packages today?