Re: Tomcat 7 - META-INF/context.xml
Filip Hanik - Dev Lists wrote: I would like to suggest that context.xml files that are contained within directories or WAR files do not get copied to a sub directory under conf where it remains if the war file or directory is removed while the server is shutdown. Copying the file META-INF/context.xml has never made much sense to me on why that was necessary or logical, it seems as a WAR file is self contained, and should remain so. what ya say? I'd be +1 for making the extraction of META-INF/context.xml optional with a slight preference for the default behaviour to be consistent with Tomcat 6. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DBCP 1.3/1.4
Filip Hanik - Dev Lists wrote: the only downside to my suggestions above is that jdbc-pool doesn't have much developer community around it. the usage of it has grown, and the bug reports have been very few and no major issues are outstanding. unless we can build a community around it, we need to figure out what to do with it. Hence my suggestion to use jdbc-pool as the basis for the commons-pool and commons-dbcp refactoring. Commons has the developer community jdbc-pool needs and jdbc-pool has the improvements commons-pool and commons-dbcp needs. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPNEGO/NEGOTIATE implementation for Apache Geronimo
Hi folks, Can you please suggest if there is anyway to disable the prompt for username and password when using basic authentication?? Thanks and Regards Ashish On 11/13/09, Costin Manolache cos...@gmail.com wrote: On Fri, Nov 13, 2009 at 6:44 AM, Mark Thomas ma...@apache.org wrote: Ashish Jain wrote: 4) Does this require code changes to BasicAuthenticator FormAuthenticator, AuthenticatorBase of tomcat. Basic and form - no. Base - maybe. Please provide your comment and suggestions. My instinct (that may be wrong) is that you'll need a new authenticator. If you get this working then I'd certainly consider it for inclusion in Tomcat. An OpenID would be nice too :-) Costin Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 - META-INF/context.xml
On 12/09/2009 02:57 AM, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: I would like to suggest that context.xml files that are contained within directories or WAR files do not get copied to a sub directory under conf where it remains if the war file or directory is removed while the server is shutdown. Copying the file META-INF/context.xml has never made much sense to me on why that was necessary or logical, it seems as a WAR file is self contained, and should remain so. what ya say? I'd be +1 for making the extraction of META-INF/context.xml optional with a slight preference for the default behaviour to be consistent with Tomcat 6. I thought even 6 has been inconsistent, copy in one version and don't copy in another? or did I misunderstand that? Filip Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 - META-INF/context.xml
Filip Hanik - Dev Lists wrote: On 12/09/2009 02:57 AM, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: I would like to suggest that context.xml files that are contained within directories or WAR files do not get copied to a sub directory under conf where it remains if the war file or directory is removed while the server is shutdown. Copying the file META-INF/context.xml has never made much sense to me on why that was necessary or logical, it seems as a WAR file is self contained, and should remain so. what ya say? I'd be +1 for making the extraction of META-INF/context.xml optional with a slight preference for the default behaviour to be consistent with Tomcat 6. I thought even 6 has been inconsistent, copy in one version and don't copy in another? or did I misunderstand that? 6.0.x was inconsistent between WARs and directories. That was made consistent in 6.0.19. META-INF/context.xml in WAR files always extracts/copies META-INF/context.xml in a directory doesn't copy 6.0.19, does copy 6.0.19 onwards Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48358] New: JSP-unloading reloaded
https://issues.apache.org/bugzilla/show_bug.cgi?id=48358 Summary: JSP-unloading reloaded Product: Tomcat 7 Version: trunk Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: isa...@apache.org Created an attachment (id=24684) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24684) Patch including tests that fixed the problem for us. Currently Tomcat does not support unloading JSPs. When constantly changing and reloading JSP files (especially during development time) this causes the JVM to run out of memory. The patch fixes this problem by tracking the last time a JSP page was requested. Objects are destroyed if a configurable number of JSPs is live, starting with the oldest ones. This behaviour is deactivated by default. It must be configured explicitly. The patch comes with tests that check the added functionality. To make testing easier I added easymock as dependency to the classpath. I'd appreciate any feedback on the code changes - suggestions for improvement, potential problems with the code etc. This work was done in collaboration with some of my colleagues at work. I will forward a link to this bug entry to those involved so they can provide more information on the background of the patch if needed. On a side note: Just in case you might like to include the patch - I couldn't find a patch intended for inclusion check box (like the one in jira) in bugzilla - thus stating explicitly: License to ASF granted for inclusion in ASF works (as per the Apache License §5). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r888860 - in /tomcat/site/trunk: docs/security-5.html docs/security-6.html xdocs/security-5.xml xdocs/security-6.xml
Author: markt Date: Wed Dec 9 16:29:54 2009 New Revision: 60 URL: http://svn.apache.org/viewvc?rev=60view=rev Log: Add some info on CVE-2009-3555 Modified: tomcat/site/trunk/docs/security-5.html tomcat/site/trunk/docs/security-6.html tomcat/site/trunk/xdocs/security-5.xml tomcat/site/trunk/xdocs/security-6.xml Modified: tomcat/site/trunk/docs/security-5.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-5.html?rev=60r1=59r2=60view=diff == --- tomcat/site/trunk/docs/security-5.html (original) +++ tomcat/site/trunk/docs/security-5.html Wed Dec 9 16:29:54 2009 @@ -1104,6 +1104,39 @@ td p blockquote + +p +strongTLS SSL Man In The Middle/strong + a href=http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555; + CVE-2009-3555/a +/p + +pA vulnerability exists in the TLS protocol that allows an attacker to + inject arbitrary requests into an TLS stream during renegotiation./p + +pThe TLS implementation used by Tomcat varies with connector. The blocking + IO (BIO) and non-blocking (NIO) connectors use the JSSE implementation + provided by the JVM. The APR/native connector uses OpenSSL./p + +pThe BIO connector is vulnerable if the JSSE version used is vulnerable. + To workaround this until a fix is available in JSSE, a new connector + attribute codeallowUnsafeLegacyRenegotiation/code has been added to + the BIO connector. It should be set to codefalse/code (the default) + to protect against this vulnerability. The attribute will be available in + Tomcat 6.0.21 onwards./p + +pThe NIO connector is not vulnerable as it does not support + renegotiation./p + +pThe APR/native connector is vulnerable if the OpenSSL version used is + vulnerable. Building with OpenSSL 0.9.8l will disable all renegotiation + and protect against this vulernability./p + +pUsers should be aware that the impact of disabling renegotiation will + vary with both application and client. In some circumstances disabling + renegotiation may result in some clients being unable to access the + application./p + p strongJavaMail information disclosure/strong a href=http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1754; Modified: tomcat/site/trunk/docs/security-6.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-6.html?rev=60r1=59r2=60view=diff == --- tomcat/site/trunk/docs/security-6.html (original) +++ tomcat/site/trunk/docs/security-6.html Wed Dec 9 16:29:54 2009 @@ -842,7 +842,40 @@ td p blockquote - p + +p +strongTLS SSL Man In The Middle/strong + a href=http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555; + CVE-2009-3555/a +/p + +pA vulnerability exists in the TLS protocol that allows an attacker to + inject arbitrary requests into an TLS stream during renegotiation./p + +pThe TLS implementation used by Tomcat varies with connector. The blocking + IO (BIO) and non-blocking (NIO) connectors use the JSSE implementation + provided by the JVM. The APR/native connector uses OpenSSL./p + +pThe BIO connector is vulnerable if the JSSE version used is vulnerable. + To workaround this until a fix is available in JSSE, a new connector + attribute codeallowUnsafeLegacyRenegotiation/code has been added to + the BIO connector. It should be set to codefalse/code (the default) + to protect against this vulnerability. The attribute will be available in + Tomcat 6.0.21 onwards./p + +pThe NIO connector is not vulnerable as it does not support + renegotiation./p + +pThe APR/native connector is vulnerable if the OpenSSL version used is + vulnerable. Building with OpenSSL 0.9.8l will disable all renegotiation + and protect against this vulernability./p + +pUsers should be aware that the impact of disabling renegotiation will + vary with both application and client. In some circumstances disabling + renegotiation may result in some clients being unable to access the + application./p + +p strongimportant: Directory traversal/strong a href=http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2938; CVE-2008-2938/a Modified: tomcat/site/trunk/xdocs/security-5.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-5.xml?rev=60r1=59r2=60view=diff == --- tomcat/site/trunk/xdocs/security-5.xml (original) +++ tomcat/site/trunk/xdocs/security-5.xml Wed Dec 9 16:29:54 2009 @@ -504,6 +504,37 @@ /section section name=Not a vulnerability in Tomcat + +
svn commit: r888904 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: pero Date: Wed Dec 9 18:15:08 2009 New Revision: 888904 URL: http://svn.apache.org/viewvc?rev=888904view=rev Log: cast my vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=888904r1=888903r2=888904view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Dec 9 18:15:08 2009 @@ -459,7 +459,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47342 Fix NPE on replicated context start Patch provided by Keiichi Fujino - +1: markt + +1: markt, pero -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47453 @@ -473,7 +473,7 @@ Don't try and replicate attributes we know to be non-serializable Patch by Tim Funk http://svn.apache.org/viewvc?rev=886019view=rev - +1: markt + +1: markt, pero -1: * Prevent lost log messages on shutdown - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 - META-INF/context.xml
On 12/09/2009 07:06 AM, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: On 12/09/2009 02:57 AM, Mark Thomas wrote: Filip Hanik - Dev Lists wrote: I would like to suggest that context.xml files that are contained within directories or WAR files do not get copied to a sub directory under conf where it remains if the war file or directory is removed while the server is shutdown. Copying the file META-INF/context.xml has never made much sense to me on why that was necessary or logical, it seems as a WAR file is self contained, and should remain so. what ya say? I'd be +1 for making the extraction of META-INF/context.xml optional with a slight preference for the default behaviour to be consistent with Tomcat 6. I thought even 6 has been inconsistent, copy in one version and don't copy in another? or did I misunderstand that? 6.0.x was inconsistent between WARs and directories. That was made consistent in 6.0.19. META-INF/context.xml in WAR files always extracts/copies META-INF/context.xml in a directory doesn't copy6.0.19, does copy 6.0.19 onwards Then I suggest making everything in TC 7 consistent with directories 6.0.19 That's the whole point, it creates nothing but confusion to move the file out, since it remains there and results in a failed deployment if you remove a WAR file/directory while the server is not running Filip Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of PoweredBy by Corina Mandel
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The PoweredBy page has been changed by Corina Mandel.
http://wiki.apache.org/tomcat/PoweredBy?action=diffrev1=211rev2=212
--
{{http://www.hahnefeld.de/images/archive/small.jpg}}
björn hahnefeld IT TC_Framework [[http://www.hahnefeld.de|björn hahnefeld
IT]] runs on Tomcat. It is a Framework for the ATOSS employee portal with runs
on Tomcat too. Hosting-Plans for the björn hahnefeld IT TC_Framework can be
booked under [[http://www.hahnefeld.de/internet-services_server.html|TomCat
Co-Location and Serverhousing]].
+ = Duramental Shop =
+ {{http://www.duramental.de/images/logo/meria.gif}}
+ Duramental Online-Shop [[http://www.duramental.de|DURAMENTAL Glutathion]]
runs on Tomcat and is realized on JSP-Pages. The Backend is a client solution
based on swing. A complete Java-App!
Anchor(more)
== More Stuff ==
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of PoweredBy by Corina Mandel
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The PoweredBy page has been changed by Corina Mandel.
http://wiki.apache.org/tomcat/PoweredBy?action=diffrev1=212rev2=213
--
= Duramental Shop =
{{http://www.duramental.de/images/logo/meria.gif}}
- Duramental Online-Shop [[http://www.duramental.de|DURAMENTAL Glutathion]]
runs on Tomcat and is realized on JSP-Pages. The Backend is a client solution
based on swing. A complete Java-App!
+ Duramental Online-Shop [[http://www.duramental.de|DURAMENTAL Glutathion]]
runs on Tomcat and is realized with JSP-Pages. The Backend is a client solution
based on swing - a complete Java-App!
Anchor(more)
== More Stuff ==
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPNEGO/NEGOTIATE implementation for Apache Geronimo
On Dec 9, 2009, at 5:03 AM, Ashish Jain wrote: Hi folks, Can you please suggest if there is anyway to disable the prompt for username and password when using basic authentication?? That's browser behavior, so the only thing you can do from the server side is not use plain BASIC auth. Are you using a SPNEGO enabled browser on a platform where it can recognize your (client side) kerberos login? Do you have a link to a description of how SPNEGO is supposed to work? thanks david jencks Thanks and Regards Ashish On 11/13/09, Costin Manolache cos...@gmail.com wrote: On Fri, Nov 13, 2009 at 6:44 AM, Mark Thomas ma...@apache.org wrote: Ashish Jain wrote: 4) Does this require code changes to BasicAuthenticator FormAuthenticator, AuthenticatorBase of tomcat. Basic and form - no. Base - maybe. Please provide your comment and suggestions. My instinct (that may be wrong) is that you'll need a new authenticator. If you get this working then I'd certainly consider it for inclusion in Tomcat. An OpenID would be nice too :-) Costin Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 45255] support disable jsessionid from url against session fixation attacks
https://issues.apache.org/bugzilla/show_bug.cgi?id=45255 --- Comment #20 from jcran jc...@0x0e.org 2009-12-09 23:59:01 UTC --- i should be careful. it doesn't prevent all session hijacking. just certain use-cases. see comments above. jcran -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
