You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ian McFarland <im...@neo.com> on 2002/07/20 00:57:31 UTC
Another valve question
This one on the host and address filters, and this one has to do with
allow and deny precedence. It's not clear from the docs how this is
handled when both an allow and deny attribute are assigned, and in the
JavaDoc it sounds like if allow is specified deny is not consulted. Is
this true?
The allow deny semantics I'm familiar with (e.g. those in Apache, and
NCSA before it) specify an ordering, and apply both sets of rules. This
allows you to do something like allow *.foo.com but still deny
*.baduser.foo.com, with a result that only people coming from foo.com
but not coming from baduser.foo.com can access the resource.
Also, are the valves processed in the order specified in the server.xml?
If so, then I imagine I could do something like:
<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.foo.com"/>
<Valve className="org.apache.catalina.valves.RemoteHostValve"
deny="*.baduser.foo.com"/>
...and get the same result.
Thoughts?
Thanks again,
-Ian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
niggle application framework
Posted by Paul Phillips <pa...@partitura.com>.
Anyone out there using the Niggle application framework with Tomcat. If
so, do you like it? Any special strengths, weaknesses?
It looks interesting to me, and I'd like to know what others think...
Regards,
Paul Phillips
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another valve question
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 19 Jul 2002, Ian McFarland wrote:
> Date: Fri, 19 Jul 2002 16:56:10 -0700
> From: Ian McFarland <im...@neo.com>
> To: Craig R. McClanahan <cr...@apache.org>,
> Tomcat List <to...@jakarta.apache.org>
> Cc: Ian McFarland <im...@neo.com>
> Subject: Re: Another valve question
>
> Thanks, Craig!
>
> This helps a lot. It gives me a much clearer conceptual model of how
> things work.
>
>
> On Friday, July 19, 2002, at 04:16 PM, Craig R. McClanahan wrote:
> > Valves are executed in the order listed in server.xml, so this would
> > indeed have the same result at a very slight performance cost (because
> > of
> > the extra stack frame triggered by the separate valve. Of course, so
> > would the opposite order in this particular scenario.
> >
>
> Oh, right, these aren't really order sensitive, since the exclusions are
> effectively additive anyway. Silly me.
>
:-)
> One clarifying question about the following:
>
> > The other important consideration is which container element (<Engine>,
> > <Host>, or <Context>) you nest the valve inside. This constrains the
> > set
> > of requests that ever pass through the valve in the first place -- to
> > only
> > the ones being processed by that particular container. For example, a
> > valve nested inside a <Context> will never see any requests for any
> > other
> > webapp on the same (or different) virtual host.
> >
>
> So if I had something like this (and I understand correctly):
>
> <Host>
> <Valve className="org.apache.catalina.valves.RemoteHostValve"
> allow="*.foo.com"/>
> <Context path="/safecontext">
> <Valve className="org.apache.catalina.valves.RemoteHostValve"
> deny="*.baduser.foo.com"/>
> </Context>
> </Host>
>
> (Many required attributes omitted)
>
> Then the following would be true:
> 1. User from *.baduser.foo.com would see content on the host, but not
> content in the /safecontext context.
More precisely, they could see content from other webapps on this host --
the host itself doesn't really have any "content".
> 2. User from elsewhere.com would not be able to see any content on the
> host.
Correct.
> 3. The second valve would never get executed on the request from
> elsewhere.com, because it had already been denied by the first valve.
>
Also correct -- the first valve would have returned the "forbidden" error
and finished the response without proceeding.
> Is that right?
>
You've got it.
In essence, the request processing functionality of a Valve is the
Tomcat-internal analog of what Filters can do for you at the application
level. For example, you could implement exactly this kind of request
filtering with a Filter instead, but only inside the app. The nice thing
about valves for this purpose is they are configured by the Tomcat system
administrator (without modifying the webapp).
> Thanks for clearing this up for me. It makes sense.
>
> Cheers,
> -Ian
>
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another valve question
Posted by Ian McFarland <im...@neo.com>.
Thanks, Craig!
This helps a lot. It gives me a much clearer conceptual model of how
things work.
On Friday, July 19, 2002, at 04:16 PM, Craig R. McClanahan wrote:
> Valves are executed in the order listed in server.xml, so this would
> indeed have the same result at a very slight performance cost (because
> of
> the extra stack frame triggered by the separate valve. Of course, so
> would the opposite order in this particular scenario.
>
Oh, right, these aren't really order sensitive, since the exclusions are
effectively additive anyway. Silly me.
One clarifying question about the following:
> The other important consideration is which container element (<Engine>,
> <Host>, or <Context>) you nest the valve inside. This constrains the
> set
> of requests that ever pass through the valve in the first place -- to
> only
> the ones being processed by that particular container. For example, a
> valve nested inside a <Context> will never see any requests for any
> other
> webapp on the same (or different) virtual host.
>
So if I had something like this (and I understand correctly):
<Host>
<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.foo.com"/>
<Context path="/safecontext">
<Valve className="org.apache.catalina.valves.RemoteHostValve"
deny="*.baduser.foo.com"/>
</Context>
</Host>
(Many required attributes omitted)
Then the following would be true:
1. User from *.baduser.foo.com would see content on the host, but not
content in the /safecontext context.
2. User from elsewhere.com would not be able to see any content on the
host.
3. The second valve would never get executed on the request from
elsewhere.com, because it had already been denied by the first valve.
Is that right?
Thanks for clearing this up for me. It makes sense.
Cheers,
-Ian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Another valve question
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 19 Jul 2002, Ian McFarland wrote:
> Date: Fri, 19 Jul 2002 15:57:31 -0700
> From: Ian McFarland <im...@neo.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat List <to...@jakarta.apache.org>
> Cc: Ian McFarland <ia...@neo.com>
> Subject: Another valve question
>
> This one on the host and address filters, and this one has to do with
> allow and deny precedence. It's not clear from the docs how this is
> handled when both an allow and deny attribute are assigned, and in the
> JavaDoc it sounds like if allow is specified deny is not consulted. Is
> this true?
>
For any single RemoteHostValue or RemoteAddrValve entry that has both
allow and deny properties, the denies are checked first. Only if none of
the deny patterns match are the allow patterns checked. The Javadocs
describing this are on RequestFilterValve, which is the superclass that
both RemoteHostValve and RemoteAddrValve are based on.
> The allow deny semantics I'm familiar with (e.g. those in Apache, and
> NCSA before it) specify an ordering, and apply both sets of rules. This
> allows you to do something like allow *.foo.com but still deny
> *.baduser.foo.com, with a result that only people coming from foo.com
> but not coming from baduser.foo.com can access the resource.
>
Because of the implemented ordering, you can accomplish this with:
<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.foo.com" deny="*.badduser.foo.com"/>
However, there is no mechanism to alter the order within a single
filter Valve instance. You can play games with multiple valves, however.
> Also, are the valves processed in the order specified in the server.xml?
> If so, then I imagine I could do something like:
>
> <Valve className="org.apache.catalina.valves.RemoteHostValve"
> allow="*.foo.com"/>
> <Valve className="org.apache.catalina.valves.RemoteHostValve"
> deny="*.baduser.foo.com"/>
>
> ...and get the same result.
>
Valves are executed in the order listed in server.xml, so this would
indeed have the same result at a very slight performance cost (because of
the extra stack frame triggered by the separate valve. Of course, so
would the opposite order in this particular scenario.
The other important consideration is which container element (<Engine>,
<Host>, or <Context>) you nest the valve inside. This constrains the set
of requests that ever pass through the valve in the first place -- to only
the ones being processed by that particular container. For example, a
valve nested inside a <Context> will never see any requests for any other
webapp on the same (or different) virtual host.
> Thoughts?
>
> Thanks again,
> -Ian
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: TOMCAT + SSL or APACHE+TOMCAT+SSL??
Posted by "Power-Netz (Schwarz)" <sc...@power-netz.de>.
>
> Hello,
>
> I need to have SSL certificate . Web server is Tomcat4.04 serving
> static and
> dynamic pages. Should i upgrade it to APACHE+TOMCAT+SSL or TOMCAT+SSL will
> do? .
TOMCAT+SSL will do.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
TOMCAT + SSL or APACHE+TOMCAT+SSL??
Posted by Sujith Mathew <su...@myrealbox.com>.
Hello,
I need to have SSL certificate . Web server is Tomcat4.04 serving static and
dynamic pages. Should i upgrade it to APACHE+TOMCAT+SSL or TOMCAT+SSL will
do? .
Is there any reason i should upgrade to APACHE+TOMCAT+SSL??
Thanks in advance
Sujith Mathew
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
JSP Compilation Error
Posted by Ashish Kulkarni <ku...@yahoo.com>.
Hi
I get the following error when running jsp, but the
servlets have no problem.
I am running windows 2000 server
java.lang.NoClassDefFoundError: sun/tools/javac/Main
my env is as follows
JAVA_HOME=c:\j2sdk1.4.0
CLASSPATH=c:\j2sdk1.4.0\bin;%JAVA_HOME%\lib\tools.jar;C:\j2sdk1.4.0\jre\lib\rt.jar;C:\j2sdk1.4.0\jre\lib\jaws.jar;
TOMCAT_HOME=c:\tomcat4.0.4
So what should i do??
Ashish
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>