Blocked Security Check Extension Laravel Package

Technical Evaluation

Architecture fit

• This is not a general-purpose Laravel package. It is a Streams Platform addon (PyroCMS 3.x) that implements the platform's SecurityCheckExtensionInterface and registers itself into the SecurityCheck service registry.
• Its entire responsibility is to return a response when the authenticated user is suspended, short-circuiting the request inside the platform's security-check pipeline.
• Outside PyroCMS/Streams — i.e., in a standard Laravel application — there is no security-check registry to hook, so the package contributes nothing. Fit is effectively binary: 100% inside PyroCMS, 0% everywhere else.

Integration feasibility

• composer require anomaly/blocked_security_check-extension, then enable the addon; registration is handled by the Streams addon service provider.
• Hard dependencies on compatible anomaly/streams-platform and anomaly/users versions. The actual code footprint is likely a single class plus a service provider.
• Effort for a team already on PyroCMS: a few hours including testing. Effort for anything else: prohibitive and pointless.

Technical risk

• Package health score of 0.065, 1 star, 0 dependents: effectively unadopted. No community validation, single maintainer, no evidence of CI or test coverage.
• License is reported as NOASSERTION — GitHub cannot identify a standard license. This is a genuine legal/compliance blocker for enterprise adoption regardless of technical merit.
• Repository name (suspension_security_check-extension) does not match the package name (blocked_security_check-extension), which suggests loose release hygiene and raises a question about which artifact is canonical.
• Abandonment risk is materially reduced only because the surface area is tiny and can be vendored or reimplemented in an afternoon.

Key questions

• What exactly is evaluated — the users.suspended column, a role, or an addon-specific flag? What is the response shape: redirect, abort(403), or JSON for API/AJAX requests?
• Does it exclude the control panel, logout, login, and password-reset routes? A suspended user who cannot reach any appeal or logout path is an operational incident.
• How does it compose with the platform's other built-in checks (activation, email verification, 2FA)? Does it override or short-circuit them?
• What is the tested compatibility matrix — PyroCMS/Streams minor versions and PHP 7.x vs 8.x constraints?

Integration Approach

Stack fit

• Good fit for a PyroCMS 3.x site running the Users module. No fit for generic Laravel 9–11, Laravel Zero, or headless API projects.

Migration path

• On PyroCMS: add via Composer, enable the addon, confirm it appears in the security-check registry, and verify behavior in staging before production.
• Off PyroCMS, or where licensing is a concern: do not adopt. Implement an EnsureUserIsNotSuspended middleware (~20–30 lines, one suspended check, route exclusions) which reproduces the behavior with full ownership and no upstream dependency.

Compatibility

• Pin against the Streams Platform major version in use and confirm the PHP constraint before adding to a PHP 8.2+ codebase. Assume the package will need a fork to keep pace with platform updates.

Sequencing

1. Confirm Streams Platform and Users module versions and the PHP constraint.
2. Add the dependency on a branch and enable the addon.
3. Audit and document route exclusions (admin, logout, appeal/support paths).
4. Test suspended, active, and administrator accounts, plus AJAX and API requests.
5. Decide adoption vs. vendoring based on the license finding; if vendoring, copy the class into the application and drop the Composer dependency.

Operational Impact

Maintenance

• Code churn is near zero, but so is upstream maintenance. Budget for internal ownership: treat the package as a small internal fork, not a maintained third-party dependency.

Support

• No vendor support, no issue triage, no security response channel. An internal owner must be named before adoption.

Scaling

• Negligible. One attribute check against an already-hydrated user model per request; no additional queries beyond what the Users module performs and no meaningful throughput impact.

Failure modes

• Fail-open is the dangerous one: if the addon is disabled, renamed, or fails to register after a platform upgrade, suspended users silently regain access with no error surfaced. Requires a smoke test in CI or post-deploy.
• Fail-closed misconfiguration: overly broad route coverage locks suspended users out of logout, password reset, or support paths.
• Check ordering conflicts: interaction with other security checks can produce inconsistent responses (redirect vs. 403 vs. JSON) depending on which check fires first.

Ramp-up

• Trivial for a developer who already knows PyroCMS addons and the security-check extension point. Genuinely confusing for a general Laravel engineer who will look for middleware and find none — document the extension point and the intended response contract explicitly.