Re: Context Path for a subdirectory
-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=notequal127.0.0.1/condition set type=status403/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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
On 12/2/2012 4:54 AM, Konstantin Kolinko wrote: 2012/11/30 Terence M. Bandoian tere...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
___ From: Christopher Schultz [ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
Leo Donahue - RDSA IT wrote: ___ From: Christopher Schultz [ch...@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/adminurl-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
2012/11/30 Terence M. Bandoian tere...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message- From: André Warnier [mailto:a...@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-nameRemote 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
Leo Donahue - RDSA IT wrote: -Original Message- From: André Warnier [mailto:a...@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-nameRemote 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message- From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
From: Leo Donahue - RDSA IT [mailto:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@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:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
From: Terence M. Bandoian [mailto:tere...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
Leo Donahue - RDSA IT wrote: -Original Message- From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 11/30/12 3:00 PM, Caldarale, Charles R wrote: From: Terence M. Bandoian [mailto:tere...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
From: Christopher Schultz [mailto:ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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:ch...@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:leodona...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message-
From: Christopher Schultz [mailto:ch...@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:ch...@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:leodona...@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
From: Leo Donahue - RDSA IT [mailto:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@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:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
Leo Donahue - RDSA IT wrote: -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@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:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message- From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message- From: Leo Donahue - RDSA IT [mailto:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
From: Leo Donahue - RDSA IT [mailto:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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? 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
-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:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
From: Leo Donahue - RDSA IT [mailto:leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message- From: Mark Eggers [mailto:its_toas...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
On 11/29/2012 12:32 PM, Leo Donahue - RDSA IT wrote: -Original Message- From: Mark Eggers [mailto:its_toas...@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-constraint127.0.0.1/ip-constraint ip-constraint192.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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
2012/11/29 Leo Donahue - RDSA IT leodona...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
Leo Donahue - RDSA IT wrote: -Original Message- From: Mark Eggers [mailto:its_toas...@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-nameRemote Address Filter/filter-name url-pattern(??)/url-pattern /filter-mapping and (??) is ? ;-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context Path for a subdirectory
-Original Message- From: André Warnier [mailto:a...@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_toas...@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-nameRemote 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context Path for a subdirectory
Leo Donahue - RDSA IT wrote: -Original Message- From: André Warnier [mailto:a...@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_toas...@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-nameRemote 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
