User Security Check Extension Laravel Package

Getting Started

This is a PyroCMS/Streams Platform extension (anomaly/* namespace), so treat it as an addon to the Users module rather than a standalone Laravel package.

1. Install: composer require anomaly/user_security_check-extension. Because the package has effectively no dependents, verify the required anomaly/streams-platform and anomaly/users-module versions in the package's composer.json before pulling it into a real project.
2. Register the addon: On the Streams Platform, extensions are registered through the addon service provider. Check src/UserSecurityCheckExtensionServiceProvider.php (or similarly named provider) and confirm it is picked up by the addon manifest. If auto-discovery is not supported by your platform version, add it manually to the addon list.
3. Publish and migrate: Run the usual php artisan addon:publish / php artisan migrate flow. Inspect resources/migrations/ first — any table or column added here is the contract you'll be working against.
4. Look here first: src/ for the service provider and any check classes, config/ for tunables, resources/lang/ for the labels surfaced in the admin UI, and resources/views/ if there's an admin panel override.
5. First use case: Enable the addon, then exercise the user creation and password-change flows in the control panel. The most likely behavior is a security validation hooked into those flows (password rules, compromised-password checks, or login-attempt safeguards). Confirm what it actually intercepts before wiring it into production.

Implementation Patterns

Hook into the Users module lifecycle. The natural usage is to let the extension subscribe to user creation/update events rather than calling it directly. Register listeners in the addon service provider and keep the extension's logic behind those events so the Users module stays untouched.

Wrap the check as a validation rule. If the extension exposes a check class, wrap it in a custom Laravel validation rule and attach it to your registration/password-reset form requests. This makes the behavior testable and keeps it out of controllers.

class SecurePassword implements Rule
{
    public function passes($attribute, $value)
    {
        return app(UserSecurityCheck::class)->passes($value);
    }
}

Middleware for login-time checks. If the extension evaluates login attempts or session state, register its middleware in the web or auth group in app/Http/Kernel.php. Keep it after StartSession and after your authentication middleware so the user context is available.

Admin-panel surface. Streams Platform addons often expose a settings section. If this one does, centralize configuration in config/user_security_check.php and read it via config() rather than hardcoding thresholds — that also gives you a clean override path per environment.

Scheduled enforcement. For periodic reevaluation (e.g., re-checking stored hashes against an updated policy), register an artisan command in the addon provider and schedule it in Kernel::schedule. Keep the job idempotent — you don't want repeated notifications on every run.

Testing pattern. Boot the addon provider in your test suite ($this->app->register(...)) and write feature tests against the registration endpoint. Since there's no upstream test coverage of note, your tests are the only regression net you'll have.

Gotchas and Tips

• Version compatibility is the biggest risk. With 1 star and 0 dependents, expect it to be pinned to an older Streams Platform / Laravel release. Check composer.json constraints and run composer why-not before upgrading your app.
• Abandonment. Assume no upstream fixes. Fork it and vendor the fork, or copy the relevant check into your own codebase if it's small — the value here is likely the policy logic, not the plumbing.
• Migration ordering. Addon migrations can collide with the Users module's tables. Always run migrations in a fresh environment first and review the migration's up() before touching production.
• Service provider not loading. If the addon "installs" but does nothing, the provider is almost certainly not registered. Check config/app.php providers, the addon manifest, and run php artisan config:clear.
• Config caching. php artisan config:cache will mask changes to the addon config file. Clear the cache whenever you adjust thresholds, or read values via env() in the config file only.
• Silent validation failures. Because the check likely hooks into form validation, a misconfigured rule may fail open. Add explicit tests asserting rejection of known-bad input, not just acceptance of good input.
• Event hook points are the extension surface. The cleanest customization is to listen to the same Users-module events the extension listens to and layer your own logic alongside it, rather than editing vendor files.
• Logging. Add a dedicated log channel for security-check decisions. If a user is blocked at registration, you want a record of which policy fired and with what config — otherwise debugging is guesswork.
• Don't rely on the admin UI alone. Whatever the Streams settings screen writes should be reproducible from config, so environments can be provisioned without clicking through the panel.

Given the package's maturity level, treat it as a reference implementation of a user security check rather than a dependency. Read the source, extract the policy, and decide whether to adopt, fork, or reimplement before committing it to a production stack.