You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mario Winterer <ma...@eduhi.at> on 2005/02/03 01:54:19 UTC
Hiding resources
Hi!
I'm running a web application that is under CVS, which means my web
application contains a lot of CVS-related directories (for the
CVS-metadata).
Is there a possibility to tell Tomcat to hide or protect all those "CVS"
directories? More general, what I need is a way to hide/protect all
files or directories with the name pattern "*/CVS/*".
As far as I know, neither a servlet/filter-mapping nor a security
constraint support this type of pattern (with two wildcards).
So I think, the only way to protect my resources is to implement a
custom filter that is mapped against "/" and checks every incoming request.
Is there a better approach?
Best regards,
Tex
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Hiding resources
Posted by Nikola Milutinovic <Ni...@ev.co.yu>.
Mario Winterer wrote:
> Hi!
>
> I'm running a web application that is under CVS, which means my web
> application contains a lot of CVS-related directories (for the
> CVS-metadata).
> Is there a possibility to tell Tomcat to hide or protect all those
> "CVS" directories? More general, what I need is a way to hide/protect
> all files or directories with the name pattern "*/CVS/*".
> As far as I know, neither a servlet/filter-mapping nor a security
> constraint support this type of pattern (with two wildcards).
> So I think, the only way to protect my resources is to implement a
> custom filter that is mapped against "/" and checks every incoming
> request.
>
> Is there a better approach?
Yes, there is. Use some build tool for your operations, like "Apache
Ant". Ant can pull neccessary files from the CVS, copy them to the
staging area, package WAR and deploy it to Tomcat. All nice and clean.
Nix.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Hiding resources
Posted by Tim Funk <fu...@joedog.org>.
getRequestURI() will return the encoded item but getServletPath() will have
the decoded path for you (without contextPath - but in this case - you won't
care about that)
-Tim
Mario Winterer wrote:
> Thanks David,
>
> I think, your second suggestion will not work, because it is not
> possible to map a servlet or filter to "*/CVS/*". According to the
> servlet-specs, only filters of the form "anything/*" or "*.extension"
> are supported (and I really do not want to add a servlet-mapping for
> every single CVS directory).
> I've already thought on a filter using regular expressions for filtering
> out certain requests. But I'm not sure if this is secure enough. Just
> think of "modified" request-urls using hex numbers for escaping ascii
> characters (e.g. ".../%43VS/..." instead of ".../CVS/..."). Are those
> urls normalized by tomcat, i.e. does request.getRequestURL() return
> ".../CVS/..." in both cases?
>
> Tex
>
>> Just a thought or two --
>>
>> 1) Setup a request filter that detects when the URL contains the
>> pattern CVS/ and redirects to a default or error page.
>> -or-
>> 2) Setup a servlet mapping for any of the potential CVS URLs and have
>> them map to a servlet that responds with an error or redirect.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Hiding resources
Posted by Mario Winterer <ma...@eduhi.at>.
Thanks David,
I think, your second suggestion will not work, because it is not
possible to map a servlet or filter to "*/CVS/*". According to the
servlet-specs, only filters of the form "anything/*" or "*.extension"
are supported (and I really do not want to add a servlet-mapping for
every single CVS directory).
I've already thought on a filter using regular expressions for filtering
out certain requests. But I'm not sure if this is secure enough. Just
think of "modified" request-urls using hex numbers for escaping ascii
characters (e.g. ".../%43VS/..." instead of ".../CVS/..."). Are those
urls normalized by tomcat, i.e. does request.getRequestURL() return
".../CVS/..." in both cases?
Tex
> Just a thought or two --
>
> 1) Setup a request filter that detects when the URL contains the
> pattern CVS/ and redirects to a default or error page.
> -or-
> 2) Setup a servlet mapping for any of the potential CVS URLs and have
> them map to a servlet that responds with an error or redirect.
>
>
> --David
>
> Mario Winterer wrote:
>
>> Thanks for your and Nix' advice - I know that what I do is not the
>> clean and nice approach. If I were you, I'd challenge my solution too!
>> But: In fact - we do have local CVS sandboxes on the development PCs
>> - and we do have a separate development webserver for testing. And we
>> do use this system when we are developing, testing and bugfixing our
>> web application.
>> But while we are developing, several people need to maintain static
>> resources. Not a big thing, just updating a handful of HTML pages. To
>> make things easier this changes are done directly on the "real"
>> webserver (please do not challenge that - this approach is OK for us).
>> By using CVS on the "real" webserver, we kill two birds with one stone:
>> 1) The static content is versioned
>> 2) By using branches, we can easily merge the content of the "real"
>> server (the HEAD-branch) and the development version (the
>> development-branch) from time to time.
>> All that without a big deployment process (that makes it difficult
>> for the handful of people that just want to do some minor updates of
>> their web pages).
>>
>> So our CVS solution is the best one for our needs - I think.
>> But back to my question: Is there a (good and secure) way to protect
>> my CVS resources?
>>
>> Best regards,
>> Tex
>>
>>> How about doing your development in a different area,
>>> and do your your deployment via export?
>>>
>>> You could also frontend your Tomcat wtih Apache and
>>> deny access with Apache.
>>>
>>> Just a couple of random thoughts . . .
>>> /mde/
>>>
>>>
>>> __________________________________ Do you Yahoo!? Yahoo!
>>> Mail - You care about security. So do we.
>>> http://promotions.yahoo.com/new_mail
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Hiding resources
Posted by David Smith <dn...@cornell.edu>.
Just a thought or two --
1) Setup a request filter that detects when the URL contains the pattern
CVS/ and redirects to a default or error page.
-or-
2) Setup a servlet mapping for any of the potential CVS URLs and have
them map to a servlet that responds with an error or redirect.
--David
Mario Winterer wrote:
> Thanks for your and Nix' advice - I know that what I do is not the
> clean and nice approach. If I were you, I'd challenge my solution too!
> But: In fact - we do have local CVS sandboxes on the development PCs -
> and we do have a separate development webserver for testing. And we do
> use this system when we are developing, testing and bugfixing our web
> application.
> But while we are developing, several people need to maintain static
> resources. Not a big thing, just updating a handful of HTML pages. To
> make things easier this changes are done directly on the "real"
> webserver (please do not challenge that - this approach is OK for us).
> By using CVS on the "real" webserver, we kill two birds with one stone:
> 1) The static content is versioned
> 2) By using branches, we can easily merge the content of the "real"
> server (the HEAD-branch) and the development version (the
> development-branch) from time to time.
> All that without a big deployment process (that makes it difficult for
> the handful of people that just want to do some minor updates of their
> web pages).
>
> So our CVS solution is the best one for our needs - I think.
> But back to my question: Is there a (good and secure) way to protect
> my CVS resources?
>
> Best regards,
> Tex
>
>> How about doing your development in a different area,
>> and do your your deployment via export?
>>
>> You could also frontend your Tomcat wtih Apache and
>> deny access with Apache.
>>
>> Just a couple of random thoughts . . .
>> /mde/
>>
>>
>>
>>
>> __________________________________ Do you Yahoo!? Yahoo! Mail - You
>> care about security. So do we. http://promotions.yahoo.com/new_mail
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Hiding resources
Posted by Mario Winterer <ma...@eduhi.at>.
Thanks for your and Nix' advice - I know that what I do is not the clean
and nice approach. If I were you, I'd challenge my solution too!
But: In fact - we do have local CVS sandboxes on the development PCs -
and we do have a separate development webserver for testing. And we do
use this system when we are developing, testing and bugfixing our web
application.
But while we are developing, several people need to maintain static
resources. Not a big thing, just updating a handful of HTML pages. To
make things easier this changes are done directly on the "real"
webserver (please do not challenge that - this approach is OK for us).
By using CVS on the "real" webserver, we kill two birds with one stone:
1) The static content is versioned
2) By using branches, we can easily merge the content of the "real"
server (the HEAD-branch) and the development version (the
development-branch) from time to time.
All that without a big deployment process (that makes it difficult for
the handful of people that just want to do some minor updates of their
web pages).
So our CVS solution is the best one for our needs - I think.
But back to my question: Is there a (good and secure) way to protect my
CVS resources?
Best regards,
Tex
>How about doing your development in a different area,
>and do your your deployment via export?
>
>You could also frontend your Tomcat wtih Apache and
>deny access with Apache.
>
>Just a couple of random thoughts . . .
>
>/mde/
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail - You care about security. So do we.
>http://promotions.yahoo.com/new_mail
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Hiding resources
Posted by Mark Eggers <it...@yahoo.com>.
How about doing your development in a different area,
and do your your deployment via export?
You could also frontend your Tomcat wtih Apache and
deny access with Apache.
Just a couple of random thoughts . . .
/mde/
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org