Weave Code
Sudo Su Laravel Package
viacreative/sudo-su
SudoSu is a Laravel package that lets developers quickly log in as any user for testing and debugging. It provides a simple sudo-su page and route for switching accounts without passwords, making it easy to verify permissions and user-specific behavior in development.
Laravel package to easily login as other users during development.
Frequently asked questions about Sudo Su
- How do I install viacreative/sudo-su in a Laravel app?
- Install it with Composer using composer require viacreative/sudo-su, then let Laravel service-provider auto-discovery register the package. Publish any config or assets if your version requires it. In the current release, add the sudosu::user-selector Blade partial to the layouts where you want the selector, guarded by config('app.debug') or an equivalent local-only check. Test the sudo-su route in a development environment before relying on it.
- Why is the sudo-su user selector not showing after composer update?
- The 1.1.0 release is a behavior-removing change: sudo-su no longer injects its markup and assets automatically. You must add the sudosu::user-selector include to each layout where the selector should appear. If you use env('APP_DEBUG') in the guard and run with cached config, the check may evaluate falsy and hide the selector. Use config('app.debug') instead and clear or rebuild cached config.
- Should I use env('APP_DEBUG') or config('app.debug') in the sudo-su Blade include?
- Use config('app.debug') rather than env('APP_DEBUG') inside Blade templates. Direct env() calls are unreliable once php artisan config:cache has run, because cached config bypasses the real environment lookup. If APP_DEBUG evaluates falsy under cached config, the sudo-su selector will not render and you may get confusing works-on-my-machine reports. The release note snippet uses env(), but the safer host-side guard is config('app.debug').
- Is viacreative/sudo-su safe to use in production?
- sudo-su is developer tooling for impersonating users during development, so it should not be exposed in production. The new integration model moves the production guard into your application code, so the safety control is the Blade include condition and route protection. Only include the selector behind a local or debug environment check, and verify that the impersonation route is not reachable in production. Do not copy the include into a shared layout without a guard.
- How do I log in as another user with sudo-su?
- sudo-su provides a sudo-su page and route for switching accounts without passwords during development. After installation and configuration, open the sudo-su page or use the user selector partial to choose the target user. The current release requires you to add the sudosu::user-selector Blade include to your layout rather than relying on automatic injection. Confirm the route and selector work only in your local or development environment.
- Does viacreative/sudo-su support Laravel 9, 10, and 11?
- The technical evaluation assumes Laravel 9+ with Blade layouts and standard service-provider auto-discovery. It does not provide a formal version support matrix, so check the package composer.json constraints and README for exact Laravel compatibility. Test on your target Laravel version, especially if you use config caching or need to publish assets. If you are on a newer major version, verify the include and asset workflow before upgrading.
- How do I restrict sudo-su to authorized developers?
- Use an environment guard so the selector and route are available only in local or debug environments. The evaluation notes that authorization gates appear unchanged, but the release note does not clarify whether the partial itself checks who may impersonate. Do not rely on the partial alone; verify the gate configuration and wrap the include in a debug or local-only condition. Remove or disable the impersonation route in production.
- What changed in viacreative/sudo-su 1.1.0?
- Version 1.1.0 removes automatic injection of the user-selector markup and supporting assets. Host applications must now add the sudosu::user-selector Blade partial to the layouts where the selector should appear. The evaluation treats this as a breaking change despite the 1.1.0 version number, because developers on a ^1.0 constraint can silently lose the selector after composer update. The release note also does not fully clarify the asset publishing story or authorization behavior.
- How should I upgrade sudo-su without breaking local development?
- Treat the upgrade as breaking even though it is published as 1.1.0. Pin the current version in composer.json before your next dependency refresh, then add the sudosu::user-selector include to every layout where you need it. Use config('app.debug') as the guard, publish or register assets if your version requires it, and test with php artisan config:cache enabled. Audit multi-tenant or white-label applications that have several layout roots.
- What are alternatives to sudo-su for Laravel user impersonation?
- Alternatives include dedicated impersonation packages such as lab404/laravel-impersonate or a custom guarded route and action that logs in as another user. sudo-su is development-focused and now relies on you to include its selector and guard it in application code. Choose an alternative if you need production-grade controls such as explicit authorization and audit logging. For simple local debugging, a custom dev-only route can also be enough.
Weaver
How can I help you explore Laravel packages today?