You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov> on 2012/11/29 20:41:22 UTC
Context Path for a subdirectory
Reading the docs: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
"..The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context."
If I have a webapp, with a www directory, and in that www directory are other directories, how would I restrict access to one of those subdirectories to the localhost?
webapps
webapp1
-WEB-INF
-classes
-lib
-www
-directory1
-directory2
Is the context path of directory1: /webapp1/directory1
Would I create a context named directory1.xml such as the following?
<?xml version="1.0" encoding="UTF-8"?>
<Context antiResourceLocking="false" privileged="true" path="/webapp1/directory1">
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
</Context>
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Mark Eggers <it...@yahoo.com>.
On 11/29/2012 12:32 PM, Leo Donahue - RDSA IT wrote:
>> -----Original Message----- From: Mark Eggers
>> [mailto:its_toasted@yahoo.com] Sent: Thursday, November 29, 2012
>> 1:12 PM To: Tomcat Users List Subject: Re: Context Path for a
>> subdirectory
>>
>> On 11/29/2012 11:41 AM, Leo Donahue - RDSA IT wrote:
>>> Reading the docs:
>>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>>>
>>> "..The web application used to process each HTTP request is
>>> selected by
>> Catalina based on matching the longest possible prefix of the
>> Request URI against the context path of each defined Context."
>>>
>>> If I have a webapp, with a www directory, and in that www
>>> directory are
>> other directories, how would I restrict access to one of those
>> subdirectories to the localhost?
>>>
>>> webapps webapp1 -WEB-INF -classes -lib -www -directory1
>>> -directory2
>>>
>>> Is the context path of directory1: /webapp1/directory1
>>>
>>> Would I create a context named directory1.xml such as the
>>> following?
>>>
>>> <?xml version="1.0" encoding="UTF-8"?> <Context
>>> antiResourceLocking="false" privileged="true"
>>> path="/webapp1/directory1">
>>>
>>> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
>>> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> </Context>
>>>
>>>
>>> Leo
>>
>> How about:
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html
>>
>> In particular:
>>
>>
>> http://tomcat.apache.org/tomcat-7.0-
>> doc/config/filter.html#Remote_Address_Filter
>>
>>
>> Although as has been discussed previously on the mailing list, the
>> regular expression is a bit simplistic.
>>
>> . . . . just my two cents. /mde/
>>
>
> Thank you Mark.
>
> I realized the first reply I got might be why not try it, my
> question, which I did, and of course I had it wrong.
>
> I thought of security-constraint right after I clicked send, but the
> filter will also work.
>
> http://planning.maricopa.gov/rest - needed to restrict access to one
> directory of that webapp. It's a third party app, but our data.
>
> Leo
I guess you're referring to an ip-constraint element inside the
security-constraint element?
Something like:
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<ip-constraint>127.0.0.1</ip-constraint>
<ip-constraint>192.168.1.0/24</ip-constraint>
</security-constraint>
From glancing around on the web, this looks like it's Resin - specific.
I didn't see ip-constraint in the 2.5 xsd or in the 3.0 xsd. If it's not
standard, I doubt it will make it into Tomcat. I'm sure one of the
committers (just a happy user here) will correct me if I'm wrong.
. . . . just my two cents
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Friday, November 30, 2012 8:20 AM
>> To: Tomcat Users List
>> Subject: Re: Context Path for a subdirectory
>>> Leo Donahue - RDSA IT wrote:
>>>
>>> If I can tag another question on the end of this thread:
>>>
>>> The Remote Address Filter has an option to set the denyStatus from 403 to
>> 404, or whatever. In general, I'm guessing it's better to respond that a
>> restricted resource is not found, rather than respond that is it there but forbidden?
>> Purely personal opinion : by doing this, you "kind of" violate the spirit of the HTTP
>> specification, and you create some confusion at the technical level.
>> And, essentially, you are lying to the client.
>> So, in general, it is not "better".
>>
>> But hey, it's your server, so you're free to return whatever you believe is most appropriate.
>> Within limits though. For example, if somewhere you provide a link to that section for
>> some people, but when they click on it, they get a "not found", they may think that your
>> application isn't working, or that your documentation is incorrect. While if they get a
>> "forbidden", they may realise that they need to ask for a permission.
>>
>
> Why is denyStatus an option? Why would someone use it?
>
Well, ok, let me revise my earlier and purely personal opinion, as per RFC 2616 :
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not
help and the request SHOULD NOT be repeated. If the request method was not HEAD and the
server wishes to make public why the request has not been fulfilled, it SHOULD describe
the reason for the refusal in the entity. If the server does not wish to make this
information available to the client, the status code 404 (Not Found) can be used instead.
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of
whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used
if the server knows, through some internally configurable mechanism, that an old resource
is permanently unavailable and has no forwarding address. This status code is commonly
used when the server does not wish to reveal exactly why the request has been refused, or
when no other response is applicable.
So it does say that if you want, you /can/ replace a 403 by a 404.
You are thus forgiven.
And that is probably the reason why the denyStatus option was provided : the Tomcat
developers did read the HTTP RFC. Clever guys, he ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
>Sent: Friday, November 30, 2012 8:32 AM
>To: Tomcat Users List
>Subject: RE: Context Path for a subdirectory
>
>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>> Subject: RE: Context Path for a subdirectory
>
>> Why is denyStatus an option? Why would someone use it?
>
>Because some people still believe in security through obscurity.
>
> - Chuck
Security AND obscurity... only those that need to know. I can get in line with that. Why give someone a target to work on it you tell them they are forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
> Subject: RE: Context Path for a subdirectory
> Why is denyStatus an option? Why would someone use it?
Because some people still believe in security through obscurity.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@ice-sa.com]
>Sent: Friday, November 30, 2012 8:20 AM
>To: Tomcat Users List
>Subject: Re: Context Path for a subdirectory
>>
>>Leo Donahue - RDSA IT wrote:
>>
>> If I can tag another question on the end of this thread:
>>
>> The Remote Address Filter has an option to set the denyStatus from 403 to
>404, or whatever. In general, I'm guessing it's better to respond that a
>restricted resource is not found, rather than respond that is it there but forbidden?
>>
>
>Purely personal opinion : by doing this, you "kind of" violate the spirit of the HTTP
>specification, and you create some confusion at the technical level.
>And, essentially, you are lying to the client.
>So, in general, it is not "better".
>
>But hey, it's your server, so you're free to return whatever you believe is most appropriate.
>Within limits though. For example, if somewhere you provide a link to that section for
>some people, but when they click on it, they get a "not found", they may think that your
>application isn't working, or that your documentation is incorrect. While if they get a
>"forbidden", they may realise that they need to ask for a permission.
>
Why is denyStatus an option? Why would someone use it?
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Friday, November 30, 2012 12:23 AM
>> To: Tomcat Users List
>> Subject: Re: Context Path for a subdirectory
>>>>>> On 11/29/2012 11:41 AM, Leo Donahue - RDSA IT wrote:
>>>>>>> Reading the docs:
>>>>>>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>>>>>>>
>>>>>>> "..The web application used to process each HTTP request is
>>>>>>> selected by
>>>>>> Catalina based on matching the longest possible prefix of the
>>>>>> Request URI against the context path of each defined Context."
>>>>>>> If I have a webapp, with a www directory, and in that www
>>>>>>> directory are
>>>>>> other directories, how would I restrict access to one of those
>>>>>> subdirectories to the localhost?
>>>>>>> webapps
>>>>>>> webapp1
>>>>>>> -WEB-INF
>>>>>>> -classes
>>>>>>> -lib
>>>>>>> -www
>>>>>>> -directory1
>>>>>>> -directory2
>>>>>>>
>>>>>>> Is the context path of directory1: /webapp1/directory1
>>>>>>>
>>>>>>> Would I create a context named directory1.xml such as the following?
>>>>>>>
>>>>>>> <?xml version="1.0" encoding="UTF-8"?> <Context
>>>>>>> antiResourceLocking="false" privileged="true"
>>>>>>> path="/webapp1/directory1">
>>>>>>>
>>>>>>> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
>>>>>>> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
>>>>>>> </Context>
>>>>>>>
>>>> Of course you'll still have to map the filter to the correct context
>>>> for directory1 in
>>>>
>>>> webapps
>>>> webapp1
>>>> -WEB-INF
>>>> -classes
>>>> -lib
>>>> -www
>>>> -directory1
>>>> -directory2
>>>>
>>>>
>>>> <filter-mapping>
>>>> <filter-name>Remote Address Filter</filter-name>
>>>> <url-pattern>(??????)</url-pattern>
>>>> </filter-mapping>
>>>>
>>>> and (??????) is .... ?
>>>>
>>>> ;-)
>>>>
>>> Sadly, it's advertised in the help section.
>>>
>>> http://planning.maricopa.gov/sdk/rest/gettingstarted.html scroll to bottom of the page.
>>>
>>> I could surgery out bullet #7 I suppose, but I'm counting on the filter to work.
>>>
>>>
>> Ah well, that is what the user enters, which does not necessarily match the layout of your application.
>> But did I misunderstand, or did you want to have the IP filter apply only to the subdirectory in question ?
>
> Yes, I wanted the IP filter to apply only to http://planning.maricopa.gov/rest/admin
>
> I was confused in thinking that if I used a url-pattern, in a context file, of /rest/admin that it would restrict access to just admin - based on the longest matching prefix - but it restricted access to all of /rest
>
>> My "trick question" was about how you would specify the url-pattern so that it applies only to:
>> (webapps)/webapp1/www/directory1
>> (and not to
>> (webapps)/webapp1/www/directory2 for instance).
>>
You /can/ use the url-pattern in the <filter-mapping> section. If you map it correctly,
the filter will only be active when that sub-directory is the request URL's target.
>
> Using the Container provided Remote Address Filter was a good reason to upgrade to Tomcat 7.0.33 from 6.0.35.
>
> If I can tag another question on the end of this thread:
>
> The Remote Address Filter has an option to set the denyStatus from 403 to 404, or whatever. In general, I'm guessing it's better to respond that a restricted resource is not found, rather than respond that is it there but forbidden?
>
Purely personal opinion : by doing this, you "kind of" violate the spirit of the HTTP
specification, and you create some confusion at the technical level.
And, essentially, you are lying to the client.
So, in general, it is not "better".
But hey, it's your server, so you're free to return whatever you believe is most appropriate.
Within limits though. For example, if somewhere you provide a link to that section for
some people, but when they click on it, they get a "not found", they may think that your
application isn't working, or that your documentation is incorrect. While if they get a
"forbidden", they may realise that they need to ask for a permission.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@ice-sa.com]
>Sent: Friday, November 30, 2012 12:23 AM
>To: Tomcat Users List
>Subject: Re: Context Path for a subdirectory
>>>>>
>>>>> On 11/29/2012 11:41 AM, Leo Donahue - RDSA IT wrote:
>>>>>> Reading the docs:
>>>>>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>>>>>>
>>>>>> "..The web application used to process each HTTP request is
>>>>>> selected by
>>>>> Catalina based on matching the longest possible prefix of the
>>>>> Request URI against the context path of each defined Context."
>>>>>> If I have a webapp, with a www directory, and in that www
>>>>>> directory are
>>>>> other directories, how would I restrict access to one of those
>>>>> subdirectories to the localhost?
>>>>>> webapps
>>>>>> webapp1
>>>>>> -WEB-INF
>>>>>> -classes
>>>>>> -lib
>>>>>> -www
>>>>>> -directory1
>>>>>> -directory2
>>>>>>
>>>>>> Is the context path of directory1: /webapp1/directory1
>>>>>>
>>>>>> Would I create a context named directory1.xml such as the following?
>>>>>>
>>>>>> <?xml version="1.0" encoding="UTF-8"?> <Context
>>>>>> antiResourceLocking="false" privileged="true"
>>>>>> path="/webapp1/directory1">
>>>>>>
>>>>>> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
>>>>>> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
>>>>>> </Context>
>>>>>>
>>>
>>> Of course you'll still have to map the filter to the correct context
>>> for directory1 in
>>>
>>> webapps
>>> webapp1
>>> -WEB-INF
>>> -classes
>>> -lib
>>> -www
>>> -directory1
>>> -directory2
>>>
>>>
>>> <filter-mapping>
>>> <filter-name>Remote Address Filter</filter-name>
>>> <url-pattern>(??????)</url-pattern>
>>> </filter-mapping>
>>>
>>> and (??????) is .... ?
>>>
>>> ;-)
>>>
>>
>> Sadly, it's advertised in the help section.
>>
>> http://planning.maricopa.gov/sdk/rest/gettingstarted.html scroll to bottom of the page.
>>
>> I could surgery out bullet #7 I suppose, but I'm counting on the filter to work.
>>
>>
>Ah well, that is what the user enters, which does not necessarily match the layout of your application.
>But did I misunderstand, or did you want to have the IP filter apply only to the subdirectory in question ?
Yes, I wanted the IP filter to apply only to http://planning.maricopa.gov/rest/admin
I was confused in thinking that if I used a url-pattern, in a context file, of /rest/admin that it would restrict access to just admin - based on the longest matching prefix - but it restricted access to all of /rest
>My "trick question" was about how you would specify the url-pattern so that it applies only to:
>(webapps)/webapp1/www/directory1
>(and not to
>(webapps)/webapp1/www/directory2 for instance).
>
Using the Container provided Remote Address Filter was a good reason to upgrade to Tomcat 7.0.33 from 6.0.35.
If I can tag another question on the end of this thread:
The Remote Address Filter has an option to set the denyStatus from 403 to 404, or whatever. In general, I'm guessing it's better to respond that a restricted resource is not found, rather than respond that is it there but forbidden?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Thursday, November 29, 2012 3:40 PM
>> To: Tomcat Users List
>> Subject: Re: Context Path for a subdirectory
>>
>> Leo Donahue - RDSA IT wrote:
>>>> -----Original Message-----
>>>> From: Mark Eggers [mailto:its_toasted@yahoo.com]
>>>> Sent: Thursday, November 29, 2012 1:12 PM
>>>> To: Tomcat Users List
>>>> Subject: Re: Context Path for a subdirectory
>>>>
>>>> On 11/29/2012 11:41 AM, Leo Donahue - RDSA IT wrote:
>>>>> Reading the docs:
>>>>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>>>>>
>>>>> "..The web application used to process each HTTP request is selected
>>>>> by
>>>> Catalina based on matching the longest possible prefix of the Request
>>>> URI against the context path of each defined Context."
>>>>> If I have a webapp, with a www directory, and in that www directory
>>>>> are
>>>> other directories, how would I restrict access to one of those
>>>> subdirectories to the localhost?
>>>>> webapps
>>>>> webapp1
>>>>> -WEB-INF
>>>>> -classes
>>>>> -lib
>>>>> -www
>>>>> -directory1
>>>>> -directory2
>>>>>
>>>>> Is the context path of directory1: /webapp1/directory1
>>>>>
>>>>> Would I create a context named directory1.xml such as the following?
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8"?> <Context
>>>>> antiResourceLocking="false" privileged="true"
>>>>> path="/webapp1/directory1">
>>>>>
>>>>> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
>>>>> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
>>>>> </Context>
>>>>>
>>>>>
>>>>> Leo
>>>> How about:
>>>>
>>>> http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html
>>>>
>>>> In particular:
>>>>
>>>>
>>>> http://tomcat.apache.org/tomcat-7.0-
>>>> doc/config/filter.html#Remote_Address_Filter
>>>>
>>>>
>>>> Although as has been discussed previously on the mailing list, the
>>>> regular expression is a bit simplistic.
>>>>
>>>> . . . . just my two cents.
>>>> /mde/
>>>>
>>> Thank you Mark.
>>>
>>> I realized the first reply I got might be why not try it, my question, which I
>> did, and of course I had it wrong.
>>> I thought of security-constraint right after I clicked send, but the filter will
>> also work.
>>> http://planning.maricopa.gov/rest - needed to restrict access to one
>> directory of that webapp. It's a third party app, but our data.
>> Of course you'll still have to map the filter to the correct context for directory1
>> in
>>
>> webapps
>> webapp1
>> -WEB-INF
>> -classes
>> -lib
>> -www
>> -directory1
>> -directory2
>>
>>
>> <filter-mapping>
>> <filter-name>Remote Address Filter</filter-name>
>> <url-pattern>(??????)</url-pattern>
>> </filter-mapping>
>>
>> and (??????) is .... ?
>>
>> ;-)
>>
>
> Sadly, it's advertised in the help section.
>
> http://planning.maricopa.gov/sdk/rest/gettingstarted.html scroll to bottom of the page.
>
> I could surgery out bullet #7 I suppose, but I'm counting on the filter to work.
>
Ah well, that is what the user enters, which does not necessarily match the layout of your
application.
But did I misunderstand, or did you want to have the IP filter apply only to the
subdirectory in question ? My "trick question" was about how you would specify the
url-pattern so that it applies only to (webapps)/webapp1/www/directory1 (and not to
(webapps)/webapp1/www/directory2 for instance).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@ice-sa.com]
>Sent: Thursday, November 29, 2012 3:40 PM
>To: Tomcat Users List
>Subject: Re: Context Path for a subdirectory
>
>Leo Donahue - RDSA IT wrote:
>>> -----Original Message-----
>>> From: Mark Eggers [mailto:its_toasted@yahoo.com]
>>> Sent: Thursday, November 29, 2012 1:12 PM
>>> To: Tomcat Users List
>>> Subject: Re: Context Path for a subdirectory
>>>
>>> On 11/29/2012 11:41 AM, Leo Donahue - RDSA IT wrote:
>>>> Reading the docs:
>>>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>>>>
>>>> "..The web application used to process each HTTP request is selected
>>>> by
>>> Catalina based on matching the longest possible prefix of the Request
>>> URI against the context path of each defined Context."
>>>> If I have a webapp, with a www directory, and in that www directory
>>>> are
>>> other directories, how would I restrict access to one of those
>>> subdirectories to the localhost?
>>>> webapps
>>>> webapp1
>>>> -WEB-INF
>>>> -classes
>>>> -lib
>>>> -www
>>>> -directory1
>>>> -directory2
>>>>
>>>> Is the context path of directory1: /webapp1/directory1
>>>>
>>>> Would I create a context named directory1.xml such as the following?
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?> <Context
>>>> antiResourceLocking="false" privileged="true"
>>>> path="/webapp1/directory1">
>>>>
>>>> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
>>>> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
>>>> </Context>
>>>>
>>>>
>>>> Leo
>>> How about:
>>>
>>> http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html
>>>
>>> In particular:
>>>
>>>
>>> http://tomcat.apache.org/tomcat-7.0-
>>> doc/config/filter.html#Remote_Address_Filter
>>>
>>>
>>> Although as has been discussed previously on the mailing list, the
>>> regular expression is a bit simplistic.
>>>
>>> . . . . just my two cents.
>>> /mde/
>>>
>>
>> Thank you Mark.
>>
>> I realized the first reply I got might be why not try it, my question, which I
>did, and of course I had it wrong.
>>
>> I thought of security-constraint right after I clicked send, but the filter will
>also work.
>>
>> http://planning.maricopa.gov/rest - needed to restrict access to one
>directory of that webapp. It's a third party app, but our data.
>>
>
>Of course you'll still have to map the filter to the correct context for directory1
>in
>
>webapps
> webapp1
> -WEB-INF
> -classes
> -lib
> -www
> -directory1
> -directory2
>
>
><filter-mapping>
> <filter-name>Remote Address Filter</filter-name>
> <url-pattern>(??????)</url-pattern>
> </filter-mapping>
>
>and (??????) is .... ?
>
>;-)
>
Sadly, it's advertised in the help section.
http://planning.maricopa.gov/sdk/rest/gettingstarted.html scroll to bottom of the page.
I could surgery out bullet #7 I suppose, but I'm counting on the filter to work.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: Mark Eggers [mailto:its_toasted@yahoo.com]
>> Sent: Thursday, November 29, 2012 1:12 PM
>> To: Tomcat Users List
>> Subject: Re: Context Path for a subdirectory
>>
>> On 11/29/2012 11:41 AM, Leo Donahue - RDSA IT wrote:
>>> Reading the docs:
>>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>>>
>>> "..The web application used to process each HTTP request is selected by
>> Catalina based on matching the longest possible prefix of the Request URI
>> against the context path of each defined Context."
>>> If I have a webapp, with a www directory, and in that www directory are
>> other directories, how would I restrict access to one of those subdirectories to
>> the localhost?
>>> webapps
>>> webapp1
>>> -WEB-INF
>>> -classes
>>> -lib
>>> -www
>>> -directory1
>>> -directory2
>>>
>>> Is the context path of directory1: /webapp1/directory1
>>>
>>> Would I create a context named directory1.xml such as the following?
>>>
>>> <?xml version="1.0" encoding="UTF-8"?> <Context
>>> antiResourceLocking="false" privileged="true"
>>> path="/webapp1/directory1">
>>>
>>> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
>>> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> </Context>
>>>
>>>
>>> Leo
>> How about:
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html
>>
>> In particular:
>>
>>
>> http://tomcat.apache.org/tomcat-7.0-
>> doc/config/filter.html#Remote_Address_Filter
>>
>>
>> Although as has been discussed previously on the mailing list, the
>> regular expression is a bit simplistic.
>>
>> . . . . just my two cents.
>> /mde/
>>
>
> Thank you Mark.
>
> I realized the first reply I got might be why not try it, my question, which I did, and of course I had it wrong.
>
> I thought of security-constraint right after I clicked send, but the filter will also work.
>
> http://planning.maricopa.gov/rest - needed to restrict access to one directory of that webapp. It's a third party app, but our data.
>
Of course you'll still have to map the filter to the correct context for directory1 in
webapps
webapp1
-WEB-INF
-classes
-lib
-www
-directory1
-directory2
<filter-mapping>
<filter-name>Remote Address Filter</filter-name>
<url-pattern>(??????)</url-pattern>
</filter-mapping>
and (??????) is .... ?
;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Mark Eggers [mailto:its_toasted@yahoo.com]
>Sent: Thursday, November 29, 2012 1:12 PM
>To: Tomcat Users List
>Subject: Re: Context Path for a subdirectory
>
>On 11/29/2012 11:41 AM, Leo Donahue - RDSA IT wrote:
>> Reading the docs:
>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>>
>> "..The web application used to process each HTTP request is selected by
>Catalina based on matching the longest possible prefix of the Request URI
>against the context path of each defined Context."
>>
>> If I have a webapp, with a www directory, and in that www directory are
>other directories, how would I restrict access to one of those subdirectories to
>the localhost?
>>
>> webapps
>> webapp1
>> -WEB-INF
>> -classes
>> -lib
>> -www
>> -directory1
>> -directory2
>>
>> Is the context path of directory1: /webapp1/directory1
>>
>> Would I create a context named directory1.xml such as the following?
>>
>> <?xml version="1.0" encoding="UTF-8"?> <Context
>> antiResourceLocking="false" privileged="true"
>> path="/webapp1/directory1">
>>
>> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
>> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> </Context>
>>
>>
>> Leo
>
>How about:
>
>http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html
>
>In particular:
>
>
>http://tomcat.apache.org/tomcat-7.0-
>doc/config/filter.html#Remote_Address_Filter
>
>
>Although as has been discussed previously on the mailing list, the
>regular expression is a bit simplistic.
>
>. . . . just my two cents.
>/mde/
>
Thank you Mark.
I realized the first reply I got might be why not try it, my question, which I did, and of course I had it wrong.
I thought of security-constraint right after I clicked send, but the filter will also work.
http://planning.maricopa.gov/rest - needed to restrict access to one directory of that webapp. It's a third party app, but our data.
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Mark Eggers <it...@yahoo.com>.
On 11/29/2012 11:41 AM, Leo Donahue - RDSA IT wrote:
> Reading the docs: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>
> "..The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context."
>
> If I have a webapp, with a www directory, and in that www directory are other directories, how would I restrict access to one of those subdirectories to the localhost?
>
> webapps
> webapp1
> -WEB-INF
> -classes
> -lib
> -www
> -directory1
> -directory2
>
> Is the context path of directory1: /webapp1/directory1
>
> Would I create a context named directory1.xml such as the following?
>
> <?xml version="1.0" encoding="UTF-8"?>
> <Context antiResourceLocking="false" privileged="true" path="/webapp1/directory1">
>
> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
> </Context>
>
>
> Leo
How about:
http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html
In particular:
http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Remote_Address_Filter
Although as has been discussed previously on the mailing list, the
regular expression is a bit simplistic.
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 12/2/2012 4:54 AM, Konstantin Kolinko wrote:
> 2012/11/30 Terence M. Bandoian <te...@tmbsw.com>:
>> Hi, Chuck-
>>
>> I don't mean to be argumentative but, with Tomcat 6.0.29, I found that
>> static files from an images subdirectory of a web application were not
>> cached by Internet Explorer 7. As a workaround, I created a context for the
>> images subdirectory and left it nested in the web application. The files
>> from that directory were then cached by IE7. The difference was that the
>> following response headers were included when there was no separate context
>> defined for the subdirectory:
>>
>> Pragma: No-cache
>> Cache-Control: no-cache
>> Expires: Wed, 31 Dec 1969 18:00:00 CST
>>
>> Something else I found unusual was that ETag and Last-Modified headers were
>> provided in both configurations. Apparently, some browsers (e.g. Firefox)
>> utilize that information even when the no-cache and Expires headers are
>> provided.
>>
>> I realize this is a non-standard configuration but it worked with 6.0.29 and
>> 6.0.35.
>>
>
> The "no-cache" headers are added to resources that are protected by a
> security constraint. That is for an obvious reason: if a resource is
> cached locally, you cannot protect it.
>
> It is usually a good idea to do not protect such static files.
>
>
> Regarding "a.war/foo/bar" vs "a#foo.war/bar", Tomcat always selects a
> webapp first - one that matches the longest path. Then it selects a
> resource in the selected webapp.
>
> It is mentioned in the Introduction section of the
> "config/context.html" page of the Configuration Reference Guide.
>
> One example of using this rule is ROOT/admin/index.html page in Tomcat 5.5.
>
> When a user requests "http://localhost:8080/admin/" and the admin
> webapp is not installed, the ROOT/admin/index.html page is called and
> says that "no such application is here". If the admin webapp is
> installed, then its welcome page (admin/index.jsp) is displayed.
>
> Best regards,
> Konstantin Kolinko
Hi, Konstantin-
That makes sense. A security constraint was indeed defined for the main
application using the URL pattern "/*". However, no security constraints
were defined for the subdirectory contexts and so the "no-cache" headers
were eliminated.
Thank you for the explanation.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/11/30 Terence M. Bandoian <te...@tmbsw.com>:
> Hi, Chuck-
>
> I don't mean to be argumentative but, with Tomcat 6.0.29, I found that
> static files from an images subdirectory of a web application were not
> cached by Internet Explorer 7. As a workaround, I created a context for the
> images subdirectory and left it nested in the web application. The files
> from that directory were then cached by IE7. The difference was that the
> following response headers were included when there was no separate context
> defined for the subdirectory:
>
> Pragma: No-cache
> Cache-Control: no-cache
> Expires: Wed, 31 Dec 1969 18:00:00 CST
>
> Something else I found unusual was that ETag and Last-Modified headers were
> provided in both configurations. Apparently, some browsers (e.g. Firefox)
> utilize that information even when the no-cache and Expires headers are
> provided.
>
> I realize this is a non-standard configuration but it worked with 6.0.29 and
> 6.0.35.
>
The "no-cache" headers are added to resources that are protected by a
security constraint. That is for an obvious reason: if a resource is
cached locally, you cannot protect it.
It is usually a good idea to do not protect such static files.
Regarding "a.war/foo/bar" vs "a#foo.war/bar", Tomcat always selects a
webapp first - one that matches the longest path. Then it selects a
resource in the selected webapp.
It is mentioned in the Introduction section of the
"config/context.html" page of the Configuration Reference Guide.
One example of using this rule is ROOT/admin/index.html page in Tomcat 5.5.
When a user requests "http://localhost:8080/admin/" and the admin
webapp is not installed, the ROOT/admin/index.html page is called and
says that "no such application is here". If the admin webapp is
installed, then its welcome page (admin/index.jsp) is displayed.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Context Path for a subdirectory
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 11/30/2012 2:00 PM, Caldarale, Charles R wrote:
>> From: Terence M. Bandoian [mailto:terence@tmbsw.com]
>> Subject: Context Path for a subdirectory
>>> A webapp can never be nested inside another, so what you're trying
>>> to do is nonsensical.
>> I don't mean to be argumentative but, with Tomcat 6.0.29, I found that
>> static files from an images subdirectory of a web application were not
>> cached by Internet Explorer 7. As a workaround, I created a context for
>> the images subdirectory and left it nested in the web application. The
>> files from that directory were then cached by IE7. The difference was
>> that the following response headers were included when there was no
>> separate context defined for the subdirectory:
>> Pragma: No-cache
>> Cache-Control: no-cache
>> Expires: Wed, 31 Dec 1969 18:00:00 CST
>> I realize this is a non-standard configuration but it worked with 6.0.29
>> and 6.0.35.
> It may accidentally work in some versions, but it is in no way a supported configuration.
>
> I think the effort would be better spent in figuring out how to control the headers properly rather than inventing something that is known to be contrary to the spec.
>
> - Chuck
Hi, Chuck-
As I mentioned, I realize this is a non-standard configuration. Also,
this was a fairly simple, but probably fairly common, use case:
- single web application
- static files in subdirectories to be delivered by Tomcat (no HTTPD
front end)
I experimented with deploying the subdirectories as separate, un-nested
applications but that only added complexity with no real benefit so I
opted for the simpler solution. Given more time, I might have tracked
down the reason for the no-cache headers - which I did attempt to do -
but this worked reliably. And I'm not sure it's technically contrary to
the spec. It certainly didn't violate anything I read in the Tomcat
configuration reference. In fact, as previously mentioned in another
post, the documentation [1] states:
"The web application used to process each HTTP request is selected by
Catalina based on matching the longest possible prefix of the Request
URI against the context path of each defined Context."
I didn't see any mention of restrictions on the locations of context roots.
-Terence Bandoian
1. http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Introduction
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 12/3/12 6:50 PM, André Warnier wrote:
> P.S. If you decide to use UrlRewriteFilter, you should be looking
> at the documentation
> (http://urlrewritefilter.googlecode.com/svn/trunk/src/doc/manual/4.0/index.html),
Cool,
>
there's a 4.0 version. And it supports mod_rewrite syntax? Very
cool.
> and at a rule using this in the <from> part :
>
> remote-addr : The IP address of the host making the request, e.g.
> 123.123.123.12 i.e. request.getRemoteAddr() (you probably want to
> negate this, and check for "not (127.0.0.1 or ::1)")
>
> and probably this in the <to> part : forward (default) :
>
> Requests matching the "conditions" for this "rule", and the URL in
> the "from" element will be internally forwarded to the URL
> specified in the "to" element. Note: In this case the "to" URL must
> be in the same context as UrlRewriteFilter. This is the same as
> doing: RequestDispatcher rq = request.getRequestDispatcher([to
> value]); rq.forward(request, response); (to forward the miscreants
> to a no-no page of your choice.)
If you haven't used url-rewrite before, it may seem a bit daunting.
Here's an example to get you started:
<rule>
<condition type="remote-addr" operator="notequal">127.0.0.1</condition>
<set type="status">403</set>
<to last="true">/forbidden.html</to>
</rule>
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC+MfcACgkQ9CaO5/Lv0PAMpQCcDD7oMUAzuTe1xKeuMpm665SR
FjIAn0jE67iGpGMDH9HqjqXFBoa4JFdp
=FdT5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
> _______________________________________
> From: Christopher Schultz [chris@christopherschultz.net]
> Sent: Friday, November 30, 2012 8:13 PM
> To: Tomcat Users List
> Subject: Re: Context Path for a subdirectory
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Leo,
>
> On 11/30/12 5:52 PM, Leo Donahue - RDSA IT wrote:
>> Ok, so before I upgraded to Tomcat 7.0.33 to use the container
>> supplied remote address filter, what were my options to restrict
>> access to just a subdirectory of a web app in Tomcat 6.0.35?
>
> Please remember that you aren't protecting a directory. Ever. You are
> protecting a url-pattern and nothing more.
> - -chris
>
> 1st, sorry for the format, I'm on vacation and webmail doesn't format replies the way I'd like.
> (sorry chuck, not taking your advice from before on getting out more. maybe tomorrow...)
>
> I have heard this before, and now I'm beginning to understand why I keep hearing this same comment. I now realize my choice of words in describing what I was trying to do leads to this comment.
>
> As many times as I've heard, "you're not protecting a directory, and some other people use the phrase 'resource'..." I always thought that there was some trick to getting by the url-pattern that no one wanted to mention.
>
> As far as the URL vs directory, the server is pretty locked down - so I'm told, and the IP I use is the IP of the host.
>
> Ultimately I wanted to restrict access to the URL /rest/admin to requests made by the local host only to that URL.
>
> webapps
> rest
> www
> admin
>
Ok, so the way I would go about it, taking into acount my limited knowledge about webapp'
"security constraints" and the like, but having written at least one servlet filter before :
1) your webapp is the "rest" webapp
2) inside that webapp, the url category which you want to protect against accesses by
other client IP's than "localhost" is : "/www/admin" and "/www/admin/*".
(The "/rest" part falls off, because you are already inside of it).
3) you can for that write your own servlet filter, or use an existing one : see
http://www.tuckey.org/urlrewrite/
4) the basic plan is to insert a servlet filter into your "webapp stack", which filter
will only be active (inserted in the request processing chain) when a URL of the type in
item (2) above is involved; and it will not be activated and play no role in other cases
(e.g. for URL paths outside of /rest/www/admin) (*)
5) you configure this in the web.xml of your webapp (../webapps/rest/WEB-INF/web.xml)
exactly as shown on the webpage indicated above, except for
<filter-mapping>
...
<url-pattern>/www/admin<url-pattern>
<url-pattern>/www/admin/*<url-pattern>
...
</filter-mapping>
(*)
The UrlRewriteFilter is probably a bit "heavy-duty" for the simple filtering which you
want. But at the same time, it is well-written, well-tested, optimised, and you will
probably benefit from knowing it, as it can do *much* more than what you need here.
Writing your own filter is not very difficult, but if you have not done it before there
are some particular aspects that need a bit of getting used to (such as for instance that
the request object is immutable, and thus to modify the request - which you do not need
here - you need to "wrap" it into your own version of it, and modify that one).
This being said, it's fun.
(*) I mean that it is the container that does the inserting or not of the filter,
depending on these <url-pattern> lines, you do not have to take care of that.
Inside of your filter code, you just filter every request you get our hands on,since you
know that your code is only called when the request URL matches.
And sorry if you knew all that already. It just did not sound that you were too sure.
P.S. If you decide to use UrlRewriteFilter, you should be looking at the documentation
(http://urlrewritefilter.googlecode.com/svn/trunk/src/doc/manual/4.0/index.html), and at
a rule using this in the <from> part :
remote-addr :
The IP address of the host making the request, e.g. 123.123.123.12
i.e. request.getRemoteAddr()
(you probably want to negate this, and check for "not (127.0.0.1 or ::1)")
and probably this in the <to> part :
forward (default) :
Requests matching the "conditions" for this "rule", and the URL in the "from" element
will be internally forwarded to the URL specified in the "to" element. Note: In this case
the "to" URL must be in the same context as UrlRewriteFilter. This is the same as doing:
RequestDispatcher rq = request.getRequestDispatcher([to value]);
rq.forward(request, response);
(to forward the miscreants to a no-no page of your choice.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
_______________________________________
From: Christopher Schultz [chris@christopherschultz.net]
Sent: Friday, November 30, 2012 8:13 PM
To: Tomcat Users List
Subject: Re: Context Path for a subdirectory
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 11/30/12 5:52 PM, Leo Donahue - RDSA IT wrote:
> Ok, so before I upgraded to Tomcat 7.0.33 to use the container
> supplied remote address filter, what were my options to restrict
> access to just a subdirectory of a web app in Tomcat 6.0.35?
Please remember that you aren't protecting a directory. Ever. You are
protecting a url-pattern and nothing more.
- -chris
1st, sorry for the format, I'm on vacation and webmail doesn't format replies the way I'd like.
(sorry chuck, not taking your advice from before on getting out more. maybe tomorrow...)
I have heard this before, and now I'm beginning to understand why I keep hearing this same comment. I now realize my choice of words in describing what I was trying to do leads to this comment.
As many times as I've heard, "you're not protecting a directory, and some other people use the phrase 'resource'..." I always thought that there was some trick to getting by the url-pattern that no one wanted to mention.
As far as the URL vs directory, the server is pretty locked down - so I'm told, and the IP I use is the IP of the host.
Ultimately I wanted to restrict access to the URL /rest/admin to requests made by the local host only to that URL.
webapps
rest
www
admin
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 11/30/12 5:52 PM, Leo Donahue - RDSA IT wrote:
> Ok, so before I upgraded to Tomcat 7.0.33 to use the container
> supplied remote address filter, what were my options to restrict
> access to just a subdirectory of a web app in Tomcat 6.0.35?
<security-constraint> on a <web-resource-collection> with whatever
<url-pattern> you want. In web.xml. As Chuck says, restricting by IP
address requires that you step outside of the spec-compliant stuff and
either write your own Valve (counterproductive IMO), use url-rewrite
(our favorite 3rd-party tool), or write your own filter.
Please remember that you aren't protecting a directory. Ever. You are
protecting a url-pattern and nothing more. While Apache httpd allows
you to protect directories such that multiple URLs mapping to that
directory are always protected, there is no such analog in the Tomcat
world: you will always have to protect based upon URL patterns.
> I'll admit, contexts are confusing to me.
A context is a thing which has been deployed as a web application.
It's got its own web.xml (even if it doesn't actually have one: it
will get a default one), ClassLoader, etc.
> You can create contexts in conf\Catalina\localhost that map to
> places that are not even in the webapps folder, but expose
> themselves as a URL to the end user.
They don't even have to be backed by the filesystem, really. If Tomcat
allowed you to deploy WARs from a database, there really is no
filesystem at all.
A file in conf/Catalina/localhost can define a context. By default,
any .war file or directory in Tomcat's webapps/ directory will be
auto-deployed as a context as well. If you want to, you can even put a
directory in webapps/ and also create an alias to it using a file in
conf/Catalina/localhost, but it's generally not recommended because a)
that's not usually what you want to do and b) it's confusing as hell.
> My thought was if I could create a context that mapped to a
> subdirectory, I could create a valve that restricted access to
> that URL.
There is no reason for the second context: if you have the Valve, you
can restrict it by url-pattern in the one-and-only webapp and not have
to artificially create another webapp just for that purpose.
> What is the right way to do this in Tomcat 6.0.35?
If you need IP-based authorization in Tomcat 6.0.35, I'd go for
url-rewrite. Just map /path/to/protect/* to url-rewrite and set up a
rule that says "ip != your.special.ip" -> 403.html (or whatever).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5dcEACgkQ9CaO5/Lv0PCxngCggWcf01I3VYYHBAVfJWtszzxZ
smIAn1NBWnFodCHDAVZnpNTyxwJSAbgP
=pu3c
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 11/30/12 7:07 PM, Leo Donahue - RDSA IT wrote:
>> -----Original Message----- From: Leo Donahue - RDSA IT
>> [mailto:LeoDonahue@mail.maricopa.gov] Sent: Friday, November 30,
>> 2012 5:02 PM To: Tomcat Users List Subject: RE: Context Path for
>> a subdirectory
>>
>>
>> The way the Server 1 is configured, there are accounts that the
>> rest/admin web app will take which let you do things like
>> shutdown the services and other stuff, if you were able to brute
>> force the rest/admin username/password.
>>
>
> That would only do you any good if you knew the internal server
> name. But I have to protect from internal threats as well, right?
Now, you're thinking properly ;)
Just remember that you asked to be able to restrict by IP address.
Well, an internal threat might be able to come from that IP address,
so you might want credentials that can be relatively quickly revoked.
I suppose you could change the IP whitelist, but then maybe you'll
have to figure out what the new blessed IP will be...
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5eTQACgkQ9CaO5/Lv0PB6PwCdHxGgWyhTjvxfq/sUuelnXI2I
2CUAn2XccinoszoRrw6H52zgZj73WyB3
=XjhS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>Sent: Friday, November 30, 2012 5:02 PM
>To: Tomcat Users List
>Subject: RE: Context Path for a subdirectory
>
>
>The way the Server 1 is configured, there are accounts that the rest/admin
>web app will take which let you do things like shutdown the services and
>other stuff, if you were able to brute force the rest/admin
>username/password.
>
That would only do you any good if you knew the internal server name. But I have to protect from internal threats as well, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 11/30/12 7:02 PM, Leo Donahue - RDSA IT wrote:
> Any changes that I make to the rest web app are done on Server 1,
> in which I then need to generate a new rest.war file to be deployed
> on Server 4. Anything custom that I configure for the rest webapp,
> like the filter in web.xml, I have to remember to unpack the war
> file, make edits and re-pack it, or leave it exploded.
I highly recommend that you script this. Apache ant is great for this
stuff. It's got tasks for unwarring WAR files, re-warring WAR files,
performing XSLT transformations, string-replacements, merging
directories together into archives (like WARs), etc.
It's quite easy to do this kind of stuff.
For instance, we have a Cocoon-based webapp that unpacks a pre-built
Cocoon WAR file, compiles some custom Cocoon-based components against
it, re-wires the XML-based configurations using XSLT, then re-builds
the WAR file so it's ready for deployment. Nothing to "remember"
except pushing the button.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5eLEACgkQ9CaO5/Lv0PDIhgCgp3iiao79N9fQPgE9IAqLEFvt
1RQAnA8Al9G1NJcEXBkajijEtoIxI1cX
=GQwZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@ice-sa.com]
>Sent: Friday, November 30, 2012 4:45 PM
>To: Tomcat Users List
>Subject: Re: Context Path for a subdirectory
>
>Maybe a bit of lateral thinking here.
>What does the admin webapp really do ? For what it is doing, does it need to
>even "live"
>in the same website/host as the main application ?
>If it's actions are confined to managing some files on disk, or some data in a
>back-end database, maybe it can do that without being really integrated into
>your main application ?
>You could then set up a separate Host, running under SSL or whatever, to run
>this admin part. It's URL would never be visible under your main site. And
>you'd have all the flexibility to set up any security constraints you want,
>without interfering with the main user site.
>
Fair question.
The "rest" web app was configured using a product called ArcGIS Server. There are at least 4 servers involved in the end product you see.
Server 1 - The ArcGIS Server - This is where you publish map documents as web services, and where you can export the "web services handler" (rest.war) to a production web server. Which I've done.
Server 2 - The ArcSDE Server - This is where the GIS data physically resides in a SQL Server.
Server 3 - The GIS Storage server - This is where Server 1 writes out the map images you see. I have a context on Server 4 that maps to a share on Server 3 as a virtual output directory.
Server 4 - The production Tomcat server - This is where I deploy the rest web app that is created from Server 1
Any changes that I make to the rest web app are done on Server 1, in which I then need to generate a new rest.war file to be deployed on Server 4. Anything custom that I configure for the rest webapp, like the filter in web.xml, I have to remember to unpack the war file, make edits and re-pack it, or leave it exploded. Changes can be things like adding new output directories, map cache directories, adding features like the ability to generate KMZ files for Google Earth, and there is even an option to configure deploying the rest.war file with a security store.
The rest/admin web app has one thing that I need, which is a clear cache feature. Any new web services that you deploy, or changes you make to existing services such as changing the color of a feature or what not, have to have the cache cleared.
The way the Server 1 is configured, there are accounts that the rest/admin web app will take which let you do things like shutdown the services and other stuff, if you were able to brute force the rest/admin username/password.
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
>> Sent: Friday, November 30, 2012 4:04 PM
>> To: Tomcat Users List
>> Subject: RE: Context Path for a subdirectory
>>
>>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>>> Subject: RE: Context Path for a subdirectory
>>> what were my options to restrict access to just a subdirectory of a
>>> web app in Tomcat 6.0.35?
>> Using just spec-provided mechanisms, such access can be limited to specific
>> users by including the appropriate security constraint elements in the
>> webapp's WEB-INF/web.xml. The wrinkle you want is to limit by IP address,
>> which is not a capability the servlet spec covers.
>>
>>> I'll admit, contexts are confusing to me.
>> The main thing to remember is that each webapp (context) is expected to be
>> physically separate from all other webapps. (This has nothing to do with the
>> URLs used to access the webapps, just the location of the webapps in the
>> server's file system, database, memory, paper tape, or whatever medium
>> they're stored on.)
>>
>>> What is the right way to do this in Tomcat 6.0.35?
>> Probably the easiest is just to pick up the filter from Tomcat 7 and use it in 6.
>> The SecurityFilter from sourceforge might be able to do it, but I'm not sure
>> (Chris should know).
>>
>> - Chuck
>>
>
> I considered the security constraint, but wouldn't that have required me to set up SSL (for a secure user/password submittal) and get someone to pay for a public certificate - which would probably not happen. Sure, I could generate a cert myself. But I would still have to convince our office of enterprise tech that leaving an admin related webapp visible to the public is ok (authentication enabled or not). The last admin related webapp on our site had to be restricted by a valve, but that was for the whole context.
>
> The software company that we use also provides these kinds of web services to the whole world. They don't even bother restricting their /rest/admin directory, which really surprises me. Maybe I'm being paranoid by trying to one up them.
>
...
Maybe a bit of lateral thinking here.
What does the admin webapp really do ? For what it is doing, does it need to even "live"
in the same website/host as the main application ?
If it's actions are confined to managing some files on disk, or some data in a back-end
database, maybe it can do that without being really integrated into your main application ?
You could then set up a separate Host, running under SSL or whatever, to run this admin
part. It's URL would never be visible under your main site. And you'd have all the
flexibility to set up any security constraints you want, without interfering with the main
user site.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
> Subject: RE: Context Path for a subdirectory
> I considered the security constraint, but wouldn't that have required me
> to set up SSL (for a secure user/password submittal) and get someone to
> pay for a public certificate - which would probably not happen.
No, SSL is not required (that's called transport guarantee in the spec). However, not using it means that the credentials could be sniffed by anyone with access to the wire.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
>Sent: Friday, November 30, 2012 4:04 PM
>To: Tomcat Users List
>Subject: RE: Context Path for a subdirectory
>
>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>> Subject: RE: Context Path for a subdirectory
>
>> what were my options to restrict access to just a subdirectory of a
>> web app in Tomcat 6.0.35?
>
>Using just spec-provided mechanisms, such access can be limited to specific
>users by including the appropriate security constraint elements in the
>webapp's WEB-INF/web.xml. The wrinkle you want is to limit by IP address,
>which is not a capability the servlet spec covers.
>
>> I'll admit, contexts are confusing to me.
>
>The main thing to remember is that each webapp (context) is expected to be
>physically separate from all other webapps. (This has nothing to do with the
>URLs used to access the webapps, just the location of the webapps in the
>server's file system, database, memory, paper tape, or whatever medium
>they're stored on.)
>
>> What is the right way to do this in Tomcat 6.0.35?
>
>Probably the easiest is just to pick up the filter from Tomcat 7 and use it in 6.
>The SecurityFilter from sourceforge might be able to do it, but I'm not sure
>(Chris should know).
>
> - Chuck
>
I considered the security constraint, but wouldn't that have required me to set up SSL (for a secure user/password submittal) and get someone to pay for a public certificate - which would probably not happen. Sure, I could generate a cert myself. But I would still have to convince our office of enterprise tech that leaving an admin related webapp visible to the public is ok (authentication enabled or not). The last admin related webapp on our site had to be restricted by a valve, but that was for the whole context.
The software company that we use also provides these kinds of web services to the whole world. They don't even bother restricting their /rest/admin directory, which really surprises me. Maybe I'm being paranoid by trying to one up them.
http://services.arcgisonline.com/ArcGIS/rest/services
http://services.arcgisonline.com/ArcGIS/rest/admin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 11/30/12 6:04 PM, Caldarale, Charles R wrote:
> The SecurityFilter from sourceforge might be able to do it, but I'm
> not sure (Chris should know).
Nope, sf doesn't have IP filtering built into it.
In my private copy, it's got the ability to restrict a session to a
specific IP, but I never bothered committing that to the repo because
it seemed so trivial.
Plus, another release of sf in its current form is seriously unlikely.
I think what I might end up doing is changing the project to "security
filters" and just package a few very useful tools that can be used
together. Either that or change the project page to redirect to Spring
Security.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5d40ACgkQ9CaO5/Lv0PBtkQCfYwUhJudfAIBm6eIX9Dv+kb8l
yvkAn22BSFNvrHBxF9/AuQJaQ4K83/bN
=NqPw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
> Subject: RE: Context Path for a subdirectory
> what were my options to restrict access to just a subdirectory of a
> web app in Tomcat 6.0.35?
Using just spec-provided mechanisms, such access can be limited to specific users by including the appropriate security constraint elements in the webapp's WEB-INF/web.xml. The wrinkle you want is to limit by IP address, which is not a capability the servlet spec covers.
> I'll admit, contexts are confusing to me.
The main thing to remember is that each webapp (context) is expected to be physically separate from all other webapps. (This has nothing to do with the URLs used to access the webapps, just the location of the webapps in the server's file system, database, memory, paper tape, or whatever medium they're stored on.)
> What is the right way to do this in Tomcat 6.0.35?
Probably the easiest is just to pick up the filter from Tomcat 7 and use it in 6. The SecurityFilter from sourceforge might be able to do it, but I'm not sure (Chris should know).
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Christopher Schultz [mailto:chris@christopherschultz.net]
>Sent: Friday, November 30, 2012 3:39 PM
>To: Tomcat Users List
>Subject: Re: Context Path for a subdirectory
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Chuck,
>
>On 11/30/12 5:25 PM, Caldarale, Charles R wrote:
>>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>>> Subject: Re: Context Path for a subdirectory
>>
>>> I don't think it's specifically /un/supported.
>>
>>> For instance, Tomcat should happily deploy both of these files:
>>
>>> myapp.war myapp#static.war
>>
>> That's not what's being discussed. You're describing logically nested
>> paths, which is fully supported; the topic under discussion is
>> physical (file system) nesting of one webapp inside another.
>
>There's definitely come nomenclature confusion going-on in this thread. For
>example:
>
>> On 11/29/12 3:14 PM, Calderale, Charles R wrote:
>>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>>> Subject: Context Path for a subdirectory
>>
>>> If I have a webapp, with a www directory, and in that www directory
>>> are other directories, how would I restrict access to one of those
>>> subdirectories to the localhost?
>>>
>>> [...]
>>>
>>> Is the context path of directory1: /webapp1/directory1
>>
>> No, it's /webapp1/www/directory1.
>
>The context path for the webapp is "/webapp1", not
>"/webapp1/www/directory1".
>
>As you say, you can't just cause a new webapp context to spring-forth from
>another by adding a context.xml file to it. Explicitly deploying a subdirectory of
>an existing webapp using
>CATALINA_BASE/conf/Catalina/localhost/webapp#www#directory1.xml with
>path=${catalina.base}/webapps/webapp1/www/directory1" would probably
>work, but it is, of course, totally stupid to do things that way.
>
>I think OP was just trying to treat a subdirectory as a distinct webapp because
>(maybe?) that seemed like an easier way to restrict access. I can imagine this
>being conflated with, say, Apache httpd's ability to specify authentication
>requirements by dropping an .htaccess file into a directory. Obviously that's
>not how Tomcat does things.
>
>I think this is yet another instance of someone not understanding that a
>"webapp" is more than just set of files and subdirectories rooted somewhere
>on the filesystem. Honestly, Leo should know better after all the time he's
>been hanging around the list ;)
>
>- -chris
Dang it.
Ok, so before I upgraded to Tomcat 7.0.33 to use the container supplied remote address filter, what were my options to restrict access to just a subdirectory of a web app in Tomcat 6.0.35?
I'll admit, contexts are confusing to me. You can create contexts in conf\Catalina\localhost that map to places that are not even in the webapps folder, but expose themselves as a URL to the end user. My thought was if I could create a context that mapped to a subdirectory, I could create a valve that restricted access to that URL.
What is the right way to do this in Tomcat 6.0.35?
Re: Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 11/30/12 5:25 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Subject: Re: Context Path for a subdirectory
>
>> I don't think it's specifically /un/supported.
>
>> For instance, Tomcat should happily deploy both of these files:
>
>> myapp.war myapp#static.war
>
> That's not what's being discussed. You're describing logically
> nested paths, which is fully supported; the topic under discussion
> is physical (file system) nesting of one webapp inside another.
There's definitely come nomenclature confusion going-on in this
thread. For example:
> On 11/29/12 3:14 PM, Calderale, Charles R wrote:
>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>> Subject: Context Path for a subdirectory
>
>> If I have a webapp, with a www directory, and in that www
>> directory are other directories, how would I restrict access to
>> one of those subdirectories to the localhost?
>>
>> [...]
>>
>> Is the context path of directory1: /webapp1/directory1
>
> No, it's /webapp1/www/directory1.
The context path for the webapp is "/webapp1", not
"/webapp1/www/directory1".
As you say, you can't just cause a new webapp context to spring-forth
from another by adding a context.xml file to it. Explicitly deploying
a subdirectory of an existing webapp using
CATALINA_BASE/conf/Catalina/localhost/webapp#www#directory1.xml with
path=${catalina.base}/webapps/webapp1/www/directory1" would probably
work, but it is, of course, totally stupid to do things that way.
I think OP was just trying to treat a subdirectory as a distinct
webapp because (maybe?) that seemed like an easier way to restrict
access. I can imagine this being conflated with, say, Apache httpd's
ability to specify authentication requirements by dropping an
.htaccess file into a directory. Obviously that's not how Tomcat does
things.
I think this is yet another instance of someone not understanding that
a "webapp" is more than just set of files and subdirectories rooted
somewhere on the filesystem. Honestly, Leo should know better after
all the time he's been hanging around the list ;)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5NZwACgkQ9CaO5/Lv0PDiOQCglkzqFfgOm7uqL68gYTnJRaPO
IogAoLKe9kfUs3AWTGS9JBIhtw0ssvUP
=F4cH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: Context Path for a subdirectory
> I don't think it's specifically /un/supported.
> For instance, Tomcat should happily deploy both of these files:
> myapp.war
> myapp#static.war
That's not what's being discussed. You're describing logically nested paths, which is fully supported; the topic under discussion is physical (file system) nesting of one webapp inside another.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 11/30/12 3:00 PM, Caldarale, Charles R wrote:
>> From: Terence M. Bandoian [mailto:terence@tmbsw.com] Subject:
>> Context Path for a subdirectory
>
>>> A webapp can never be nested inside another, so what you're
>>> trying to do is nonsensical.
>
>> I don't mean to be argumentative but, with Tomcat 6.0.29, I found
>> that static files from an images subdirectory of a web
>> application were not cached by Internet Explorer 7. As a
>> workaround, I created a context for the images subdirectory and
>> left it nested in the web application. The files from that
>> directory were then cached by IE7. The difference was that the
>> following response headers were included when there was no
>> separate context defined for the subdirectory:
>
>> Pragma: No-cache Cache-Control: no-cache Expires: Wed, 31 Dec
>> 1969 18:00:00 CST
>
>> I realize this is a non-standard configuration but it worked with
>> 6.0.29 and 6.0.35.
>
> It may accidentally work in some versions, but it is in no way a
> supported configuration.
I don't think it's specifically /un/supported.
For instance, Tomcat should happily deploy both of these files:
myapp.war
myapp#static.war
Requests to /myapp/static/... will be directed to the "inner" context
while those that match /myapp/* but not /myapp/static/* will be
directed to the "outer" one. I was actually waiting for someone to
point out to the OP that the Tomcat documentation originally
referenced was talking about context-name-matching (to choose a
context) and not matching a servlet directly from the URI.
The (subtle) point is that Tomcat first has to decide which context
should handle the request, and the entire URI need not be used for
that: only the context-path portion of that, which is typically the
string before the second '/' in the URL (like 'foo' for
http://www.example.com/foo/). The documentation states that the
decision is made based upon longest-match at the /context/ level, not
at the servlet level (though longest-match is also done at the servlet
level once the context has been chosen).
Thus, I believe Tomcat technically fully-supportd "nested" contexts.
Note that there are many dragons lurking in this area. Notable ones
include overlapping URI-spaces for session ids. If you need sessions
in both webapps, you (and your code) are eventually going to get confused.
> I think the effort would be better spent in figuring out how to
> control the headers properly rather than inventing something that
> is known to be contrary to the spec.
I wouldn't say that this is contrary to the spec. Just not ....
well-tested.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5LbEACgkQ9CaO5/Lv0PASQACgigIn6sKQBQty4ohANPvPoxQf
/IEAn3U/5UO81KG/qHFutEQn93fjE/xj
=Wjuf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Terence M. Bandoian [mailto:terence@tmbsw.com]
> Subject: Context Path for a subdirectory
> > A webapp can never be nested inside another, so what you're trying
> > to do is nonsensical.
> I don't mean to be argumentative but, with Tomcat 6.0.29, I found that
> static files from an images subdirectory of a web application were not
> cached by Internet Explorer 7. As a workaround, I created a context for
> the images subdirectory and left it nested in the web application. The
> files from that directory were then cached by IE7. The difference was
> that the following response headers were included when there was no
> separate context defined for the subdirectory:
> Pragma: No-cache
> Cache-Control: no-cache
> Expires: Wed, 31 Dec 1969 18:00:00 CST
> I realize this is a non-standard configuration but it worked with 6.0.29
> and 6.0.35.
It may accidentally work in some versions, but it is in no way a supported configuration.
I think the effort would be better spent in figuring out how to control the headers properly rather than inventing something that is known to be contrary to the spec.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Context Path for a subdirectory
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 11/29/2012 2:14 PM, Caldarale, Charles R wrote:
>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>> Subject: Context Path for a subdirectory
>> If I have a webapp, with a www directory, and in that www directory
>> are other directories, how would I restrict access to one of those
>> subdirectories to the localhost?
> Probably your best bet is to use a filter for the webapp to which those subdirectories belong.
>
>> Is the context path of directory1: /webapp1/directory1
> No, it's /webapp1/www/directory1.
>
>> Would I create a context named directory1.xml such as the following?
> Absolutely not. A webapp can never be nested inside another, so what you're trying to do is nonsensical.
>
> - Chuck
Hi, Chuck-
I don't mean to be argumentative but, with Tomcat 6.0.29, I found that
static files from an images subdirectory of a web application were not
cached by Internet Explorer 7. As a workaround, I created a context for
the images subdirectory and left it nested in the web application. The
files from that directory were then cached by IE7. The difference was
that the following response headers were included when there was no
separate context defined for the subdirectory:
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 18:00:00 CST
Something else I found unusual was that ETag and Last-Modified headers
were provided in both configurations. Apparently, some browsers (e.g.
Firefox) utilize that information even when the no-cache and Expires
headers are provided.
I realize this is a non-standard configuration but it worked with 6.0.29
and 6.0.35.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
> Subject: Context Path for a subdirectory
> If I have a webapp, with a www directory, and in that www directory
> are other directories, how would I restrict access to one of those
> subdirectories to the localhost?
Probably your best bet is to use a filter for the webapp to which those subdirectories belong.
> Is the context path of directory1: /webapp1/directory1
No, it's /webapp1/www/directory1.
> Would I create a context named directory1.xml such as the following?
Absolutely not. A webapp can never be nested inside another, so what you're trying to do is nonsensical.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/11/29 Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>:
> Reading the docs: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
>
> "..The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context."
>
> (...)
>
> Would I create a context named directory1.xml such as the following?
>
> <?xml version="1.0" encoding="UTF-8"?>
> <Context antiResourceLocking="false" privileged="true" path="/webapp1/directory1">
1. The path attribute is invalid here. The file name of the xml file
will be used as the path.
E.g. naming the file "webapp1#www#directory1.xml" and moving those
files into directory named /webapps/webapp1#www#directory1 is a way
to deploy such application. Isn't it in the FAQ?
Anyway I think it would be easier for you to configure a
RemoteAddrFilter, as others suggested.
2. Unless you know what "privileged" is, do not use it.
> <Valve className="org.apache.catalina.valves.RemoteAddrValve"
> allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
> </Context>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org