Laravel Command Blocker Laravel Package

Getting Started

Install with Composer and let Laravel package discovery register the service provider. Publish the package config if the README provides a vendor:publish tag, then open the config file first; that is where the day-to-day control lives. Confirm whether rules are global, per-environment, or command-list based before adding anything.

A sensible first use case is a production/staging guard for destructive Artisan commands (migrate:fresh, db:wipe, queue:clear, etc.). After editing config, run php artisan config:clear and test one allowed and one blocked command. v1.0.1 is a patch release: it fixes failures when configured commands are not present, so it is the safer starting point for apps whose command set varies by environment or installed packages.

Implementation Patterns

• Environment-scoped protection: keep local permissive and block dangerous commands only in production/staging. Use the package config or App::environment()-based config values.
• Deploy/CI guard: include the package in deployment images and let it block destructive commands from interactive shells and CI jobs. Pair with php artisan config:cache during deploy.
• Feature-package tolerant lists: include commands from optional packages only if they exist in some environments; v1.0.1 handles absent commands instead of erroring.
• Custom commands: add app-specific destructive commands to the block list. Treat the block list as code-reviewed configuration.
• Testing workflow: add a console test that asserts a blocked command fails and an allowed command runs. Reset config cache in test setup if needed.
• Defense in depth: use DB credentials, filesystem permissions, and environment restrictions alongside the package; don't treat command blocking as a security boundary.

Gotchas and Tips

• v1.0.1 may silently ignore missing commands. That prevents crashes, but a typo in a blocked command name can also be ignored—verify names with php artisan list.
• Blocking applies to Artisan command execution; direct SQL, shell scripts, and OS-level commands can bypass it.
• Check exact matching behavior: canonical names vs aliases/signatures. Block the form users actually type.
• Command discovery is environment/package dependent. A command that exists locally may be missing in production; v1.0.1 is the release to prefer for that case.
• Config cache is a common source of confusion: after changing the block list, run php artisan config:clear or rebuild cache.
• Don't accidentally block deployment-critical commands (config:cache, route:cache, migrate --force) without testing the whole pipeline.
• Extension point: keep project-specific rules in the published config and review changes like any other production guard; avoid editing vendor files.