tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Winterer <mario.winte...@eduhi.at>
Subject Re: Hiding resources
Date Thu, 03 Feb 2005 21:05:53 GMT
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


Mime
View raw message