Suspension Security Check Extension Laravel Package

Product Decisions This Supports

• Account lifecycle enforcement (suspend → deny access). If the product has a suspend/ban state on user accounts, something must enforce it at the authentication boundary. This package exists to close that gap in the Streams Platform Users module — it is the mechanism that turns a "suspended" flag from a data field into an actual access control.
• Feature scoping: is suspension enforcement in scope, or is it a "moderation v2" item? Reviewing this package forces the question of whether "suspended users cannot log in or remain logged in" is table-stakes for launch or a deferred moderation feature. If the answer is table-stakes, the roadmap needs a line item — and this package is one candidate implementation.
• Build vs. buy (leaning build). The functional surface here is small and well-understood: verify user status at login, and re-verify on subsequent requests so a suspension takes effect immediately rather than at next session expiry. That is a modest amount of application code in most frameworks. The buy case only holds if the team is already committed to the Streams/PyroCMS Users module and wants to avoid forking it.
• Security posture / abuse-handling commitments. If sales, trust & safety, or a security questionnaire asserts "suspended accounts are terminated immediately," this is the kind of component that backs that claim. It informs whether that statement is supportable in a given release.
• Immediate-vs-eventual revocation decision. A meaningful product decision is whether suspension takes effect on the next request (hard logout) or at next login. This package's existence implies the former is achievable cheaply; that shapes how the moderation UX is designed and what support tickets you'll get.

When to Consider This Package

Adopt only when all of the following hold:

• You are already running the Anomaly Labs Streams Platform with the Users module — this is an ecosystem-specific extension, not a general-purpose Laravel auth package. Its value is near-zero outside that stack.
• You need suspension enforcement and would otherwise patch or wrap the Users module yourself; using a published extension keeps you off a fork and preserves upgrade paths.
• You have accepted the maintenance risk: 1 star, 0 dependents, and no meaningful community signal mean you are effectively the only consumer. Budget for reading the source and owning it.
• Legal has cleared the license. NOASSERTION is not a license — it means the repository's terms could not be automatically determined. Do not ship this into a commercial product before a human confirms the actual license terms. This is a hard blocker, not a formality.

Look elsewhere (or build in-house) when:

• You are not on the Streams/PyroCMS stack, or you use a different auth system (Laravel Breeze/Jetstream/Fortify, Sanctum, an external IdP). A gate, middleware, or Fortify authentication pipeline customization is the right tool.
• You need session/token revocation guarantees across APIs, mobile, or websockets — auth-boundary checks alone won't cover long-lived tokens issued before suspension.
• You require vendor support, SLAs, or a maintained dependency for a security-relevant control. A near-zero-adoption package with an unresolved license should not be the sole enforcement point for a security policy.
• There is any chance the Users module will be replaced. Coupling an access-control rule to a niche module increases migration cost later.

How to Pitch It (Stakeholders)

For executives: This is a small extension that enforces account suspension inside our user module — it makes "suspended" actually mean "locked out." The functionality is genuinely needed if we promise customers that bad actors can be shut off immediately, and the alternative is a small amount of our own code. The package itself is not a strategic asset: it has one star, no downstream users, and an unresolved license. My recommendation is to treat it as a reference implementation and a schedule/trade-off input, not a dependency to adopt on faith — approve the requirement, and let engineering decide whether to consume this or write the equivalent in-house.

For engineering: Scope is narrow — enforce user-status at login and re-check on authenticated requests so suspension revokes access on the next request rather than the next session. It targets the Streams Platform Users module specifically, so it only applies if we're on that stack. Two concerns before adoption: the license is NOASSERTION (needs legal sign-off), and adoption is effectively zero, so we own any bugs. Estimate the in-house equivalent first; if it's small and we're not already deep in Streams, build it and keep our access-control logic in our own codebase where we can test it.