Json Rpc Check Ip Bundle Laravel Package

Getting Started

tourze/json-rpc-check-ip-bundle is a Symfony bundle (not a native Laravel package) that adds IP-based gating around JSON-RPC handling. Release 0.0.3 ships with no descriptive changelog — the notes are only a compare link between 0.0.2 and 0.0.3 — so treat it as a maintenance/patch bump and read the diff before upgrading. Nothing in the release indicates new features, deprecations, or breaking changes, but at 0.0.x there is no semver guarantee either way.

Where to look first, in order:

1. composer.json — confirm the Symfony/JSON-RPC component constraints it pulls in; that tells you which host framework versions it will even install against.
2. The bundle class and its DI extension (src/*Bundle.php, src/DependencyInjection/) — this is where the checker service, its tag, and default config keys are registered.
3. Whatever service implements the IP decision (look for CheckIp, IpChecker, *Matcher) — that is the piece you will actually reuse or replace.
4. The JSON-RPC integration point — a handler decorator or middleware, which is where the allow/deny decision is enforced.

First practical use case: restricting a JSON-RPC endpoint so only internal networks or partner IP ranges can call administrative methods, while leaving read-only/public methods open.

Install with composer require tourze/json-rpc-check-ip-bundle, register it in config/bundles.php, and (on Laravel) plan on a thin bridge — a service provider that binds the checker and a middleware wrapping the JSON-RPC route. Do not expect Laravel-native discovery, config publishing, or a facade.

Implementation Patterns

• Decorate, don't fork. Wrap the JSON-RPC handler (or the bundle's middleware) in your own class so the check runs before dispatch. This keeps the third-party surface to one integration point and makes a future 0.0.x bump a one-file change.
• Fail closed. Configure an explicit allowlist and verify what an empty list means in this version — "allow all" and "deny all" are both plausible defaults and the difference is a security incident.
• Per-method policy. Gate sensitive method namespaces (admin.*, internal.*) rather than the whole endpoint; public methods rarely need IP checks and blocking them breaks clients.
• CIDR over single IPs. Keep ranges in config/env (RPC_ALLOWED_CIDRS), not hardcoded, so ops can change a partner range without a deploy.
• Correct client IP resolution. Behind a load balancer or CDN, configure trusted proxies (Symfony Request::setTrustedProxies(), Laravel TrustProxies) so the checker sees the real client address. Without this every request looks like it comes from the balancer and the allowlist is meaningless.
• Return JSON-RPC errors, not HTML. A plain 403 from framework middleware breaks clients that expect a JSON-RPC error envelope. Emit something like -32000/-32600 with the HTTP status your clients tolerate.
• Test with explicit REMOTE_ADDR. Functional tests should build requests with a server array (['REMOTE_ADDR' => '10.0.0.5']) and assert both allow and deny paths, plus the header-spoofing path.
• Log denials. One line per rejection with the resolved IP and the reason is the difference between a five-minute and a five-hour debugging session.

Gotchas and Tips

• 0.0.x churn. Pin the exact version ("0.0.3", not ^0.0) and keep the adapter class described above. Assume method signatures can change between patches.
• Empty release notes are a real risk. Diff 0.0.2...0.0.3 yourself (composer diff / GitHub compare) and check whether the change is only CI, composer.json, or code. In a pre-1.0 package a silent behaviour change is entirely possible.
• IPv6 and IPv4-mapped addresses. ::ffff:127.0.0.1 frequently misses an 127.0.0.0/8 rule. Normalise before matching and add a test per family.
• Header spoofing. Never read X-Forwarded-For unless trusted proxies are configured; otherwise a client sets their own allowlisted IP.
• Stale container. Symfony caches compiled DI config — after changing allowlists or service wiring, bin/console cache:clear (and check OPcache in prod) before concluding the rule "doesn't work".
• Empty-config semantics. As above: assert the default behaviour in a test rather than reading the docs, because at this version the docs may not exist.
• Extension point. Prefer replacing the checker service via a container alias or decoration over editing vendor code; that survives upgrades.
• Bundle-in-Laravel friction. If this is going into a Laravel app, expect to reimplement the middleware contract yourself and use only the checker class. Budget for that rather than fighting bundle auto-registration.