Hidden Entity Bundle Laravel Package

Technical Evaluation

Architecture fit. None as a dependency. gibilogic/hidden-entity-bundle is a Symfony 2 bundle — it registers a HiddenEntityType form type, a DI extension, and a Doctrine ORM data transformer. The brief frames this as a Laravel/PHP package, but Laravel ships neither the Symfony Form component nor Doctrine as first-class citizens, so there is no form factory, no data-transformer pipeline, and no bundle container for this code to attach to. The capability it models — carry an entity reference through a form round-trip as a scalar, then rehydrate it server-side — is natively expressed in Laravel by route model binding (/posts/{post}/comments) plus an exists validation rule and a Policy check. As a TPM, the only defensible reason to look at this repo is as a reference design for a small internal helper, not as an install target.

Integration feasibility. Effectively zero. Two independent blockers: (1) the framework mismatch above; (2) API drift — the bundle targets the pre-3.0 Symfony Form API (setDefaultOptions), which became configureOptions. It would fatal against any supported Symfony version and its composer constraints will not resolve against PHP 8.1+/current Laravel. The realistic "integration" is a 50–100 line reimplementation of the pattern in Laravel: a hidden Blade input, Rule::exists('posts','id') scoped by tenant/owner, findOrFail, and an authorization gate. That is roughly one engineer-day.

Technical risk. Concentrated in the pattern, not the code. A hidden field carrying an entity ID is fully user-controlled; it is only safe if the server resolves the entity and verifies ownership/tenant scope on every submit. The name "hidden entity" invites the misconception that hiding the input provides protection — a supply-chain and audit concern to call out explicitly. Secondary risks: Symfony 2 has been EOL for years with no security backports; 0 stars / 0 dependents / 0 score means no evidence of production use, no third-party review, and no one who would notice a CVE. There is no CVE monitoring, no release cadence, and no maintainer SLA.

Key questions.

1. Which Laravel/PHP versions are in scope, and does an internal convention for hidden-ID submission already exist that we should standardize rather than duplicate?
2. What is the authorization model for referenced entities — single-tenant, multi-tenant, role-scoped — and where is ownership enforced today (Policy, global scope, middleware)?
3. Is the underlying motive UX/performance (avoiding a thousands-row <select>), correctness (wizard state), or just legacy convenience? This determines whether a simple exists rule suffices or we need signed identifiers or server-side session carry-over.
4. Do we need polymorphic/multi-entity hidden resolution, or is a single typed foreign key enough?
5. Who owns the internal helper, and does it belong in application code or a shared support package?

Integration Approach

Stack fit. Implement natively. Map Symfony's three moving parts onto Laravel primitives: the HiddenType render → a Blade input or form component; the DataTransformer → prepareForValidation() or a dedicated Rule object that resolves the scalar; the Doctrine hydration + EntityType constraint → Rule::exists(...)->where('tenant_id', …) plus a Policy/Gate::authorize call. Route model binding covers the common case where the ID is in the URL rather than the body — prefer it, since it centralizes resolution and authorization.

Migration path. Do not vendor, fork, or wrap the bundle. Treat the repo as a design reference: extract the semantics (hidden scalar in, authorized model out) and drop the implementation. There is no existing adoption to unwind, so no code migration is required.

Compatibility. Hard incompatible on both axes — Symfony 2 form API and PHP 5.x-era constraints versus current Laravel (PHP 8.1+). No shim is worth building; a compatibility layer would cost more than the reimplementation and carry the same EOL risk.

Sequencing.

1. Confirm no existing internal equivalent and pick the canonical home (application Rules/ or a shared support package).
2. Build the hidden-input component plus the resolution/authorization rule, with tenant/ownership scoping baked in rather than optional.
3. Write tampering tests: valid ID, foreign-tenant ID, deleted ID, non-numeric input, soft-deleted record.
4. Document the pattern and its security precondition ("hidden ≠ trusted") in team conventions.
5. Add a review/lint checklist item for any hidden-ID field lacking an explicit authorization check.

Operational Impact

Maintenance. As a dependency: unbounded and unattractive — no upstream fixes, no CVE monitoring, and a fork you alone maintain. As an internal pattern: low and predictable, about a one-day build over a small, stable surface.

Support. None available. No maintainer SLA, no issue triage, no community to escalate to. Any defect becomes internal debugging against unfamiliar Symfony 2 internals — a worse position than owning 80 lines of straightforward Laravel.

Scaling. Not a throughput concern; this is form-layer glue, not a hot path. The scaling risk is organizational: a hidden-ID convention adopted without a mandatory authorization check propagates an IDOR pattern across every form that copies it, and the blast radius grows with the number of tenants and entities.

Failure modes.

• IDOR / privilege escalation — the dominant risk; a trusted hidden ID lets a user reference another tenant's record.
• Stale or deleted IDs — resolution failures surface as 500s instead of clean 404/422 responses.
• Mass assignment — passing the resolved model into fill()/update() can write columns the form never intended to expose.
• Silent fallback — a null-resolution path defaulting to "create new" produces orphaned or duplicated records.
• Framework-level fatals — if anyone installs the bundle anyway, the Symfony Form API mismatch fails at container boot, which is at least a loud failure.

Ramp-up. Negligible for the reimplementation; a Laravel developer comfortable with FormRequests and Policies produces the equivalent in under a day. For anyone attempting to use the bundle as shipped, ramp-up is inverted: effort goes into unlearning Symfony 2 idioms and reverse-engineering abandoned code, with no transferable payoff.

Recommendation. Reject as a dependency. Adopt the underlying hidden-entity pattern as a thin internal Laravel helper with authorization as a non-optional part of the contract; log any inherited Symfony 2 usage as tech debt with a named owner and removal date.