On 29/09/2025 12:03, Rémy Maucherat wrote:
On Mon, Sep 29, 2025 at 11:51 AM Mark Thomas <[email protected]> wrote:
All,
We have a PR [1] that adds CIDR notation support to the RemoteIpFilter.
I have a set of changes stashed locally that fixes a couple of
formatting nits and expands it to the RemoteIpValve as well.
Currently, it is coded so the the regular expression (internalProxies,
trustedProxies) based attributes are used unless the corresponding CIDR
attribute is used (internalProxiesCidr, trustedProxiesCidr) in which
case the regular expression is ignored and the CIDR attribute used instead.
Before I commit this, I was wondering what the long term plan might be
here and whether there was a better default.
Will we always support regular expressions and CIDR?
Do we want to (eventually) move from regular expressions to CIDR?
If we want to move towards CIDR then I was thinking we might want to:
- move the default from internalProxies to internalProxiesCidr
- use the CIDR attributes by default but ignore them and use the regular
expression ones if set
- deprecated the regular expression attributes and remove them in 12.0.x
That should be backwards compatible since:
- if a user has set the regular expression attributes they will be used
- the defaults will be unchanged
- new usage can use CIDR
Thoughts?
There's also RemoteCIDRFilter/Valve, is there any real difference ? It
has allow/deny and uses the same NetMask utility class.
Yes, there is a difference.
RemoteIpFilter handles providing the correct client IP/port/protocol
when behind a proxy. It doesn't do allow/deny.
RemoteAddressFilter, RemoteHostFilter and RemoteCIDRFilter all do allow
deny.
We could deprecate RemoteAddressFilter (with RemoteCIDRFilter as the
replacement) if we wanted to move towards using CIDR notation rather
than regular expressions for IP addresses.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
