Tomcat 7.0.54 - Session invalidate broken in some apps
I've found that certain applications will no longer invalidate sessions after upgrading from 7.0.53 to 7.0.54. It seems to require clustering to be set up in Tomcat. If it's not set up, session invalidation works fine. So far, I can only trigger it in a webapp that uses Tapestry Spring Security. I see a few changes in the changelog related to session invalidate and clustering, could one of these changes be responsible? Anyone else see the same issue? -Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
(Slightly OT): Server JVM 7
I have found that under JRE 6 (haven't tested 7 for performance yet, only functionality) that the server jvm gives me much better performance for Tomcat than the client JVM does. However, I can only find a 64-bit server JVM for Java 7, while in Java 6, there was both a 32-bit and 64-bit server JVM. Is there a 32-bit server JVM for Java 7 that I'm just not seeing? I want to stick with 32-bit because none of my apps use anywhere enough memory to need 64-bit addressing, and 32-bit is supposed to reduce the memory footprint a bit and give slightly better performance. It also means I don't need 64-bit ODBC DSNs, along with the 32-bit ones that some of my GUI apps need. Thanks for any links or into... Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: (Slightly OT): Server JVM 7
Hi David, -Original Message- From: David kerber [mailto:dcker...@verizon.net] Sent: Thursday, May 29, 2014 3:35 PM I have found that under JRE 6 (haven't tested 7 for performance yet, only functionality) that the server jvm gives me much better performance for Tomcat than the client JVM does. However, I can only find a 64-bit server JVM for Java 7, while in Java 6, there was both a 32-bit and 64-bit server JVM. Is there a 32-bit server JVM for Java 7 that I'm just not seeing? I want to stick with 32-bit because none of my apps use anywhere enough memory to need 64- bit addressing, and 32-bit is supposed to reduce the memory footprint a bit and give slightly better performance. It also means I don't need 64-bit ODBC DSNs, along with the 32-bit ones that some of my GUI apps need. Thanks for any links or into... Dave I don't know how it is on other OSes, but AFAIK for Windows, Oracle's JDK(32-bit and 64-bit) always contains a Server VM, whereas 32-bit JRE does not. On 64-bit JRE and JDK, only a Server JVM is available. However I don't know what is included in Server JRE that is also available for download. Example output when a 32-bit JDK (Java7) and 32-bit + 64-bit JRE (Java8) is installed: C:\C:\Program Files (x86)\Java\jdk1.7.0_60\jre\bin\java -version java version 1.7.0_60 Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing) C:\C:\Program Files (x86)\Java\jdk1.7.0_60\jre\bin\java -server -version java version 1.7.0_60 Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) Server VM (build 24.60-b09, mixed mode) C:\C:\Program Files (x86)\Java\jdk1.7.0_60\bin\java -version java version 1.7.0_60 Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing) C:\C:\Program Files (x86)\Java\jdk1.7.0_60\bin\java -server -version java version 1.7.0_60 Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) Server VM (build 24.60-b09, mixed mode) C:\C:\Program Files (x86)\Java\jre8\bin\java -server -version Error: missing `server' JVM at `C:\Program Files (x86)\Java\jre8\bin\server\jvm.dll'. Please install or use the JRE or JDK that contains these missing components. C:\C:\Program Files\Java\jre8\bin\java -version java version 1.8.0_05 Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL on one subdirectory only.
On Tue, May 27, 2014 at 2:21 PM, Mark Thomas ma...@apache.org wrote: On 27/05/2014 17:31, John Smith wrote: Tomcat 7.0.42, RHEL6, JDK1.7.0_25, Standalone TC configuration. IPTABLES route port 80 to 8080 I've got a subdirectory like 'www.mysite.com/admin' that I want to put under FORM based authentication. That's clear enough, and I've got the java keytool cert working well enough on my dev box until I get one from a CA. Couple of questions: 1. Anyone familiar with any problems routing 443 to 8443 on *nix boxes for TC SSL certs? It's preferable to not have my end users needing port numbers. The cert doesn't care about the port, IIRC. Should be fine. 2. With the SSL connector enabled, https://* is globally respected on the entire webapp. Do I need to manually check the URL/protocol to deny or redirect https to http outside of '/admin'? Is there any built in TC mechanism or suggested best practice to handle this? or should I not care? Nothing to automatically handle https - http. Unless it causes an issue, I'd just leave it. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Mark, Thanks and appreciated, as always.
Re: (Slightly OT): Server JVM 7
Thanks, Konstantin, that was what I needed. I knew but had forgotten about the JDK having the server JRE. Dave On 5/29/2014 9:58 AM, Konstantin Preißer wrote: Hi David, -Original Message- From: David kerber [mailto:dcker...@verizon.net] Sent: Thursday, May 29, 2014 3:35 PM I have found that under JRE 6 (haven't tested 7 for performance yet, only functionality) that the server jvm gives me much better performance for Tomcat than the client JVM does. However, I can only find a 64-bit server JVM for Java 7, while in Java 6, there was both a 32-bit and 64-bit server JVM. Is there a 32-bit server JVM for Java 7 that I'm just not seeing? I want to stick with 32-bit because none of my apps use anywhere enough memory to need 64- bit addressing, and 32-bit is supposed to reduce the memory footprint a bit and give slightly better performance. It also means I don't need 64-bit ODBC DSNs, along with the 32-bit ones that some of my GUI apps need. Thanks for any links or into... Dave I don't know how it is on other OSes, but AFAIK for Windows, Oracle's JDK(32-bit and 64-bit) always contains a Server VM, whereas 32-bit JRE does not. On 64-bit JRE and JDK, only a Server JVM is available. However I don't know what is included in Server JRE that is also available for download. Example output when a 32-bit JDK (Java7) and 32-bit + 64-bit JRE (Java8) is installed: C:\C:\Program Files (x86)\Java\jdk1.7.0_60\jre\bin\java -version java version 1.7.0_60 Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing) C:\C:\Program Files (x86)\Java\jdk1.7.0_60\jre\bin\java -server -version java version 1.7.0_60 Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) Server VM (build 24.60-b09, mixed mode) C:\C:\Program Files (x86)\Java\jdk1.7.0_60\bin\java -version java version 1.7.0_60 Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing) C:\C:\Program Files (x86)\Java\jdk1.7.0_60\bin\java -server -version java version 1.7.0_60 Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) Server VM (build 24.60-b09, mixed mode) C:\C:\Program Files (x86)\Java\jre8\bin\java -server -version Error: missing `server' JVM at `C:\Program Files (x86)\Java\jre8\bin\server\jvm.dll'. Please install or use the JRE or JDK that contains these missing components. C:\C:\Program Files\Java\jre8\bin\java -version java version 1.8.0_05 Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL on one subdirectory only.
2. With the SSL connector enabled, https://* is globally respected on the entire webapp. Do I need to manually check the URL/protocol to deny or redirect https to http outside of '/admin'? Is there any built in TC mechanism or suggested best practice to handle this? or should I not care? We use two-factor authentification with SSL - but I think in your case this can be helpful too - not a big difference. Try look at this: http://wiki.metawerx.net/wiki/ForcingSSLForSectionsOfYourWebsite Arseny, thank you. I wasn't aware of the user-data-constraint and transport-guarantee elements. I'll give them a try.
Re: Tomcat 7.0.54 - Session invalidate broken in some apps
2014-05-29 11:58 GMT+04:00 David Rees dree...@gmail.com: I've found that certain applications will no longer invalidate sessions after upgrading from 7.0.53 to 7.0.54. It seems to require clustering to be set up in Tomcat. If it's not set up, session invalidation works fine. So far, I can only trigger it in a webapp that uses Tapestry Spring Security. I see a few changes in the changelog related to session invalidate and clustering, could one of these changes be responsible? What are the symptoms? Is there anything unusual in the log files? Is a single web application affected, or it spans several applications (via Single Sign On)? You may consider debugging. http://wiki.apache.org/tomcat/FAQ/Developing#Debugging You may consider simplifying you configuration to build a simple reproduce scenario for a bug report. Anyone else see the same issue? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0095 Apache Tomcat denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 5/27/14, 2:41 PM, Christopher Schultz wrote: All, On 5/27/14, 8:46 AM, Mark Thomas wrote: CVE-2014-0095 Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 8.0.0-RC2 to 8.0.3 Description: A regression was introduced in revision 1519838 that caused AJP requests to hang if an explicit content length of zero was set on the request. The hanging request consumed a request processing thread which could lead to a denial of service. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 8.0.5 or later (8.0.4 contains the fix but was not released) Alternate mitigation: SetEnvIf Content-Length ^0$ no-jk=1 After a bit of testing, I can see that clients will often send Content-Length: 0 for a POST request that in fact has no form data (e.g. all fields are DISABLED or there simply are no child input elements for a form). Beware, as this may have an adverse impact on your web application if you have used the above mitigation: Tomcat will never see these form submissions and clients will likely get a 404 error. Apologies for the bad advice. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh28EAAoJEBzwKT+lPKRYrOEQAKkgB6psAONqCqftqjaqLCy2 uY4HgaZpp1znhpju5Lavzib/3eDMewb43ge9FlUEpkkpa1wGazej0k8rlQw1Blsd 9YdHY5/nMhyF09B3qj8pocF+V5TWq0faqsb64XntHArS29Q5/iCFchPSwGP6YlMD S4iULE61YZj5tkVT+QSJoU/Q0AhdBLyIb2gpvNHF+qrJE+EqvCY7ticuUh0YiwuM nCmszteNJb9EW+AdC6rbeAxT7QlZcE2krLWNjf75NZOP42+GlRnBi2BuP/v/FSAV h8XNxFw/361/mGgeZG0olE+Dniv/4BY5JXX7CoSj0oYtn3UzabVY9WoUSqlMoKUB 1NXQRGm3+pVLSKtf1EJCnH2MJP2MRAw4GXTlOUxZLGJqUvcYZ0ih5TJAwKE6f19n Y+jyfddKbKYTwz2Muxcj4AYFPmQnXsD6eq5R/ziAxBz3rzX8wCYw2eS+O2QGRzy0 52RnFmzDKcIaZTN5LPvGvNcmWOMQEB2+mPwjkBOXv/jb5MEqMdruqGtkeAtjRJ/a dAPdpJb8DBBIfle68AW4rhsPvIHTOc5a7wlQjyr3VOLztKfaI8dOZD0jM0LN/mwH 3Be7/zBCnNuN4UpzBCZPfQRHKBRReAUfNepIBZA4yOpTqMhk1SJlqlNQ/u2tPFVZ ihkIIQrRyi5jb3CUrDNq =aNQ4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgrading Tomcat version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/28/14, 8:12 AM, Mark Thomas wrote: On 28/05/2014 13:06, David kerber wrote: Right now I'm running TC 7.0.22 on Windows Server 2008 R2, as windows services. Not using APR. To upgrade to the latest version, I should be able to just stop the services and unzip the latest .zip version on top of the existing Tomcat installation, right? Wrong. At least one JAR (ecj*.jar, the Eclipse compiler) has changed names so you'll have multiple versions of that JAR. You'll need to remove the old versions. You are also likely to clobber any customisations you have in server.xml or any of the other files in conf. You can do it this way but you need to be really careful. +1 I always favor the use of CATALNA_HOME + CATALINA_BASE. This allows you to unzip a new Tomcat into a new CATALINA_HOME (e.g. /usr/local/tomcat/7.0.54), stopping the old JVM, changing the CATALINA_HOME environment variable to point to the new Tomcat, and re-launching. If things go badly, just change your CATALINA_HOME back to the old value and re-restart. Everything should be back the way it was and you can inspect *both* configurations to see what might be the problem. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh3KNAAoJEBzwKT+lPKRYWTEP/jqwXjEYvanuJUy9ucQQj3hO ODwP6al/nTibO+CG4JrKDCps/b3mKyzgePjen2a3NiImLXk2PGsqEh/QnOdiLscZ znzcb6tfdYegv9PBR5yuPaiXelAuSMUMlOE84bDBCBtZp4q0VZRfGsYIyW3fMfJT 21e6WcGYlIMng8SoIDlyJWUhv24mY+C3IBgrFCT6kHbCVAIXlkysSA30ysx3LTbl vT8LpLfKepXJEzhKGE6t7xTSlRYpngylhnv4ikwW8wx0V5zkAIgfTC4URPRxEVXv 5BNDgS/VgDUCShmpcl7Y/4RyXj73E/r+q0V/sU5YQCumYjnN5eHljyH5Z9yF/RqT ewe5QeNtG7J8Ii+5iaR+o1Lqo/O0nI+RhzEs5IeLioNSrSu/dhpbD5b0Pzx+bhBC /azeBZnRd9BkK1QWZXVlPsQS6Be4cwOZQmsuJyVEcVfVGHRcgfkBgoD5J/wZz4/1 YC9w9meetdZrUFpufKKV8Uw+WX6M3NadWp2c6JfkXUxZzEHSw2ikFOvQ5T8WYrd9 iSlco8xopPJvC65yt8+0sJK4vkYuOrypyponhyMdfUWz+Ldvc93YICiMOXzUAGRQ STZgk+xek9+BX0LGvAZXG6Ri6UJtNfoidjsH7+BOQBaUWjCQwjay3BgEaqhUKUG0 JPQylv6Wo9YJUDKtmrT9 =9Ut7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk 1.2.27 stack smashing detected on centos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dino, On 5/28/14, 5:49 AM, Dino Ciuffetti wrote: Hi there. My name is Dino Ciuffetti, I'm a linux sysadmin and I'm new to this list. I have a sporadic problem with mod_jk (tomcat connectors), I hope someone can help me on this. I have Apache/2.2.15 (Unix) mod_jk/1.2.37 PHP/5.3.3 Apache, and PHP are installed via RPM (centos packages), while mod_jk was compiled from source. Subject says 1.2.27 and above says 1.2.37. I assume 1.2.37 is correct but please check. In any case, can you re-test with 1.2.40, and make sure that debugging symbols are included in the build? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh3QEAAoJEBzwKT+lPKRYv8gP/2T8XIX6PWlRhz+kbB7Qpol2 qu0H5pCM1+Nkn9RCCoK0pokqpfwUfRh/0jw0+zAmU0q3sk/7Q417qyUKoDaeKlqV Lf2Cmwtbpz0NZitUJ8Gbv8wU6klQoNmE51qOy76DN3dS1d3+bcXywhEduIstud5V wDRgjBf1G0wpYHv7xUclzp1sTSWRw9eo76vlsMKUyQLHEFDXqRT/bu42F4Bq26DH S6HKtVjkTjrBkx3KoAb27SEZgiQ2+OtWXs5MZTOaZzuDwNogNXuYUREuTpsAGgzX mycov6V4QfBf7pl740BSSvc3EcwXHzelag2r+0aAF1FVHdf8qR9bCNEbFFl8X7Pl PSfk5MNfevQ8ahhZ+rgjUBcl86nDwgHivCdj4xCWfo+ML3EcwpFLEXbHY1pPFcml g5PQSw4qPrvHD9POqi7OCa29uJJg/PSzjj4IfYRc4kvCoqH8npCxrdRrXmY6XMAU 89qhCOko1F7EHEYj0tC3Vlx/qewteOeMJdSwZKZwFyBxF3whAwCEWDOUPIKK4gBQ Mhb8xgibELQ2CKA1GPCAbwVGiHjvGuyqZKb+m4AgPNOXGyxhxNeMe3snBELnpJoW rYbrF9Rz08yn9I7G/kNN7n8SY3lNirmpfVFBjpFPiUZkLJxv8PAJ+KHKdf2IpBAc +D/GeioZAlxjN1lZgNW7 =T6+g -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
comet question
Hey guys, I found this on the web, and it really alarms me because my web app which is in development depends on Comet technology to work. http://bighow.net/4294974-Comet_under_Tomcat_6_0_33_sends_data_to_a_wrong_user.html Before I start digging into the tomcat7 source code, can anyone verify or contest the issue on that site? If Comet is not 100% dependable, how about WebSockets as an alternative?
Re: comet question
oh yea, im on tomcat 7 btw On Thu, May 29, 2014 at 2:13 PM, Elias Kopsiaftis yemi...@gmail.com wrote: Hey guys, I found this on the web, and it really alarms me because my web app which is in development depends on Comet technology to work. http://bighow.net/4294974-Comet_under_Tomcat_6_0_33_sends_data_to_a_wrong_user.html Before I start digging into the tomcat7 source code, can anyone verify or contest the issue on that site? If Comet is not 100% dependable, how about WebSockets as an alternative?
Re: comet question
On 5/29/2014 2:21 PM, Elias Kopsiaftis wrote: oh yea, im on tomcat 7 btw Then why are you asking about a problem in a very old version of Tomcat 6? On Thu, May 29, 2014 at 2:13 PM, Elias Kopsiaftis yemi...@gmail.com wrote: Hey guys, I found this on the web, and it really alarms me because my web app which is in development depends on Comet technology to work. http://bighow.net/4294974-Comet_under_Tomcat_6_0_33_sends_data_to_a_wrong_user.html Before I start digging into the tomcat7 source code, can anyone verify or contest the issue on that site? If Comet is not 100% dependable, how about WebSockets as an alternative? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet question
To make sure it doesnt exist in Tomcat7. Thats why. Ive never looked into the tomcat source code and theres no point for my current project unless this bug still exists. Just trying to save myself the work. Also, I couldnt find a page of known tomcat7 comet issues. If such a page existed it would be helpful On Thu, May 29, 2014 at 2:45 PM, David kerber dcker...@verizon.net wrote: On 5/29/2014 2:21 PM, Elias Kopsiaftis wrote: oh yea, im on tomcat 7 btw Then why are you asking about a problem in a very old version of Tomcat 6? On Thu, May 29, 2014 at 2:13 PM, Elias Kopsiaftis yemi...@gmail.com wrote: Hey guys, I found this on the web, and it really alarms me because my web app which is in development depends on Comet technology to work. http://bighow.net/4294974-Comet_under_Tomcat_6_0_33_ sends_data_to_a_wrong_user.html Before I start digging into the tomcat7 source code, can anyone verify or contest the issue on that site? If Comet is not 100% dependable, how about WebSockets as an alternative? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 5/29/14, 2:45 PM, David kerber wrote: On 5/29/2014 2:21 PM, Elias Kopsiaftis wrote: oh yea, im on tomcat 7 btw Then why are you asking about a problem in a very old version of Tomcat 6? +1 Also, that web site looks like a scraping site that steals content from some other site like StackOverflow, Nabble, etc. The question isn't even complete it cuts off in the middle. Errors of this kind are usually due to a problem in the application, but there have been some edge cases found over the last few years and patched. You should make sure you are using the most up-to-date patch version of Tomcat in your release line. If you are using Tomcat 7, you want to make sure you are using Tomcat 7.0.54 which was just recently released and includes a few security updates. As for a technology for the future, you should dump Comet: the world is standardizing on Websocket. Java EE now includes a Websocket API, so you'll be able to deploy Websocket-based web applications on any compliant container instead of tying yourself to the Tomcat-specific Comet implementation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh4YUAAoJEBzwKT+lPKRYGG4QAMta8eJb8vCRFz/+JKLxLmja Ufeklv7CL1W+UDcljU/0t9YuWk1pfGiXRn2ORgLDuZUee69Eb2c959z4owpMaEiX ctqWTre1qA7sYCuQkBHehsOP4ohGYnhvndFeqJEMHedoQvj1y5WsNydXMwCYhCx3 czWYbrL3tb8h6VjOMfEEOi1LFyV7hNIvaKt4I4WRw+8HMC6kLRTvoJf0JB8Ikj0s JZ9whO481K6H6WhxNYSx+/VrOUsX986LNXqnsEbhGhrEq3OJsBgF5Tmfy068PqbX OlzVDJP8wNpriauFpKDLrB/KKvQKnFEbEEcJ9rXJs799+3URkOZ7e63Cw9wN1Ie4 30kaGCt+qNQswV2WAKaJz9wJQATO2TVb+Cf/fA2XKzGpCDCR1wC3dJo2Tk4RW7q8 QJJ72TpZEGr/b4V67MSbKZhN28MQnzIIeKp+0105n2Bvjwomof6Lz7c2RMD9+YJQ K8RYyBD5K6eQqoOn3+9aWTjPPYLy6zquoQV5bWiVmasBs9VdiuhSpdlNbKL8D9Ot rkYuz9QhlSTxftQPbSVkIV8xxhQJlhHkXYCd+pXhSCPJ7VeqhPHmz8gnDj4v6RAJ oBDvxLpaNySoh970rf5yIQhJATTCMwZyxEZlQ2rI+HUg9VrnVUlT/hRnPMFwYZml fFIxarosofRPMdiBIVta =tRxc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.54 - Session invalidate broken in some apps
On Thu, May 29, 2014 at 8:51 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-05-29 11:58 GMT+04:00 David Rees dree...@gmail.com: I've found that certain applications will no longer invalidate sessions after upgrading from 7.0.53 to 7.0.54. It seems to require clustering to be set up in Tomcat. If it's not set up, session invalidation works fine. So far, I can only trigger it in a webapp that uses Tapestry Spring Security. I see a few changes in the changelog related to session invalidate and clustering, could one of these changes be responsible? What are the symptoms? The symptoms are that you expect the current session to be invalidated and issued a new session on subsequent requests, but instead the session remains valid and all data in the session remains. Is there anything unusual in the log files? Nothing in the logs as far as I can tell. Is a single web application affected, or it spans several applications (via Single Sign On)? Only a single web application affected. You may consider debugging. http://wiki.apache.org/tomcat/FAQ/Developing#Debugging You may consider simplifying you configuration to build a simple reproduce scenario for a bug report. Yes, those are my next steps, just haven't gotten that far yet and wanted to see if anyone else was seeing anything similar. Thanks Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet question
ok thanks guys, I just got freaked out when I saw that post. On Thu, May 29, 2014 at 3:10 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 5/29/14, 2:45 PM, David kerber wrote: On 5/29/2014 2:21 PM, Elias Kopsiaftis wrote: oh yea, im on tomcat 7 btw Then why are you asking about a problem in a very old version of Tomcat 6? +1 Also, that web site looks like a scraping site that steals content from some other site like StackOverflow, Nabble, etc. The question isn't even complete it cuts off in the middle. Errors of this kind are usually due to a problem in the application, but there have been some edge cases found over the last few years and patched. You should make sure you are using the most up-to-date patch version of Tomcat in your release line. If you are using Tomcat 7, you want to make sure you are using Tomcat 7.0.54 which was just recently released and includes a few security updates. As for a technology for the future, you should dump Comet: the world is standardizing on Websocket. Java EE now includes a Websocket API, so you'll be able to deploy Websocket-based web applications on any compliant container instead of tying yourself to the Tomcat-specific Comet implementation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh4YUAAoJEBzwKT+lPKRYGG4QAMta8eJb8vCRFz/+JKLxLmja Ufeklv7CL1W+UDcljU/0t9YuWk1pfGiXRn2ORgLDuZUee69Eb2c959z4owpMaEiX ctqWTre1qA7sYCuQkBHehsOP4ohGYnhvndFeqJEMHedoQvj1y5WsNydXMwCYhCx3 czWYbrL3tb8h6VjOMfEEOi1LFyV7hNIvaKt4I4WRw+8HMC6kLRTvoJf0JB8Ikj0s JZ9whO481K6H6WhxNYSx+/VrOUsX986LNXqnsEbhGhrEq3OJsBgF5Tmfy068PqbX OlzVDJP8wNpriauFpKDLrB/KKvQKnFEbEEcJ9rXJs799+3URkOZ7e63Cw9wN1Ie4 30kaGCt+qNQswV2WAKaJz9wJQATO2TVb+Cf/fA2XKzGpCDCR1wC3dJo2Tk4RW7q8 QJJ72TpZEGr/b4V67MSbKZhN28MQnzIIeKp+0105n2Bvjwomof6Lz7c2RMD9+YJQ K8RYyBD5K6eQqoOn3+9aWTjPPYLy6zquoQV5bWiVmasBs9VdiuhSpdlNbKL8D9Ot rkYuz9QhlSTxftQPbSVkIV8xxhQJlhHkXYCd+pXhSCPJ7VeqhPHmz8gnDj4v6RAJ oBDvxLpaNySoh970rf5yIQhJATTCMwZyxEZlQ2rI+HUg9VrnVUlT/hRnPMFwYZml fFIxarosofRPMdiBIVta =tRxc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Elias, On 5/29/14, 3:12 PM, Elias Kopsiaftis wrote: ok thanks guys, I just got freaked out when I saw that post. There are other things that might freak you out. Read the security statements for Tomcat 7, for instance, and decide if you are at the right patch level. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh4ccAAoJEBzwKT+lPKRYLSUP/ibTnQzEkEyJery1gcYNPR3Z XkTuC00K4raPfa2GV/CBjqJq30LNxmMLShi0B+QMsmij4yOmwQCgpqpWYYt0dpmb LACEM61MaLCvnnfUCM0xdsw3QcynjqafXyRWm0MyZYp3+mt+lULjyfJsQ/u+1mp7 UlMrAKC1zNVh5abVDM1v+hTI1c9LE+Xx/rAujpFBLk8U5iJ4B7qwmRztdYcciLpn j9m5JdMdv4PSZ2hHPQKsefJzNrsojGGMzU4pbmQk/bvDaWRCZd60fo+d8k6sPZzY oMPUTXxwuSyzn+rXtWqhiof98SqIcmYPzrRDvZhZi/4WCMVnnyIir0yFNNDhZnjc H+7INzSDJtH3P/Vg7uYpNXoagPmH2veZtGl85QHpczzRlTOeJeO/Y6KMefkaRodq 33b2KjYOoWdatde35YWaPn2CK+eGEtMuwWKkWrzoVNvtgUG3yKXPodSkqhhCp3LT Ir04OAj60uhcD3yLSNuer/tGAziL0mMhk7zyTeAXpmRTvE/Ff7YKTkbKG33YIMJN rUa7KKMvx9mq+AYocmkQEyqiMFuFGr07neQOeAKusLJuKiuOzhTZ7HOJtgJf3n0K MkQE94Zk1tRlmbKw4onoNnh83ZFk7fpnqs7MsJuirZNdd6UFZvutmcLLqlZn0TMB EXnhj0NWDDs9NCA+IMtj =bQcf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Elias, On 5/29/14, 3:08 PM, Elias Kopsiaftis wrote: To make sure it doesnt exist in Tomcat7. Thats why. Ive never looked into the tomcat source code and theres no point for my current project unless this bug still exists. Just trying to save myself the work. Also, I couldnt find a page of known tomcat7 comet issues. If such a page existed it would be helpful Check Bugzilla. Anything logged and not fixed is known, I suppose. Also check the changelogs. Feel free to check everything between Tomat 6.0.33 and Tomcat 7.0.54, but that's a lot of reading. Are you actually having a problem, or are you just scared of what might be out there? To my knowledge, there are no proofs that Tomcat has zero flaws. Therefore, it could potentially serve every response to the wrong client. Experience says that does not happen. Common sense also tells you that, because nobody would use Tomcat if it was so horribly broken. There have been related bugs in the past that have been fixed when found. If you think you have found one, please report it with as much information as you can. But if you are just asking if there is a known problem with Tomcat where responses go to the wrong client, the answer is no: if we knew about a problem, we'd fix it and roll a new release. - -chris On Thu, May 29, 2014 at 2:45 PM, David kerber dcker...@verizon.net wrote: On 5/29/2014 2:21 PM, Elias Kopsiaftis wrote: oh yea, im on tomcat 7 btw Then why are you asking about a problem in a very old version of Tomcat 6? On Thu, May 29, 2014 at 2:13 PM, Elias Kopsiaftis yemi...@gmail.com wrote: Hey guys, I found this on the web, and it really alarms me because my web app which is in development depends on Comet technology to work. http://bighow.net/4294974-Comet_under_Tomcat_6_0_33_ sends_data_to_a_wrong_user.html Before I start digging into the tomcat7 source code, can anyone verify or contest the issue on that site? If Comet is not 100% dependable, how about WebSockets as an alternative? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh4btAAoJEBzwKT+lPKRYhvgQAMO2/TysR56uWeAo3nDRiJZP 2R9Q26t0UmAVqbUfujs0VtCGTySv6LKCHgbG6I/XQotSbdeaWY9jIZphqpLxylLV T24WqIFAv2J4ZLsx/W09pXMqvErVnp0kuesaFnEj4ooOfqATRTG0oscgQxy6Qrtb kzoOHYxG8c0/T/RnvNF+97F3ybRdwpW4U2TwLvtMYCw6H9MSzUPRJLdSIbnA4oS2 Bf7OcVoHCJ/53ODDuUfTpFXZgEucNmq58HHRaV0TYBQjIv1GwMMe889MWrfIQzuO rmHbXqORb/tRTZeV2DxPZ2t3AS0qU6K1qz4SDX91jngMJg9Uclvh8iW5pSi8K5y9 a9ZGoB4nVX9vZlkLwazfHfvUXwFVfzqZL9yYaSc7cT8EGf/47KV/xjRombdKyw18 /M4pNEBrD+hOqKKB24J3u6v1aGuz6ffUZ8io94bAGNm+Nq86+cL45PxQ49pkyVIk T7FQbM/NDgNJVRdByHalPlPyFtvC4d6mpU+yG9ryyESy1yCyMx9ojNTA/gt0IJ40 CZdqnPkEAsrzIadRYi/2n3eTQFrABHmH+jfh1ShzxLsd96mxz7GC1DM26yoJq/ok ckiEY0zY058Csp1NafRoSKbDSQ48pkvBvF0eccym3fCZwknA22a9iuZ9eRkLXbdO NxKin3hu9RQlMzCC1jmI =yrsV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.54 - Session invalidate broken in some apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 5/29/14, 3:12 PM, David Rees wrote: On Thu, May 29, 2014 at 8:51 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-05-29 11:58 GMT+04:00 David Rees dree...@gmail.com: I've found that certain applications will no longer invalidate sessions after upgrading from 7.0.53 to 7.0.54. It seems to require clustering to be set up in Tomcat. If it's not set up, session invalidation works fine. So far, I can only trigger it in a webapp that uses Tapestry Spring Security. I see a few changes in the changelog related to session invalidate and clustering, could one of these changes be responsible? What are the symptoms? The symptoms are that you expect the current session to be invalidated and issued a new session on subsequent requests, but instead the session remains valid and all data in the session remains. Do you mean that you have a web application that does this: session.invalidate(); session = request.getSession(true); ... and the old session is in fact not invalidated? Is there anything unusual in the log files? Nothing in the logs as far as I can tell. Is a single web application affected, or it spans several applications (via Single Sign On)? Only a single web application affected. You may consider debugging. http://wiki.apache.org/tomcat/FAQ/Developing#Debugging You may consider simplifying you configuration to build a simple reproduce scenario for a bug report. Yes, those are my next steps, just haven't gotten that far yet and wanted to see if anyone else was seeing anything similar. Please demonstrate that the session is in fact not validated. Given your description, if this is really happening, it should be trivial to create a test-case. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh4eHAAoJEBzwKT+lPKRYaggP/1+ImY4rFsro1aA0Rc6LeTWE SV0wm/Ic7Elux15nr9wWFHDPi1k6RhpLp1TcI9RS8dpw0sXMjMjg2iMjZQn2+ETe 7gr3nI8vnzz6lYcnPmI9ckC0nOXB5J/1UcdE7M8P/tmKmYhZBXX1PdvIx5mwkowH YojmXzmtt8GfFAfuux0xv5RgcfpXbz9VmjSmfZxD6zlIuoa0pxkYHgNGKsFatMYd vK8yDUsBd+yOHRFMev6iO1XrePNRa8xOtwfKYeDQQ/kQNB1pqW0tQ2jJ1+NSMbVc WWM1SgS44NFatrQgUqX0uMKM2q8Jx57CnSlXGrk0yIiGMcOp+egXt1i8XTSdY92f gxHbwfkmz7U/dGztnjQxSAjerNFGFS8puaCHW6Ot5EThT9MQDytYkhwcFAqK3Zmg R1zqPj+MYQb8IBDQ1HaV57d0xhLFErriCPShsb9dH9Hubo77DOPUc3TkdLJJ9f4C eq+dyCO/Rt4JQEu5myWJsQAczZoZoFQYm3QOhaTNMxq/KzQ5ZDcfwmIpF4J8wWtM 0SFoqTYVQAFCYUHBNDgro+F3TpA55dwhTofOk3h4DcmDPAXucq7aq2cs5+FIiQS3 7MHDkDPPQr4gI+mGVPIZRGrUbpQ54+EhNUYga722knkaxDzkP9UxW5kix63bEDck Pdbe3wXdaaO3ZRms0kGf =/iQW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.54 - Session invalidate broken in some apps
On Thu, May 29, 2014 at 12:16 PM, Christopher Schultz ch...@christopherschultz.net wrote: Do you mean that you have a web application that does this: session.invalidate(); session = request.getSession(true); ... and the old session is in fact not invalidated? Yes. Specifics to make this happen seem to be: TC 7.0.54 in a cluster, Tapestry 5.2.6 + Tapestry Spring Security. 7.0.53 is OK. 7.0.54 standalone is OK Tapestry App without spring security is OK. Plain old servlet apps work fine. Please demonstrate that the session is in fact not validated. Given your description, if this is really happening, it should be trivial to create a test-case. Yes, just haven't had the time yet. -Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: comet question
I am having random errors, but we are still looking into them because right now we think they are probably from our end. The current one is that the connection from the client to the comet servlet will randomly repeatedly receive NULL. Still looking into this to see what the server is doing On Thu, May 29, 2014 at 3:13 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Elias, On 5/29/14, 3:08 PM, Elias Kopsiaftis wrote: To make sure it doesnt exist in Tomcat7. Thats why. Ive never looked into the tomcat source code and theres no point for my current project unless this bug still exists. Just trying to save myself the work. Also, I couldnt find a page of known tomcat7 comet issues. If such a page existed it would be helpful Check Bugzilla. Anything logged and not fixed is known, I suppose. Also check the changelogs. Feel free to check everything between Tomat 6.0.33 and Tomcat 7.0.54, but that's a lot of reading. Are you actually having a problem, or are you just scared of what might be out there? To my knowledge, there are no proofs that Tomcat has zero flaws. Therefore, it could potentially serve every response to the wrong client. Experience says that does not happen. Common sense also tells you that, because nobody would use Tomcat if it was so horribly broken. There have been related bugs in the past that have been fixed when found. If you think you have found one, please report it with as much information as you can. But if you are just asking if there is a known problem with Tomcat where responses go to the wrong client, the answer is no: if we knew about a problem, we'd fix it and roll a new release. - -chris On Thu, May 29, 2014 at 2:45 PM, David kerber dcker...@verizon.net wrote: On 5/29/2014 2:21 PM, Elias Kopsiaftis wrote: oh yea, im on tomcat 7 btw Then why are you asking about a problem in a very old version of Tomcat 6? On Thu, May 29, 2014 at 2:13 PM, Elias Kopsiaftis yemi...@gmail.com wrote: Hey guys, I found this on the web, and it really alarms me because my web app which is in development depends on Comet technology to work. http://bighow.net/4294974-Comet_under_Tomcat_6_0_33_ sends_data_to_a_wrong_user.html Before I start digging into the tomcat7 source code, can anyone verify or contest the issue on that site? If Comet is not 100% dependable, how about WebSockets as an alternative? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTh4btAAoJEBzwKT+lPKRYhvgQAMO2/TysR56uWeAo3nDRiJZP 2R9Q26t0UmAVqbUfujs0VtCGTySv6LKCHgbG6I/XQotSbdeaWY9jIZphqpLxylLV T24WqIFAv2J4ZLsx/W09pXMqvErVnp0kuesaFnEj4ooOfqATRTG0oscgQxy6Qrtb kzoOHYxG8c0/T/RnvNF+97F3ybRdwpW4U2TwLvtMYCw6H9MSzUPRJLdSIbnA4oS2 Bf7OcVoHCJ/53ODDuUfTpFXZgEucNmq58HHRaV0TYBQjIv1GwMMe889MWrfIQzuO rmHbXqORb/tRTZeV2DxPZ2t3AS0qU6K1qz4SDX91jngMJg9Uclvh8iW5pSi8K5y9 a9ZGoB4nVX9vZlkLwazfHfvUXwFVfzqZL9yYaSc7cT8EGf/47KV/xjRombdKyw18 /M4pNEBrD+hOqKKB24J3u6v1aGuz6ffUZ8io94bAGNm+Nq86+cL45PxQ49pkyVIk T7FQbM/NDgNJVRdByHalPlPyFtvC4d6mpU+yG9ryyESy1yCyMx9ojNTA/gt0IJ40 CZdqnPkEAsrzIadRYi/2n3eTQFrABHmH+jfh1ShzxLsd96mxz7GC1DM26yoJq/ok ckiEY0zY058Csp1NafRoSKbDSQ48pkvBvF0eccym3fCZwknA22a9iuZ9eRkLXbdO NxKin3hu9RQlMzCC1jmI =yrsV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.54 - Session invalidate broken in some apps
On Thu, May 29, 2014 at 12:39 PM, David Rees dree...@gmail.com wrote: Yes. Specifics to make this happen seem to be: TC 7.0.54 in a cluster, Tapestry 5.2.6 + Tapestry Spring Security. OK, I was wrong, no Tapestry or Spring Security is required, just a couple JSPs are required to reproduce. Key is that clustering needs to be enabled. Drop these two JSP files into your 7.0.54 cluster enabled web app. /** session.jsp **/ %@page session=true% html body table trtdSession creation time:/tdtd%= session.getCreationTime() %/td/tr trtdSession last accessed:/tdtd%= session.getLastAccessedTime() %/td/tr trtdCurrent time:/tdtd%= System.currentTimeMillis() %/td/tr trtdIs Session Id from URL?:/tdtd%= request.isRequestedSessionIdFromURL() %/td/tr trtda href=session.jspReload Page/a/tdtda href=invalidate.jspInvalidate/a/td/tr /table /body /html /** invalidate.jsp **/ % request.getSession().invalidate(); response.sendRedirect(session.jsp); % Make sure Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster/ is added to the Host of the webapp you dropped the files above into. Clicking on Reload Page will show the same creation time. On a 7.0.53 if you click on Invalidate, you will get a new creation time. On 7.0.54, you do not. I'll open a ticket with these details, too. -Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.54 - Session invalidate broken in some apps
On Thu, May 29, 2014 at 6:16 PM, David Rees dree...@gmail.com wrote: I'll open a ticket with these details, too. https://issues.apache.org/bugzilla/show_bug.cgi?id=56578 -Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
