Blocked Security Check Extension Laravel Package

Getting Started

This is a single-purpose extension for the Streams Platform (PyroCMS) security-check system: it hooks into the login flow and blocks users who are flagged as suspended. With one star and zero dependents, treat it as unmaintained sample code rather than a supported dependency — read the source before you ship it.

1. Install alongside a matching host. It is only meaningful if you already run anomaly/users-module on the Streams Platform. Pull it with composer require anomaly/blocked_security_check-extension from a project whose composer.json already pins the platform, or drop the folder into addons/anomaly/blocked_security_check-extension/ for a manual install and run php artisan addon:install anomaly.extension.blocked_security_check-extension.
2. Look first at three files — the service provider, the security check class (the one implementing SecurityCheckInterface / extending the base check), and lang/en/addon.php (or resources/lang). The provider tells you what is registered, the check class is the whole feature, and the language file is where the denial message lives.
3. First use case: stop suspended accounts at login. In the admin, open Users → Security and confirm the new check appears in the list; enable it. Then suspend a test user and try to log in — you should see the check's message instead of a session.

Note the naming inconsistency: the package is anomaly/blocked_security_check-extension but the repository is suspension_security_check-extension. Verify the actual addon namespace/slug from composer.json (extra.pyro or extra.streams) before running install commands, because the dotted addon path must match exactly.

Implementation Patterns

Treat the check as one node in the login pipeline. The Streams security system collects checks and evaluates them on each attempt; this extension contributes a single rule. That means it coexists with captcha, throttling, and two-factor rather than replacing them — order and enablement are managed centrally in the users module config, not in this package.

Suspension state is the source of truth. The check reads the user's suspension flag/expiry from the users module and returns a failure with a localized message when active. Do not duplicate that state in your own tables; drive suspension through the users module's admin actions (or $user->suspend()-style calls) so the check sees it.

Custom denial messaging. Swap or extend lang/en/... to match your product tone, and override the view if the package ships one. If you need per-role wording, subclass the check and register your subclass in the provider rather than editing vendor files.

Pair it with notifications. A common day-to-day workflow is: admin suspends a user → listener on the suspension event emails the user with an appeal link → this check blocks the login until an admin clears the flag. Put the listener in your own addon, not in this extension.

Testing. Write a feature test that boots the security check collection with a suspended user and asserts the failure response, plus one with an active user asserting pass-through. Because the package has no test suite of its own, this is your only regression net when the platform updates.

Gotchas and Tips

• Maintenance risk is the headline gotcha. One star, zero dependents, NOASSERTION license. Confirm the license file before commercial use, and vendor-lock or fork it into your own namespace so a Packagist disappearance does not break installs.
• Namespace/slug mismatch between package name (blocked_security_check-extension) and repository (suspension_security_check-extension) is the most likely cause of "addon not found" during addon:install. Inspect composer.json and the directory name under addons/.
• Check enablement is easy to forget. Installing the addon does not necessarily activate the check. Look in the admin security settings and in the users module config for an explicit toggle.
• Message clarity matters for support load. A suspended user who sees a generic "login failed" will file tickets. Make the localized message explicitly say the account is suspended and when/if the suspension lifts (if the users module exposes an expiry).
• Don't rely on the check for enforcement alone. It gates login, not sessions. A user suspended while logged in keeps their session until you invalidate it — add a middleware or event listener that logs them out.
• Debugging: if the check never fires, start with php artisan addon:list to confirm registration, then dump the collected security checks to see whether your class is present and enabled, then trace the check's isEnabled()/check() logic with the suspension flag set.
• Extension point: overriding the check's getMessage()/getType() in a subclass is cleaner than monkey-patching; the provider's binding is where you redirect to your subclass.
• Version drift: the Streams Platform interface has changed across releases. Diff the implements/extends signature against your installed anomaly/users-module before upgrading the platform, or the addon will fatal on boot.