Re: Hiding resources
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hiding resources
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hiding resources
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hiding resources
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hiding resources
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hiding resources
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
