Ezmbpaex Ls Laravel Package

Technical Evaluation

Verdict: Do not adopt. This is not a Laravel package — it is a deprecated eZ Publish legacy extension (ezmbpaex, "multi binary password attribute extension") that implements password expiry, password-change enforcement, and password policy checks against the eZ Publish 4/5 user model. The classification in the intake record ("Laravel/PHP package") is a metadata artifact of Packagist/composer-style indexing. Treating it as a Composer dependency for a Laravel app is a category error.

Architecture fit

• Zero fit with Laravel idioms: no service provider, no facade, no config publishing, no migrations, no contracts. Configuration is legacy INI (mbpaex.ini, site.ini overrides); templates are eZTemplate (.tpl), not Blade.
• Domain coupling is to eZUser, eZUserType, eZContentObjectAttribute, and the legacy datatype/hook system (preUpdate, postUpdate attribute hooks). None of these have analogues a Laravel app can satisfy.
• What is genuinely reusable is the policy model, not the code: aging thresholds per user group, forced change on first login, reuse prevention, notification lead times.

Integration feasibility

• Practically infeasible as a dependency: the package will not autoload under Composer 2 / PSR-4, assumes PHP 5.x-era runtime semantics, and its entry points are invoked by the eZ kernel, which a Laravel app never boots.
• The only honest integration is a re-implementation: Laravel Password rule objects plus a custom rule for history/reuse, a password_changed_at column, a middleware or Fortify/Breeze login listener that redirects to a forced-change screen, and queued notifications for expiry warnings. Estimated 2–4 engineer-weeks including tests and backfill, versus an unbounded fork-and-port effort.
• Reuse of the source is gated on licensing: NOASSERTION is a red flag, not a formality. eZ Publish legacy was largely GPL-2.0, but we cannot rely on inference — legal review is required before copying any code, and copying is the only thing that would make this artifact useful.

Technical risk

• Abandoned-by-design: repository is archived, last release January 2020, 16 stars, 0 dependents. No security response path exists for code sitting directly on authentication.
• Security-sensitive domain: password policy code that is unmaintained is a compliance and audit liability. Reviewers will ask who patches it; the answer is "we do."
• Stale primitives: interacts with legacy hashing and session handling; any assumptions about hash algorithms or password column semantics will be wrong for a modern Laravel users table.
• Low signal: star count and dependent count are too small to infer API stability or community vetting. Absence of dependents means no field evidence of production use.

Key questions for the requester

1. Is there an actual eZ Publish 4/5 legacy estate in scope, or is this being evaluated for a Laravel application? The answer changes the recommendation completely.
2. Which policy behaviors are required — expiry, forced rotation, reuse prevention, complexity, notification cadence, admin reset? These are the real deliverables and they are all buildable natively.
3. Who owns the security review and the ongoing patch obligation if we fork?
4. Is there a compliance driver (ISO 27001, PCI, internal audit finding) that mandates rotation? Modern guidance (NIST SP 800-63B) de-emphasizes forced rotation, which may reduce scope to length/blocklist and breach checks only.
5. Has legal cleared NOASSERTION, or can we confirm the upstream license text?

Integration Approach

Stack fit

• Target stack: Laravel 10/11, PHP 8.2+, Fortify or Breeze, MySQL/Postgres. This package targets eZ Publish legacy on PHP 5.x. There is no overlap; nothing installs, nothing boots.
• If the estate truly runs eZ Publish legacy, this is a legitimate in-place extension and the recommendation flips to "assess, then pin and fork." Confirm this first — it is the fork in the road.

Migration path

1. Requirements extraction (2–3 days). Read the INI schema and hooks; write down the policy rules as acceptance criteria, with no code copied.
2. Native implementation (2–4 weeks). Schema change (password_changed_at, password_history table), a PasswordPolicy service, a Password rule for reuse, a ForcePasswordChange middleware on the authenticated route group, expiry notifications via a scheduled command, and an artisan backfill for existing users.
3. Parallel-run validation. If a legacy system is being retired, shadow-compare policy decisions for one cycle before cutover.

Compatibility

• Do not attempt PHP 8 compatibility shims on the legacy code — that is a rewrite wearing a fork's clothing, with none of a rewrite's clarity.
• Verify any downstream consumer's Laravel version before choosing Fortify vs. hand-rolled middleware; the forced-change redirect interacts with session and intended-URL handling and is the most common source of bugs.

Sequencing

• Week 0: resolve the stack question and the license question. Both are blocking.
• Week 1: requirements extraction and acceptance criteria sign-off.
• Weeks 2–4: native build, tests, backfill dry run.
• Week 5: staged rollout behind a feature flag; monitor lockout/support volume before enabling enforcement org-wide.

Operational Impact

Maintenance

• Zero upstream maintenance. Archived repo, single 2020 release, no maintainer response. Any fork becomes our permanent liability with no rebase path.
• The native alternative is a few hundred lines of ordinary Laravel code that our team already knows how to maintain — materially better total cost of ownership despite higher day-one cost.

Support

• No vendor, no security advisories, no CVE feed. We would be the de facto maintainers of an authentication component with no upstream signal to tell us if it is being exploited.
• Internal support burden falls on whoever owns auth. Ramp-up requires legacy eZ Publish familiarity (INI merging, datatype hooks, eZTemplate), a skill set that is shrinking and expensive to source. Budget 2–3 weeks of a senior engineer's time just to read the code confidently.

Scaling

• The workload is negligible — a handful of checks per login or password change. Performance is not a concern in either the legacy or native path.
• The scaling risk is organizational: enforcement across a large user base generates a support spike (lockouts, expired-session loops, helpdesk resets). Plan a grace window and an admin-assisted reset path.

Failure modes

• Lockout loops: expiry check fires on a route the user cannot reach, producing an unbreakable redirect cycle. This is the dominant failure mode for both implementations; test the middleware exception list explicitly.
• Hash/schema drift: legacy assumptions about the password column break silently against modern hashing.
• Notification fatigue: aggressive expiry warnings train users to ignore them.
• Backfill errors: bulk-setting password_changed_at to now() disables enforcement for existing users; setting it to epoch expires everyone at once. Choose deliberately.
• Orphaning: the one engineer who understood the legacy hook leaves; the component becomes untouchable and unauditable.

Ramp-up

• Legacy path: 2–3 weeks to competence, concentrated in one person, with no external documentation beyond the repo.
• Native path: 2–3 days for any Laravel-fluent engineer, testable and reviewable in normal code review.

Recommendation to the decision-maker: decline the dependency. Re-scope the request as a password-policy feature and fund the 2–4 week native build. Escalate immediately if the requester's environment is Laravel, since the intake metadata is misleading and any procurement based on it would be wasted.