oscerd opened a new pull request, #25406:
URL: https://github.com/apache/camel/pull/25406
## Description
`WebhookUrlValidator` classified webhook hosts in two places that did not
agree with each other.
A host written as an IP literal was checked against a string prefix list
(`isPrivateIpv6`), while a host reached through a name was classified with the
`InetAddress` predicates. Those two do not cover the same ground —
`Inet6Address.isSiteLocalAddress()` reports the deprecated `fec0::/10` block
and **not** the `fc00::/7` unique local addresses that replaced it — so the
same address was accepted or rejected depending on how it was written. Verified
on JDK 21: `fd00::1` and `fc00::1` return `false` for all four predicates,
while `fec0::1` returns `site=true`.
The literal pre-check also prefix-matched the raw host string with
`startsWith("fc")` / `startsWith("fd")` without first establishing that the
host was an IP literal, so any name beginning with those two characters was
rejected outright. `https://fcm.googleapis.com/webhook` and
`https://fd-edge.example.com/webhook` were both refused.
## Changes
Both paths now resolve the host and classify the resulting address with a
single shared raw-byte classifier. `InetAddress.getByName()` already parses
bracketed IPv6 literals without touching DNS, so the separate literal path is
no longer needed and the two forms cannot drift apart again.
The classifier recognises these in addition to the loopback / wildcard /
link-local / site-local ranges already handled:
| Range | Example |
|---|---|
| IPv6 unique local, `fc00::/7` | `fd00::1` |
| IPv4-compatible IPv6 | `::10.0.0.1` |
| NAT64 well-known prefix, `64:ff9b::/96` | `64:ff9b::a00:1` |
| 6to4, `2002::/16` | `2002:c0a8:101::1` |
| Shared address space, `100.64.0.0/10` | `100.64.0.1` |
NAT64 and 6to4 addresses are classified by the IPv4 address they embed
rather than blocked wholesale, so an IPv6-only deployment can still reach
public webhook endpoints through a translation prefix.
IPv4-mapped IPv6 needs no new handling — the JDK returns an `Inet4Address`
for `::ffff:x.x.x.x`, so the existing IPv4 rules already applied.
Host names are no longer classified by their spelling.
## Notes for reviewers
- **Exception message text changes.** `[fd00::1]` now reports `unique local`
instead of `private/internal IPv6 ranges`, and `[::1]` reports `loopback`
instead of the IPv6 message. Four existing test assertions were updated
accordingly. No API signature changed.
- **`nonGlobalReason` checks loopback** even though a host reaching loopback
directly is answered earlier (where `allowLocal` can let it through). That
branch exists for the addresses embedding an IPv4 one — `64:ff9b::7f00:1`
carries `127.0.0.1` — and is covered by a test.
- A package-private `HostResolver` seam lets the resolved-host path be
tested without DNS and without installing a JVM-wide
`InetAddressResolverProvider`, which would have affected every test in the
module.
## Testing
`WebhookUrlValidatorTest` goes from 13 to 30 tests, covering each range
above in both literal and resolved form, the adjacent addresses just outside
`100.64.0.0/10`, the NAT64/6to4 cases that must stay allowed, and the host
names that were previously rejected for their spelling.
- `camel-a2a` module suite: 519 tests, all passing
- Full reactor build from root (`mvn clean install -DskipTests`): SUCCESS,
no uncommitted regen artifacts
## Documentation
Adds `camel-4x-upgrade-guide-4_23.adoc` with a note on the newly rejected
ranges and the relaxed host-name matching, and registers it in the upgrade
guide index.
---
_Claude Code on behalf of @oscerd_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
