Francis GALIEGUE wrote:
On Thu, Sep 15, 2011 at 14:25, André Warnier <a...@ice-sa.com> wrote:
[...]
OK, I've found the bug...
I have added an access log valve and here is what I see in it:
[15/Sep/2011:11:59:14 +0200] 0:0:0:0:0:0:0:1 (132 msec/964 bytes) 403
GET //manager/text/list HTTP/1.0
That explains it. So, I do have IPv6, but the valve doesn't recognize
::1 as being equivalent to the fully expanded IPv6 address... If it
only tries and matches the regex, the behaviour is therefore normal.
Aha. So I do get a Debugger Bonus Point after all.
Yes, indeed. Even though I have NETWORKING_IPV6=no in
/etc/sysconfig/network. Bah.
I have added 0:0:0:0:0:0:0:1 as an alternative instead of ::1 and it
does work...
So, PEBKAC mostly, but I think Tomcat should be able to treat reduced
IPv6 address formats.
That would mean that both the address configured in the Valve, and the
client address, would need to be "canonicalised" and then compared.
You'll probably see the traditional "patches are welcome" soon.
On the other hand, using a regexp provides for quite a bit of flexibility
regarding ranges of addresses. You could use something like :
"(127\\.0\\.0\\.1)|((0?:0?:0?:0?:0?:0?)?:0?:1)"
Well, checking address ranges would be _much_ easier if regexes were
not anchored...
But anyway, the "allow" and "deny" as they exist currently just don't
cut the mustard, and are far from being as potent as, say Apache's
Allow from and Deny from. This should be the goal.
RemoteAddrValveEvolved?
One difficulty with implementing an Apache httpd-like scheme is that, in httpd, the order
of the allow/deny plays a big role, and preserving the order is generally more difficult
in XML.
But maybe just this : the "localhost" case is so frequent, that maybe it could just be a
separate attribute in the Valve, like : localhostAllow="true/false" or even
localhost="allow/deny"
and internally match any form of localhost.
That may allow for some optimisation. I'm sure the impact would be tiny, but since this
is code that gets invoked at just every request and generally quite early, it may be
significant.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
