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/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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to