Platform Gate Laravel Package

Product Decisions This Supports

• Trust boundary / API exposure roadmap. This package is the enforcement point for "only traffic that came through our edge is trusted." v0.7.1 tells us the team treats the shared edge secret as a first-class product risk, not an implementation detail — that supports decisions to keep the public API behind a single ingress rather than exposing origin services directly.
• Build vs. buy on edge authentication. The package (plus its Worker-side counterpart) is a small, opinionated component. The 0.7.1 patch history — header scrubbing in 0.7.0, then $_SERVER/$_ENV scrubbing in 0.7.1 — is a useful signal: the hard part isn't the header check, it's the leak surface around it. Buying/centralizing that logic is cheaper than re-deriving it per service.
• Security incident posture and audit follow-through. This release closes a Medium finding from an internal audit (S1, initiative "api-abierta") within a patch release. That supports committing to the package as a maintained dependency and citing it as evidence of remediation in audit/security reviews.
• Observability vendor decisions. The finding only existed because logs flow into Sentry. That makes "which logs leave the perimeter, and in what shape" an explicit decision for any service using a hosted error tracker — and a reason to require scrubbing guarantees at the library level rather than relying on per-service discipline.
• Upgrade policy for pre-1.0 dependencies. 0.7.0 → 0.7.1 requires no config or code change; with ^0.7 it's a composer update. Low friction means we can set a "patch within the sprint" expectation for security-relevant patches without a release-train cost.
• Deployment sequencing decisions. Domains can be upgraded in any order and the patch is backward compatible — so this doesn't force a coordinated multi-service rollout, and doesn't need a change freeze window.
• Use cases it enables: authenticated ingress for multi-tenant APIs, trusted-proxy deployments (Cloudflare Workers/edge in front of PHP-FPM), and per-domain edge secret rotation without downtime.

When to Consider This Package

Adopt it when:

• Your Laravel services sit behind a controlled edge/proxy and must reject requests that bypass it.
• You already (or plan to) run the matching edge Worker, so the shared-secret contract has an owner on both ends.
• You ship logs to a third-party error tracker (Sentry, etc.) and need the guarantee that request credentials never appear in those logs. This release is specifically the "we can prove it" version — it adds tests asserting no library log contains the secret value.
• You need configuration failures (short secret, malformed host, Worker started before the secret was provisioned) surfaced once per process with stable text — the 0.7.1 change moves those errors to the first request so they're logged after the secret is stripped, which matters both for noise control and for not leaking on misconfiguration.

Look elsewhere or de-scope when:

• You rely on Sentry and run PHP-FPM. This is the key caveat: v0.7.1 alone is not sufficient. Under PHP-FPM the header remains visible to getallheaders() and cannot be deleted from PHP, so the domain's Sentry before_send must strip X-Funnelchat-Edge. If you cannot own that configuration in every service, treat this package as a partial control only.
• You have no trusted ingress — i.e., you're not actually behind an edge, so there's no secret to validate.
• You need a stable public API today. It's 0.x; pin ^0.7 and expect patch-level churn on security findings.
• You need a general-purpose auth/authorization layer. This authenticates the channel, not the user.

How to Pitch It (Stakeholders)

To executives: we had an audit finding — the edge credential could reach our error-tracking vendor through logs. The vendor fixed it at the source in a patch release, verified with tests, and it's a drop-in upgrade with no code or config changes and no coordinated rollout. One caveat with a cost attached: on PHP-FPM the header still can't be removed from PHP, so each service's Sentry configuration must also strip it — that's ours to own, not the vendor's.

To engineering: 0.7.0 removed the secret from headers and the request's server bag but missed $_SERVER. 0.7.1 also scrubs $_SERVER/$_ENV for HTTP_X_FUNNELCHAT_EDGE regardless of whether validation passed, and moves edge configuration errors to first-request logging so they're emitted after redaction instead of while TrustEdge is being constructed. No library log includes the value, and there are now tests proving that, including logs emitted inside TrustEdge. Upgrade: bump 0.7.0 → 0.7.1 or just composer update funnelchat20/platform-gate under ^0.7; domains can upgrade in any order. Coming from 0.6, follow the 0.6 upgrade guide but land on 0.7.1.

Action items to land with the upgrade: (1) confirm before_send strips X-Funnelchat-Edge on every PHP-FPM service with Sentry enabled and the sentry channel in LOG_STACK; (2) check that no dashboards or alert rules keyed off the old log timing (config errors now log on first request, not at construction) silently go quiet; (3) record the audit finding as remediated with the residual Sentry-configuration dependency noted.