Mjr Security Integration Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the auth boundary. This package only exists to wire an authorization library into a transport stack. The PM decision it informs is architectural, not procurement: enforce authentication and authorization at a single choke point in front of business logic instead of scattering checks across handlers. Adopt the pattern; skip the artifact.
• Roadmap input for legacy modernization. Zero stars, zero dependents, last release 2016-07-18, read-only. If it shows up in a dependency graph, the only product decision it drives is "what replaces this, who owns it, and by when." Route it to the modernization/sunset backlog, not the feature backlog.
• Dependency-risk policy calibration. A security-adjacent component with no maintainer and no patches in roughly a decade is a clean example for setting the bar on acceptable dependencies. Use it to justify a policy gate: auth-adjacent dependencies require an active maintainer and a recent release before review.
• Framework-fit guardrail. The package is a Symfony bundle, not a Laravel package. The decision this supports is a negative one for our stack: do not let generic "PHP auth" search results enter a Laravel roadmap. Laravel's Gate/Policy plus Sanctum or Passport covers the same requirement with first-party support.
• Requirements discovery for authorization UX. Reading a thin integration layer is a fast way to enumerate the product questions that must be answered before an API contract is signed: who is the principal, what is the protected resource, what is the policy unit, how are roles mapped, how is multi-tenant scope enforced.
• Make-or-buy on glue code. The transferable insight is that integration seams are usually a few hundred lines of middleware. Building that seam in-house is cheaper and safer than inheriting someone else's abandoned version of it.

When to Consider This Package

Consider it only in tightly bounded, non-adoption scenarios:

• As reference material for an internal design. If engineering is defining how JSON-RPC or API requests get authenticated and authorized centrally, the bundle is a compact prior-art example of decorator-style enforcement at the transport boundary. Read it; do not ship it.
• When auditing or acquiring a codebase that already depends on it. You need to characterize the security posture and exit cost of a legacy Symfony/Modera MJR footprint. That is a due-diligence task, not a new build.
• When you already operate a legacy Symfony app built on Modera MJR and need to document or patch existing behavior. Even then: pin, vendor, assign an owner, and put a replacement date on the roadmap.
• When building the business case against bespoke per-controller auth. It is useful evidence that centralized transport-level enforcement is a known, solved shape.

Look elsewhere — decisively — when:

• You are on Laravel. There is no supported integration path. A Symfony bundle cannot bind to Laravel's container, middleware, or auth lifecycle without a full re-implementation. Use Gate/Policy, middleware, and Sanctum or Passport.
• You need maintained security code. Authentication and authorization are the highest-consequence code you own. An unmaintained 2016 component cannot meet modern expectations for patching cadence, CVE response, or audit evidence. This is a disqualifier, not a trade-off.
• You need current framework or PHP support. Assume incompatibility with modern Symfony and PHP 8.x. The cost of a private fork exceeds the cost of implementing the pattern natively.
• You need community support or hiring leverage. Zero stars, zero dependents means no ecosystem, no Q&A corpus, and no candidate pool. Every question becomes internal archaeology.
• You have audit or compliance obligations (SOC2, PCI, ISO) that prohibit unpatched auth dependencies outright.
• You need a vendor relationship. No maintainer activity, no releases, no support contract — total cost of ownership is unbounded where it matters most.

How to Pitch It (Stakeholders)

Executive summary. This is an abandoned, read-only integration bundle for a niche Symfony JSON-RPC framework. It has no users, no dependents, and no release since July 2016 — and it is not a Laravel package, so it does not fit our stack at all. We are not adopting it. That is the correct call, not a missed opportunity: security code without a maintainer is a liability, not a shortcut. Our recommendation is to reuse the design idea — a single enforcement point where requests are authenticated and authorized before reaching business logic — and implement it natively on Laravel, where we control patching, testing, and audit evidence.

To engineering. Treat this as reference material only. The transferable lesson is the decorator-at-the-transport-boundary pattern: keep authentication and authorization out of handlers, centralize policy evaluation, and make the principal/resource/policy triple explicit in the API contract. If this bundle already exists in a legacy service, mark it frozen — vendor it, document it, assign an owner, and open a replacement ticket with a date. Do not fork it into a supported internal library; that converts an unowned dependency into an unowned dependency we now maintain.

The ask. No budget, no spike, no procurement. Three concrete actions: (1) correct the categorization so Symfony artifacts stop entering Laravel evaluations, (2) add one modernization backlog item for any service found depending on it, and (3) adopt a standing rule that security-adjacent dependencies require an active maintainer and a recent release before they clear review.