Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1543: IpAddressMatcher does not act like expected #1785

spring-issuemaster opened this Issue Aug 18, 2010 · 4 comments


None yet
1 participant

Kai Moritz (Migrated from SEC-1543) said:

When configuring a constraint like "hasIpAddress('X.X.X.X')", Spring-Security usees the class org.springframework.security.web.util.IpAddressMatcher to compare the given IP with the IP from the request.

Unfortunatly, IpAddressMatcher throws an IllegalArgumentException, when the given IP and the IP from the request are of different type. This happens for example, when the request uses an IPv6-Address, but the Address used in "hasIpAddress()" was an IPv4-Address. The unexpected outcome of this behavior is, that any IPv6-request matching the resource will only see an error-page!

I suggest, that IpAddressMatcher responds with "false", if the given Address and the Address in the Request are of different type. That would solve this issue and is also the behavior I would expect: two IP-Addresses of different type are simply always not equal!

Luke Taylor said:

The original intention was that it is considered an error to configure a security contraint with an IPv4 address on an IPv6 network. Do you actually have a dual-IP setup where you are using both simultaneously? If that's the case then your suggestion would make sense to me, but if it is a choice between one or the other then I would say it is a configuration issue which should be flagged up as such. (Disclaimer - I don't know a great deal about Ipv6 networks :-) ).

Kai Moritz said:

I also do not know much about IPv6.
But I think, nowadays it is a very common situation,
that both protocol versions are enabled in parallel -- especially, if you are on your local
test-machine (all linux distrbutions I am working with
now act like this)!

But clearly you are right: making it configurable would
be the best solution! Nevertheless, if you take tjat path,
I would suggest, that throwing the error would not become
the default behaviour.

Andrew Rawnsley said:

I will second Kai's suggestion that this isn't an exceptional situation. Part of the issue is that, as Kai suggested, that it is a common now. Both protocols are active in OS X by default, and localhost on OS X comes through as ::1 and not

More importantly, this behavior dictates that I can only deploy an application on IPv4 or 6 networks based on my choice of hasIpAddress filters, without maintaining multiple versions of said filters. That shouldn't be making the choice for me.

(Our situation is like that - our production systems (linux) only have 4 active, but test machines (OS X) have both, and due to the aforementioned localhost issue...)

There is a workaround - add -Djava.net.preferIPv4Stack=true to thejvm startup, and everything comes through ipv4. But I feel the proper solution is as Kai suggested - that a protocol mismatch return false and not an exception.

Luke Taylor said:

I think this makes sense too, so I've changed the code to return false for different address types.

@spring-issuemaster spring-issuemaster added this to the 3.1.0.M2 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment