Well, it's the usual thing - you can have a system that's completely open but gets cratered because some duffer clicked the wrong button. Or you can have a system that's 100% secure, but nobody can use it because it's 100% secure. Or you can have something that's "secure enough" to protect from accidents and any but the most determined black hat, which is really what I'm aiming for here.
Pete Pid <p...@pidster.com> wrote on 05/17/2010 11:47:52 AM: > On 17/05/2010 18:14, peter_f...@blm.gov wrote: > > Pid <p...@pidster.com> wrote on 05/17/2010 10:55:06 AM: > > > >> On 17/05/2010 17:48, peter_f...@blm.gov wrote: > >>> To clarify what I'm up to here - we have an in-house doc that suggests > >>> switching off autoDeploy and deployOnStartup on production systems, and > >> > >> Does it explain why it makes this suggestion? > > > > To prevent someone accidentally (or otherwise, of course) deploying an > > application in a production system simply by dropping in a WAR. > > > >> > >>> I've been testing those recommendations on an experimental setup. What > > the > >>> in-house doc forgets to say is what you've explained here (and which > >>> answers my original question - thanks!) which is that you have to put a > >>> Context element into the server.xml to make it work. > >> > >> Which is explicity discouraged in current versions of Tomcat. > > > > Yes, but in a fixed production setting it makes sense. At least in that > > setting you'd have to be able to edit server.xml, which is not something > > you're going to do by accident. > > With the right settings, you'd still need to restart the server, even if > someone had managed to accidentally update the war files. > > Seems a little paranoid, but hey... > > > p > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
