Activation Security Check Extension Laravel Package

Getting Started

This is a Streams Platform (PyroCMS) addon that plugs into anomaly/users-module to add an activation check into the authentication flow — i.e., it is the piece that decides whether an unactivated user is allowed through login. It is not a standalone package: nothing happens without the Users module and the Streams addon system installed.

Minimal steps:

1. Install the addon via Composer (composer require anomaly/activation_security_check-extension) or drop it into addons/ if you are vendoring it. Because the repo has an unasserted license (NOASSERTION), get legal sign-off before shipping it in a commercial product — or plan to reimplement the behavior yourself.
2. Install and enable it through the addon system, not just Composer: php artisan addon:install anomaly.activation_security_check-extension followed by php artisan addon:enable ... (or the equivalent in the control panel). Streams addons are inert until installed/migrated.
3. Clear caches after enabling — php artisan addon:reinstall, then cache:clear and view:clear. Most "the extension isn't doing anything" reports are stale addon/service caches.

Where to look first: the service provider in src/ (its register()/listen() methods tell you exactly how it hooks in), the migrations/ folder (what state it persists, if any), and any resources/lang/resources/config files for the messages and toggles it introduces. Read the provider before touching config — with 2 stars and 0 dependents there is essentially no documentation to lean on.

First use case to validate end-to-end: create a user with activated = false, attempt login, confirm the check blocks them with the expected message; then activate the user and confirm login succeeds. That single test tells you whether the addon is wired correctly and whether it duplicates behavior the Users module already provides.

Implementation Patterns

Trace the hook before extending it. Addons in this ecosystem hook in via one of a few mechanisms — an event listener on authentication events, a class that extends a "security check"/authenticator contract in the Users module, or a decorator around the authenticator. Confirm which one this uses by reading the provider, then trace that same path in anomaly/users-module. Everything you do afterward depends on knowing whether you are adding a check or overriding one.

Treat it as a reference implementation, not a dependency. With 0 dependents and 2 stars, the realistic day-to-day use is: copy the pattern into your own addon, or fork it and own the maintenance. If you depend on it, pin the exact version in composer.lock and vendor the source so an upstream disappearance doesn't break deploys.

Layer additional checks alongside it. If you need "activated and not suspended and email verified," instantiate the same pattern the addon uses for each additional condition rather than piling conditionals into one class. Keep each check independently testable and independently toggleable.

Test the login path as a feature test, not a unit test. Factory a user in each activation state, hit the actual login route, assert on both the redirect/JSON response and the session guard state. This is the only reliable way to catch checks that fire in the wrong order or are silently skipped.

Surface the outcome in the UI. Move any hardcoded messages into resources/lang and, if the addon ships views, publish/override them from your theme rather than editing the package in vendor/ or addons/.

Deployment discipline. Enable the addon as part of your deploy script (install → enable → clear caches), not manually in the control panel, so staging and production converge. Record the addon state in your database seeding/migration strategy.

Gotchas and Tips

• License risk is the headline. NOASSERTION means there is no explicit grant. Do not redistribute the code, and get a legal review before commercial use. Forking and reimplementing from scratch is often cheaper than the legal conversation.
• The check can lock out administrators. If the activation flag is missing, stale, or reset by a bad migration, every login fails — including yours. Before enabling in production, know how to disable the addon without the panel (via artisan or a direct addons table update) and test that escape hatch.
• Confirm it isn't redundant. The Users module already has activation concepts. If the addon only changes an error message or a redirect path, you may be adding a maintenance burden for a two-line override.
• "Nothing happens" is almost always caching. Run php artisan addon:reinstall anomaly.activation_security_check-extension, then cache:clear, config:clear, view:clear. If it still does nothing, confirm the addon is actually installed and not merely enabled.
• Debug from inside the hook. Drop a logger() call at the top of the check/listener to confirm it is reached on the login request at all. Half the failures are wiring problems, not logic problems. Then tinker into the user record to inspect the raw activation attributes the check reads.
• Watch for stale activation codes. If the check validates an activation token rather than a boolean flag, expired or reused codes will produce confusing "correct credentials, still blocked" behavior. Log the specific reason for the block.
• Pin and monitor. No dependents and no license means no upgrade path. Pin the version, and add a note in your README that this addon is unmaintained and should be replaced if the Users module API shifts.
• Extension points you can rely on: language files, config overrides, and view publishing. Avoid editing addon source directly — you will lose the changes on the next Composer update and have no upstream to merge from.