tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Context Path for a subdirectory
Date Fri, 30 Nov 2012 15:20:07 GMT
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: André Warnier []
>> 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:
>>>>>>> "..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.
>>>  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
> 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:
For additional commands, e-mail:

View raw message