Weave Code
Manual Auth Bundle Laravel Package
ruwork/manual-auth-bundle
Symfony bundle for manually authenticating users through Symfony Security, simplifying programmatic login flows such as custom sign-in, impersonation, or session-based authentication without extra boilerplate.
[READ-ONLY] Subtree split of the Ruwork Manual Auth Bundle
Frequently asked questions about Manual Auth Bundle
- Can I install ruwork/manual-auth-bundle in a Laravel application?
- No. Despite appearing in Composer package lists, ruwork/manual-auth-bundle is a Symfony bundle, not a Laravel package. It has no service provider, no Laravel config publishing, and depends on Symfony Security internals rather than Laravel's auth manager. Installing it in a Laravel app gives you an unused dependency and likely Composer constraint conflicts. Use Laravel's native auth APIs instead.
- What does ruwork/manual-auth-bundle actually do?
- It is a Symfony bundle that authenticates a user through the Symfony Security component without going through credential verification, which simplifies programmatic login flows. Typical uses are custom sign-in endpoints, impersonation helpers, and session-based login shortcuts. It is a thin wrapper around what Symfony already exposes, not a full authentication system. Read the source before relying on it, because the README is minimal and the behavior depends entirely on how it hooks into the firewall.
- What is the Laravel equivalent of ruwork/manual-auth-bundle?
- Laravel ships this capability natively. Use Auth::login($user) or Auth::loginUsingId($id) inside a controller or middleware, and wrap it in your own authorization check. A small custom guard plus middleware covers the rest, typically 50 to 150 lines including tests. You do not need a third-party package for this.
- Which Symfony and PHP versions does ruwork/manual-auth-bundle support?
- The last release was 2018-05-06, which places it in the Symfony 3.4 and 4.0 era with PHP 7.1 to 7.2. Symfony deprecated the Guard component in 5.3 and removed it in 6.0, so if the bundle relies on Guard or the old AuthenticationProviderInterface, it will not boot on Symfony 6 or 7. Check composer.json before making any decision. Assume a port is mandatory on modern Symfony or PHP 8.2 and above.
- Is ruwork/manual-auth-bundle still maintained?
- No. The repository is archived, has zero stars and zero dependents, and has not been updated since 2018. There is no maintainer to issue patches and no security advisory feed watching it. Its dependency constraints will drift further out of sync with modern symfony/security-bundle and PHP releases with every framework upgrade.
- Is it safe to use ruwork/manual-auth-bundle for impersonation in production?
- Treat it as high risk. The bundle's entire purpose is to bypass credential verification, so a config drift or a missing environment gate turns it into an account-takeover vector. An unmaintained package gives you no patch path if a flaw is found. For impersonation, prefer Symfony's built-in switch_user firewall, which is maintained and audited. If you must keep the bundle, add a written exception and an automated assertion that it is disabled outside non-production.
- How do I port ruwork/manual-auth-bundle to Symfony 6 or 7?
- Extract the behavior from the source and rewrite it as a native authenticator implementing AbstractAuthenticator with a Passport and the appropriate badges. The logic is small, so reimplementation is usually faster than a fork. If you do fork, copy it into a private repository, port it to the current authenticator API, pin the version, and add a security test. Budget roughly two to five engineer-days for the reimplement path.
- Why does composer require ruwork/manual-auth-bundle fail with dependency conflicts on PHP 8.2?
- The package was published against Symfony 3.4 and 4.0 era constraints and PHP 7.1 to 7.2. Modern symfony/security-bundle and PHP 8.2 cannot satisfy those transitive requirements, so Composer refuses to resolve. Widening the constraints yourself is not a real fix, because the code may still call removed Guard APIs at runtime. Reimplement the behavior instead of fighting the resolver.
- How should I test that manual login is disabled outside development?
- Write a functional test that hits the login route or invokes the service in a non-dev environment and asserts the user is not authenticated. Gate the feature behind an explicit config flag plus an environment check, and fail closed when the flag is absent. Run that test in CI on every build so a config change cannot silently enable it. Also assert the route or service is not registered at all in production.
- What are the alternatives to ruwork/manual-auth-bundle?
- On Symfony, use the switch_user firewall for impersonation, the login-link handler for passwordless flows, or a dev-only firewall with security set to false. On Laravel, use Auth::login() and Auth::loginUsingId() behind a policy or gate, or a maintained impersonation package such as lab404/laravel-impersonate. All of these are supported and receive security updates. Reimplementing the roughly 100 lines of logic yourself is often the cleanest option overall.
Weaver
How can I help you explore Laravel packages today?