You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sanford Stein <Sa...@cybertools.biz> on 2011/10/04 19:21:39 UTC
Denying IPs using the Valve command in context.xml
1. I am using wildcards in my IP addresses, such as:
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
deny="*.googlebot.com"/>
From my reading of the documentation, this should be OK, but when this
line is present I cannot access any of my
servlets from any IP address. Do wildcards work here and, if so, what
am I doing wrong?
2. Is it possible for a give IP to permit access to some servlets while
denying access to others?
Thanks,
Sanford Stein
CyberTools Inc.
--
------------------------------------------------------------------------
CyberTools Logo <http://CyberTools.biz> *Sanford Stein *| *CyberTools,
Inc.*
75 Arlington Street, Suite 500, Boston MA 02116 | 800.894.9206 x
103 | F 888.899.0346
Sanford.Stein@CyberTools.biz <ma...@CyberTools.biz> |
CyberTools.biz <http://CyberTools.biz> | Build-It-Once Development
Re: [OT] Denying IPs using the Valve command in context.xml
Posted by André Warnier <aw...@ice-sa.com>.
Sanford Stein wrote:
...
> I am not intentionally sending HTML e-mails--perhaps my Thunderbird
> client is doing something of which I am unaware.
>
You can set this either in your global preferences for sending emails
(Options..Composition..General..Send Options), and/or specifically in your address book,
for the address "users@tomcat.apache.org".
("prefers to receive messages formatted as.. Plain text")
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sanford,
On 10/4/2011 3:40 PM, Sanford Stein wrote:
> I am not intentionally sending HTML e-mails--perhaps my
> Thunderbird client is doing something of which I am unaware.
You can configure tb to send plain-text to certain recipients.
Consider adding users@tomcat.apache.org to such a list.
> By escaping my punctuation characters, I was able to get
> "\*\.googlebot\.com" and other such addresses to work.
Good.
> I tried to use the filter feature to restrict an IP address to
> certain class files only. Here is what I put into web.xml:
>
> <filter> <filter-name>Remote Address Filter</filter-name>
> <filter-class>org.apache.catalina.filters.RemoteAddrFilter</filter-class>
>
>
<init-param>
> <param-name>deny</param-name>
> <param-value>24\.13\.86\.5</param-value> </init-param> </filter>
> <filter-mapping> <filter-name>Remote Address Filter</filter-name>
> <url-pattern>/CyberHTML</url-pattern> </filter-mapping> <filter>
> <filter-name>Remote Address Filter 2</filter-name>
> <filter-class>org.apache.catalina.filters.RemoteAddrFilter</filter-class>
>
>
<init-param>
> <param-name>allow</param-name>
> <param-value>24\.13\.86\.5</param-value> </init-param> </filter>
> <filter-mapping> <filter-name>Remote Address Filter
> 2</filter-name> <url-pattern>/TunnelServlet</url-pattern>
> <filter-mapping>
>
> The result was that 24.13.86.5 was denied access to BOTH servlets.
> (They are both in the 'classes' subdirectory.) If someone can
> see anything I am doing wrong, I would appreciate your response.
Note that you have mapped the filters by URL and not by servlet. If
you want to map by servlet and not by URL, you can use <servlet-name>
instead of <url-mapping>.
I can't explain why you are getting denials under both URLs, though.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6Lb3YACgkQ9CaO5/Lv0PDf8gCbBoE2/LpouKwuWH5hzFTzMy2R
makAn2xT/0Dq9E4nopGLpPZ9E36abgs6
=HV8Y
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Sanford Stein <Sa...@cybertools.biz>.
Andre, Christopher, and Konstantin,
Thank you for your prompt responses and your suggestions.
I apologize for not indicating my Tomcat version -- it is 5.5.23. My OS
is RHEL 5.6.
I am not intentionally sending HTML e-mails--perhaps my Thunderbird
client is doing something of which I am unaware.
By escaping my punctuation characters, I was able to get
"\*\.googlebot\.com" and other such addresses to work.
I tried to use the filter feature to restrict an IP address to certain
class files only. Here is what I put into web.xml:
<filter>
<filter-name>Remote Address Filter</filter-name>
<filter-class>org.apache.catalina.filters.RemoteAddrFilter</filter-class>
<init-param>
<param-name>deny</param-name>
<param-value>24\.13\.86\.5</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Remote Address Filter</filter-name>
<url-pattern>/CyberHTML</url-pattern>
</filter-mapping>
<filter>
<filter-name>Remote Address Filter 2</filter-name>
<filter-class>org.apache.catalina.filters.RemoteAddrFilter</filter-class>
<init-param>
<param-name>allow</param-name>
<param-value>24\.13\.86\.5</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Remote Address Filter 2</filter-name>
<url-pattern>/TunnelServlet</url-pattern>
<filter-mapping>
The result was that 24.13.86.5 was denied access to BOTH servlets.
(They are both in the 'classes' subdirectory.) If someone can see
anything I am doing wrong, I would appreciate your response.
Thanks,
Sanford Stein
CyberTools Inc.
Re: Denying IPs using the Valve command in context.xml
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Tue, Oct 4, 2011 at 22:50, André Warnier <aw...@ice-sa.com> wrote:
[...]
>
> So my question is : which of Matcher or Pattern is really used in the
> Valve's code ?
>
You use a Matcher to match. A Pattern is only the compiled form of a regex:
final String re = "^";
final Pattern p = Pattern.compile(re);
final Matcher m = p.matcher("myinput");
if (m.matches())
// etc
So, the fact that Matcher instances are not thread safe is not really
the problem.
[...]
>
> - or the documentation should be amended to indicate that the expression
> provided for allow and deny is already automatically anchored at the
> beginning and end of the string.
Agreed. The Tomcat documentation also suffered the same problem (wrt
regex usage in its <regex-mapper> IIRC) and I've had the doc fixed :p
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 10/4/2011 5:48 PM, André Warnier wrote:
> Yes, because if one defines e.g. a Pattern "^abcdef" and uses it
> via yesno = Pattern.matches("^abcdef",input); it will actually
> match the pattern at the beginning of the string only, which is
> what one would expect. Thus
>
> Pattern.matches("^abc","abcdef");
>
> would return true, while this :
>
> Pattern.compile("^abc").matcher("abcdef").matches()
>
> would return false (according to what I read in the documentation
> of Matcher.matches()). Not so ?
I'm not sure how Pattern.matches() would be different than
Pattern.matcher().matches(), given that it is documented to be identical.
>>> So my question is : which of Matcher or Pattern is really used
>>> in the Valve's code ?
>>
>> You could read the code :)
>
> Do you mean to say that trying to configure Tomcat according to
> the online documentation, with the purpose of using it as a
> servlet container, is reserved exclusively for java programmers ?
> ;-)
No, I meant to say that you've been around long enough that you don't
have to speculate.
> I guess that what I have trouble understanding here, is how the
> Java regex library can go about allowing to create a Pattern like
> "^abc", and then using it in a Matcher.matches() method, completely
> ignoring the anchors which it accepted in the Pattern and silently
> inserting its own.
It can and should, because it's documented to do so. Nobody is saying
it's the "right" thing to do... just that it's what it does do.
> But then, how come they are not, in the allow/deny of the Valve ?
Because of the choice to use Matcher.matches() instead of something
more nuanced.
> Does the Valve code itself strip any provided anchors, and "force"
> ^ and $ around the expression provided in the allow/deny attributes
> ?
No, it keeps them in-tact. It's the library that essentially ignores them.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6LhOQACgkQ9CaO5/Lv0PBFfwCfcT5d7reodusMTNR2GgWvBoZx
wigAoLKwFDgE1p7ijEPxnpn2rFCwbAYT
=kZqV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Tue, Oct 4, 2011 at 23:48, André Warnier <aw...@ice-sa.com> wrote:
>>
>>> And, it seems that the Pattern class, and its own .matches()
>>> method, does work in the way that a non-exclusively-java programmer
>>> would expect, anchors and all.
>>
>> Does it?
>>
>
> Yes, because if one defines e.g. a Pattern "^abcdef" and uses it via
> yesno = Pattern.matches("^abcdef",input);
> it will actually match the pattern at the beginning of the string only,
> which is what one would expect. Thus
>
> Pattern.matches("^abc","abcdef");
>
> would return true, while this :
>
> Pattern.compile("^abc").matcher("abcdef").matches()
>
> would return false (according to what I read in the documentation of
> Matcher.matches()).
> Not so ?
>
>>
Well, no, and here you see the incoherency of Java vocabulary vs the
rest of the regex world ;)
The Javadoc should really read "attempts to match the _whole_
input".
Bah. Too late to fix things...
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
...
>
>> And, it seems that the Pattern class, and its own .matches()
>> method, does work in the way that a non-exclusively-java programmer
>> would expect, anchors and all.
>
> Does it?
>
Yes, because if one defines e.g. a Pattern "^abcdef" and uses it via
yesno = Pattern.matches("^abcdef",input);
it will actually match the pattern at the beginning of the string only, which is what one
would expect. Thus
Pattern.matches("^abc","abcdef");
would return true, while this :
Pattern.compile("^abc").matcher("abcdef").matches()
would return false (according to what I read in the documentation of Matcher.matches()).
Not so ?
>
>> So my question is : which of Matcher or Pattern is really used in
>> the Valve's code ?
>
> You could read the code :)
>
Do you mean to say that trying to configure Tomcat according to the online documentation,
with the purpose of using it as a servlet container, is reserved exclusively for java
programmers ?
;-)
...
I guess that what I have trouble understanding here, is how the Java regex library can go
about allowing to create a Pattern like "^abc", and then using it in a Matcher.matches()
method, completely ignoring the anchors which it accepted in the Pattern and silently
inserting its own.
Unless apparently, if you first call
Matcher.useAnchoringBounds(true)
/then/ it would respect the anchors in the Pattern.
Or ?
I must admit that I cannot really be sure of my interpretation of the useAnchoringBounds
method :
quote :
public Matcher useAnchoringBounds(boolean b)
Sets the anchoring of region bounds for this matcher.
Invoking this method with an argument of true will set this matcher to use anchoring
bounds. If the boolean argument is false, then non-anchoring bounds will be used.
Using anchoring bounds, the boundaries of this matcher's region match anchors such as
^ and $.
Without anchoring bounds, the boundaries of this matcher's region will not match
anchors such as ^ and $.
By default, a matcher uses anchoring region boundaries.
unquote
The above would seem to indicate that by default, anchors like ^ and $ (in the Pattern ?)
are being respected.
But then, how come they are not, in the allow/deny of the Valve ?
Does the Valve code itself strip any provided anchors, and "force" ^ and $ around the
expression provided in the allow/deny attributes ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 10/4/2011 4:50 PM, André Warnier wrote:
> I agree with Francis that the way the documentation is written, is
> confusing for anyone not dedicating his life to Java programming
> (like the sysadmins and other perl programmers who have to use this
> to configure Tomcat). In classical regex usage, if you want
> something anchored, you have to say so explicitly. In classical
> regex usage, if you do use anchors such as ^ and $, you expect them
> to take effect, and not to be silently ignored.
I suspect it's not going to change, as that would be an incompatible
change. Since it's security-related, it's not something to be changed
lightly.
> And, it seems that the Pattern class, and its own .matches()
> method, does work in the way that a non-exclusively-java programmer
> would expect, anchors and all.
Does it?
"
Compiles the given regular expression and attempts to match the given
input against it.
An invocation of this convenience method of the form
Pattern.matches(regex, input);
behaves in exactly the same way as the expression
Pattern.compile(regex).matcher(input).matches()
If a pattern is to be used multiple times, compiling it once and
reusing it will be more efficient than invoking this method each time.
"
> So my question is : which of Matcher or Pattern is really used in
> the Valve's code ?
You could read the code :)
> Furthermore, about the Tomcat Valve documentation, I would opine :
>
> - either the documentation remains as it is, and in the code, it
> should use the Pattern class for matching (and thus not
> automatically anchor, but allow the usage of explicit anchors in
> the provided patterns for allow and deny).
Not going to change the code (see above). Also, Pattern.matches is
static and re-compiles the pattern every time. That's also not going
to change.
> - or the documentation should be amended to indicate that the
> expression provided for allow and deny is already automatically
> anchored at the beginning and end of the string. (And also that
> this is not thread-safe, and may occasionally miss a host ?)
Documentation patches are always welcome. Thread-safety is not an
issue (hint:read the code).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6Lc4wACgkQ9CaO5/Lv0PCySgCgkLqSiAVx4D/F/7RTbKopzQBf
hScAn3VAYSNyoHzgi5jg4h3nDAat0bQt
=QpMq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by André Warnier <aw...@ice-sa.com>.
Francis GALIEGUE wrote:
> On Tue, Oct 4, 2011 at 21:40, André Warnier <aw...@ice-sa.com> wrote:
> [...]
>> I am not sure that I follow the depths of the Java implementation of all of
>> this, but please note that "\.googlebot\.com$" is a regexp /anchored/ at the
>> end of the string.
>> In other words, I would be surprised (and disappointed) if this did not
>> match the hostnames "bot1.googlebot.com" and "bot123.bots.googlebot.com"
>
> It's quite simple really: .matches(), which is used, anchors the regex
> at the beginning and end. .matches("re") is equivalent to
> .lookingAt("^re$"), even if your re is already anchored.
>
> Unfortunately, this method's misleading name and the prevalence of
> Java has led a lot of people to believe that regex matching was done
> on the whole input, which is of course false.
>
Having now consulted the java.util.regex package documentation (as mentioned in the Tomcat
Valves documentation), these are my own remarks :
I agree with Francis that the way the documentation is written, is confusing for anyone
not dedicating his life to Java programming (like the sysadmins and other perl programmers
who have to use this to configure Tomcat). In classical regex usage, if you want something
anchored, you have to say so explicitly. In classical regex usage, if you do use anchors
such as ^ and $, you expect them to take effect, and not to be silently ignored.
One thing that strikes me, is in :
http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html
it says "Instances of this class are immutable and are safe for use by multiple concurrent
threads. Instances of the Matcher class are not safe for such use."
(But the Matcher class itself seems silent about this).
And, it seems that the Pattern class, and its own .matches() method, does work in the way
that a non-exclusively-java programmer would expect, anchors and all.
So my question is : which of Matcher or Pattern is really used in the Valve's code ?
Furthermore, about the Tomcat Valve documentation, I would opine :
- either the documentation remains as it is, and in the code, it should use the Pattern
class for matching (and thus not automatically anchor, but allow the usage of explicit
anchors in the provided patterns for allow and deny).
- or the documentation should be amended to indicate that the expression provided for
allow and deny is already automatically anchored at the beginning and end of the string.
(And also that this is not thread-safe, and may occasionally miss a host ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Tue, Oct 4, 2011 at 21:40, André Warnier <aw...@ice-sa.com> wrote:
[...]
>>
> I am not sure that I follow the depths of the Java implementation of all of
> this, but please note that "\.googlebot\.com$" is a regexp /anchored/ at the
> end of the string.
> In other words, I would be surprised (and disappointed) if this did not
> match the hostnames "bot1.googlebot.com" and "bot123.bots.googlebot.com"
It's quite simple really: .matches(), which is used, anchors the regex
at the beginning and end. .matches("re") is equivalent to
.lookingAt("^re$"), even if your re is already anchored.
Unfortunately, this method's misleading name and the prevalence of
Java has led a lot of people to believe that regex matching was done
on the whole input, which is of course false.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by André Warnier <aw...@ice-sa.com>.
Francis GALIEGUE wrote:
> On Tue, Oct 4, 2011 at 21:08, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
> [...]
>> - From the docs:
>>
>> "If this attribute [allow] is specified, the remote address MUST match
>> for this request to be accepted".
>>
>> "If this attribute [deny] is specified, the remote address MUST NOT
>> match for this request to be accepted".
>>
>> I don't think Matacher.lookingAt is appropriate for this kind of checking.
>>
>
> Well, it depends on the definition of "match", I guess. For me, a
> regex matches an input if it matches anywhere in the input! Which is
> pretty much the definition of regex matching, and which is why Java's
> .matches() methods are misnomers...
>
I am not sure that I follow the depths of the Java implementation of all of this, but
please note that "\.googlebot\.com$" is a regexp /anchored/ at the end of the string.
In other words, I would be surprised (and disappointed) if this did not match the
hostnames "bot1.googlebot.com" and "bot123.bots.googlebot.com" e.g.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 10/5/2011 10:28 AM, Mark H. Wood wrote:
> Having said that, I think that an anchored partial match
> (lookingAt()) really is the least-bad fit to the address problem,
> since we're usually more concerned about the first, second, and
> perhaps third quads of an IP address and the trailing part is
> considered insignificant.
Again, I'm guessing that this just isn't going to change, no matter how
good the arguments are, unless there is some new syntax that
differentiates the old behavior from the new (such as adding prefix and
postfix / like /\.0\./ if you want to match anything that has a 0 as
either of the middle two octets of an IPv4 address).
> As I posted previously, though, it's still pretty bad: how would
> you match a /27?
This valve can't do that, anyway. If you want /27, you have to list them
all out. Note that there is a patch currently under development to
handle CIDR masks such as this one:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51953
> Domain matches, OTOH, might take matches() as least-bad of the
> regex types, since the prefix tends to be the don't-care part.
I see these as mirror-images of one-another: the implementation fails in
both cases by requiring you to add .* to either the beginning or the end
of your regular expression.
No matter what else happens, it's worth pointing-out in the
documentation what's really going on, here.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6M1PEACgkQ9CaO5/Lv0PB0HQCfYpd59y18bJilfBPasp2MRyDl
Np0An1NWgVCHEfOWnhz4+PLMiBtTkhne
=adNX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Tue, Oct 04, 2011 at 09:11:28PM +0200, Francis GALIEGUE wrote:
> On Tue, Oct 4, 2011 at 21:08, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
> [...]
> >
> > - From the docs:
> >
> > "If this attribute [allow] is specified, the remote address MUST match
> > for this request to be accepted".
> >
> > "If this attribute [deny] is specified, the remote address MUST NOT
> > match for this request to be accepted".
> >
> > I don't think Matacher.lookingAt is appropriate for this kind of checking.
> >
>
> Well, it depends on the definition of "match", I guess. For me, a
> regex matches an input if it matches anywhere in the input! Which is
> pretty much the definition of regex matching, and which is why Java's
> .matches() methods are misnomers...
Hmmm, old SNOBOL coders may recall the handy concept of "anchored"
(.matches(), .lookingAt()) vs. "unanchored" (.find()) matching. The
actual difference between matches() and lookingAt() is that of
matching the entire string vs. matching a prefix.
Having said that, I think that an anchored partial match (lookingAt())
really is the least-bad fit to the address problem, since we're
usually more concerned about the first, second, and perhaps third
quads of an IP address and the trailing part is considered
insignificant. As I posted previously, though, it's still pretty bad:
how would you match a /27?
Domain matches, OTOH, might take matches() as least-bad of the regex
types, since the prefix tends to be the don't-care part. Again,
though, since domain structure is significant, regex matching tends to
require a lot of complexity that could be considered boilerplate: you
almost always need to write all the fiddly escaped dots and stuff.
(If you think SNOBOL is ancient: I'm trying to recall whether COMIT
II embodied all of these concepts. :-)
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
Re: Denying IPs using the Valve command in context.xml
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Tue, Oct 4, 2011 at 21:08, Christopher Schultz
<ch...@christopherschultz.net> wrote:
[...]
>
> - From the docs:
>
> "If this attribute [allow] is specified, the remote address MUST match
> for this request to be accepted".
>
> "If this attribute [deny] is specified, the remote address MUST NOT
> match for this request to be accepted".
>
> I don't think Matacher.lookingAt is appropriate for this kind of checking.
>
Well, it depends on the definition of "match", I guess. For me, a
regex matches an input if it matches anywhere in the input! Which is
pretty much the definition of regex matching, and which is why Java's
.matches() methods are misnomers...
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 10/5/2011 9:57 AM, Mark H. Wood wrote:
> Part of the problem with this valve is that regex matching is such
> a (IMHO) bizarre choice for IP address matching. IP addresses have
> a structure which is very unlike text, and the customary and
> expected matches take a bit of finagling to do in regexes.
This was done somewhat recently (can't find the enhancement request at
the moment) so that partial IP address matches could be done. It's
done at the RequestFilterValve level which allows any of the
subclasses to use regular expressions to match pretty much any
allow/deny request property. Take a look a the code to see the level
of reuse it provides. While it may not exactly be the smartest choice
for IP addresses specifically, you don't have to use it for IP
addresses :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6M1i0ACgkQ9CaO5/Lv0PAnuwCfZNhDWns5QDu5Lee+txGP0uU+
iP0An3wBwYz3+DEp7YrfDt1lJM0WfISb
=HZFI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Wed, Oct 5, 2011 at 15:57, Mark H. Wood <mw...@iupui.edu> wrote:
> Part of the problem with this valve is that regex matching is such a
> (IMHO) bizarre choice for IP address matching. IP addresses have a
> structure which is very unlike text, and the customary and expected
> matches take a bit of finagling to do in regexes.
>
> I should try writing netmask and CIDR address matchers.
>
I'm doing just that at the moment :p
https://issues.apache.org/bugzilla/show_bug.cgi?id=51953
> Likewise the hostname valve. Domain names also are structured, and
> people who have just discovered the valve may be expecting quite a
> different type of matching than what they get. I had to read the
> documentation very slowly and carefully before I could get the
> customary match styles out of my head.
>
> Again, I should try writing a DNS-style globber. It might be fun.
> (But don't hold your breath waiting for it.)
>
Ideally, all of Apache's "allow from" and "deny from" (along with
Order while we are at it) could/should be implemented. I'm starting
with the most simple case of all.
It'll be fun to implement, say, 10., .mydomain.com and such...
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
Part of the problem with this valve is that regex matching is such a
(IMHO) bizarre choice for IP address matching. IP addresses have a
structure which is very unlike text, and the customary and expected
matches take a bit of finagling to do in regexes.
I should try writing netmask and CIDR address matchers.
Likewise the hostname valve. Domain names also are structured, and
people who have just discovered the valve may be expecting quite a
different type of matching than what they get. I had to read the
documentation very slowly and carefully before I could get the
customary match styles out of my head.
Again, I should try writing a DNS-style globber. It might be fun.
(But don't hold your breath waiting for it.)
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
Re: Denying IPs using the Valve command in context.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Francis,
On 10/4/2011 2:53 PM, Francis GALIEGUE wrote:
> On Tue, Oct 4, 2011 at 20:46, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> Francis,
>>
>> On 10/4/2011 2:37 PM, Francis GALIEGUE wrote:
>>> On Tue, Oct 4, 2011 at 19:49, André Warnier <aw...@ice-sa.com>
>>> wrote: [...]
>>>
>>>> In this particular case, "\.googlebot\.com$" would be better
>>>> (with the RemoteHostValve).
>>>>
>>>
>>> No, that would not even work, for there is a fatal flaw in all
>>> existing Valves and Filters using regexes: they use the
>>> .matches() method of Matcher instead of .lookingAt(), which
>>> means you _must_ specify the whole hostname in the regex...
>>
>> Are you saying that ".*\.googlebot\.com" doesn't work?
>>
>
> No, this would work. However, "\.googlebot\.com$" will not.
- From the docs:
"If this attribute [allow] is specified, the remote address MUST match
for this request to be accepted".
"If this attribute [deny] is specified, the remote address MUST NOT
match for this request to be accepted".
I don't think Matacher.lookingAt is appropriate for this kind of checking.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6LWcgACgkQ9CaO5/Lv0PC8xACgqAzmTNKrfbmpDZAkFK4RgjfV
C8gAn0f0bZB10jP6O1wjfJSl9tTYTBuK
=ejl6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Tue, Oct 4, 2011 at 20:46, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Francis,
>
> On 10/4/2011 2:37 PM, Francis GALIEGUE wrote:
>> On Tue, Oct 4, 2011 at 19:49, André Warnier <aw...@ice-sa.com> wrote:
>> [...]
>>
>>> In this particular case, "\.googlebot\.com$" would be better
>>> (with the RemoteHostValve).
>>>
>>
>> No, that would not even work, for there is a fatal flaw in all
>> existing Valves and Filters using regexes: they use the .matches()
>> method of Matcher instead of .lookingAt(), which means you _must_
>> specify the whole hostname in the regex...
>
> Are you saying that ".*\.googlebot\.com" doesn't work?
>
No, this would work. However, "\.googlebot\.com$" will not.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Francis,
On 10/4/2011 2:37 PM, Francis GALIEGUE wrote:
> On Tue, Oct 4, 2011 at 19:49, André Warnier <aw...@ice-sa.com> wrote:
> [...]
>
>> In this particular case, "\.googlebot\.com$" would be better
>> (with the RemoteHostValve).
>>
>
> No, that would not even work, for there is a fatal flaw in all
> existing Valves and Filters using regexes: they use the .matches()
> method of Matcher instead of .lookingAt(), which means you _must_
> specify the whole hostname in the regex...
Are you saying that ".*\.googlebot\.com" doesn't work?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6LVIQACgkQ9CaO5/Lv0PDxPQCdHaH4ecRo0h/TXmdRYMZ1Egx2
ZfUAoIjk3/F2inEAM4eFxEcR6NXA5kva
=Xmb9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Tue, Oct 4, 2011 at 19:49, André Warnier <aw...@ice-sa.com> wrote:
[...]
> In this particular case, "\.googlebot\.com$" would be better (with the
> RemoteHostValve).
>
No, that would not even work, for there is a fatal flaw in all
existing Valves and Filters using regexes: they use the .matches()
method of Matcher instead of .lookingAt(), which means you _must_
specify the whole hostname in the regex...
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by André Warnier <aw...@ice-sa.com>.
Here are the Valves which exist under Tomcat 7.0, the latest version.
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html
Which one are you talking about, and which Tomcat version ?
Note that org.apache.catalina.valves.RemoteAddrValve can filter on the base of the client
/IP address/, not its hostname (as a careful read of the on-line documentation makes clear).
Note also that as well the org.apache.catalina.valves.RemoteHostValve as the
org.apache.catalina.valves.RemoteAddrValve filter on the base of /regular expressions/,
and "*.googlebot.com" is not one of those.
In this particular case, "\.googlebot\.com$" would be better (with the RemoteHostValve).
And finally, note also that this may be quite "expensive", in the sense that Tomcat may
need to do a couple of DNS lookups per client, to allow this to work.
In this particular case, would a "robots.txt" file in the ROOT of your server, not be
better ? Google bots should be well-behaved.
Sanford Stein wrote:
> 1. I am using wildcards in my IP addresses, such as:
> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
> deny="*.googlebot.com"/>
>
> From my reading of the documentation, this should be OK, but when this line is
> present I cannot access any of my
> servlets from any IP address. Do wildcards work here and, if so, what am I
> doing wrong?
>
> 2. Is it possible for a give IP to permit access to some servlets while denying
> access to others?
>
> Thanks,
> Sanford Stein
> CyberTools Inc.
> --
> --------------------------------------------------------------------------------
> CyberTools Logo <http://CyberTools.biz> *Sanford Stein *| *CyberTools, Inc.*
> 75 Arlington Street, Suite 500, Boston MA 02116 | 800.894.9206 x 103 | F
> 888.899.0346
> Sanford.Stein@CyberTools.biz <ma...@CyberTools.biz> |
> CyberTools.biz <http://CyberTools.biz> | Build-It-Once Development
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/10/4 Sanford Stein <Sa...@cybertools.biz>
>
> 1. I am using wildcards in my IP addresses, such as:
> <Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="*.googlebot.com"/>
>
> From my reading of the documentation, this should be OK, but when this line is present I cannot access any of my
> servlets from any IP address. Do wildcards work here and, if so, what am I doing wrong?
1. Please do not send HTML e-mails to this mailing list.
2. Your exact Tomcat version = ?
3. Wildcards never worked there. RemoteAddrValve uses Regular expressions.
4. RemoteAddrValve works with IP addresses, not host names.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Denying IPs using the Valve command in context.xml
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sanford,
On 10/4/2011 1:21 PM, Sanford Stein wrote:
> 1. I am using wildcards in my IP addresses, such as: <Valve
> className="org.apache.catalina.valves.RemoteAddrValve"
> deny="*.googlebot.com"/>
That doesn't look like a valid regular expression.
> From my reading of the documentation, this should be OK, but when
> this line is present I cannot access any of my servlets from any IP
> address. Do wildcards work here and, if so, what am I doing
> wrong?
You are trying to use a glob-style wildcard instead of a regular
expression.
> 2. Is it possible for a give IP to permit access to some servlets
> while denying access to others?
I don't think you can do this with a <Valve>, but you can do it with a
<Filter>
(http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Remote_Address_Filter)
that is only mapped to certain servlets.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6LRdwACgkQ9CaO5/Lv0PDUvwCfaycwYGMvZc7l7qGf618uIUa9
DKwAn3gcfFCmsYA+GO9K2FFxchMZUUq3
=5fnP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org