RE: Exception in CoyoteAdapter class
Hi, We are concerned about the issues we found some weeks ago, do you have any suggestions about it? Best Regards, AT -Mensaje original- De: Christopher Schultz [mailto:ch...@christopherschultz.net] Enviado el: lunes, 09 de diciembre de 2013 22:51 Para: Tomcat Users List Asunto: Re: Exception in CoyoteAdapter class -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 AT, On 12/9/13, 6:43 AM, at.silk wrote: 2. What is in front of Tomcat? An Apache HTTPD server? - Right. Is Apache HTTPD accessed via HTTPS? - Right, via HTTPS How mod_jk is configured there? Is mod_jk configured to pass SSL_SESSION_ID to Tomcat? AT: This is our configuration: AllowCONNECT 443 SSLEngine on SSLProxyEngine on SSLProxyVerify none SSLOptions +StdEnvVars +ExportCertData SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile xxx.crt SSLCertificateKeyFile xxx.key ProxyPass / ajp://localhost:8010/ connectiontimeout=3600 timeout=3600 ProxyPassReverse / ajp://localhost:8010/ Note a note: this is a mod_proxy_ajp configuration, not a mod_jk one. I know that mod_jk uses SSLOptions +StdEnvVars to pass the SSL session id to Tomcat, but I'm sorry, I don't know about mod_proxy_ajp. I can imagine that it would operate in a similar way, but the mod_proxy_ajp documentation isn't as forthcoming as the mod_jk documentation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSpjtYAAoJEBzwKT+lPKRYbp4P/3xElIVs2K47Y/+ppay3Np/7 TyhYLXIdgUAvapRy6p8KC8okiAxgteNkPPtwxywQqR/LkM0mHeFtN3OFJe1MHl0D qJ3ZoyYEKbe+4bGuUm/SLX7YswSO+0nTsf9OGmi2XVZyCXff0faxZFSZ2N1hW+0y 4+J1eLcG+yHAkaN9JSsSHYx+M9hKoMz4ZXIohnB1zfvD1iroSoBpPPlbdl0BXBaa /b6yNjFfpgqxojiCdP8/eA2/Tdd5+p9aNwUWAYiq3vMME6+oDuYMghQifK1pIbzP ezgF4/IObA8y1Zhavnw2hA3ZjtNcXauzSmF9iTxlDQaEhjVeiAtwAv+yrXyhQB6/ J1pc/1DpVTsA+7j/JEGKhpna8W0G6aJc7iIFoqu5g36bHEoZbNDlnLZDE2kZrSda q1zjIklRhmiA1lEqh8tW4N1ushBgkJpQp2PZx5ZNqsvbrr3djbFHSkXUKgus3VsS czdD7vuhGsHX8ER/c3/KD59TF7IDUcjluJWyQRhoc2P+S0xTtDMTHDLvx4WXwLm1 ZU3+pzR/MAoCI0kesq5NxR4lewyT3n9MW3nD62sO1h9ieqoOuhQ8eRqxSpBTsZZH Sy+GorGhXiZmdr02llagtHrdiexrY84oPzTioIPkQ8/C9TlR7zDaxpPE39HjILkd r8ajstixh1CbE3sC2h1C =hEow -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception in CoyoteAdapter class
at.silk wrote: Hi, We are concerned about the issues we found some weeks ago, do you have any suggestions about it? Maybe : your configuration does not seem to make sense. (or it works differently from what you think, or we do not understand what you are telling us) From the history of this thread, it seems so far that you are reporting an issue that should not be possible given the other information that you have provided. So you have got everyone confused. Maybe some facts first : 1) The AJP protocol does NOT support SSL/HTTPS. AJP is its own protocol, different from HTTP/HTTPS. It is used exclusively between a front-end HTTP/HTTPS webserver, and a back-end Tomcat server. It transports or forwards HTTP/HTTPS requests (including HTTP/HTTPS headers and SSL-specific information) between the front-end webserver and the back-end Tomcat, but the format in which it transports this information is not the same as HTTP/HTTPS. And it is always unencrypted. 2) Implementing AJP requires 2 things : a) on the back-end Tomcat server : - a functional AJP Connector b) on the front-end webserver (e.g. Apache httpd) : - a proxy add-on module which is capable to talk to the AJP Connector of a back-end Tomcat For Apache httpd, there exist 2 such add-on modules : - mod_jk - mod_proxy_ajp 3) the AJP protocol is unknown to browsers, and a browser cannot connect directly to a Tomcat AJP Connector. 4) a browser can connect directly to a Tomcat HTTP or HTTPS Connector. In other words, in your case, the connection between browsers and a Tomcat webapp could be (using Apache as an abbreviation for a front-end Apache httpd webserver) : browser --HTTP-- Apache + mod_proxy_ajp --AJP-- Tomcat + AJP Connector - webapp OR browser --HTTP-- Apache + mod_jk --AJP-- Tomcat + AJP Connector - webapp OR browser --HTTPS-- Apache + mod_proxy_ajp --AJP-- Tomcat + AJP Connector - webapp OR browser --HTTPS-- Apache + mod_jk --AJP-- Tomcat + AJP Connector - webapp OR browser --HTTP-- Tomcat + HTTP Connector - webapp OR browser --HTTPS-- Tomcat + HTTPS Connector - webapp but, with the information that you have provided so far, it is not clear to the people on this list which of the above schemas you are using, or if you are even using one of the above. So I believe that you should make that clear first, and after that maybe someone can help you answer your questions. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Exception in CoyoteAdapter class
Señor AT Martínpuerto y el protocolo tienen que estar de acuerdo con la configuración del conector AJP en tomcat server.xml MartínEl puerto debe ser 8009 MartínHabilitar el protocolo TLS (pero no SSLv2) http://www.zeitoun.net/articles/configure-mod_proxy_ajp-with-tomcat/start MartínSaludos Cordiales desde Dorchester MA From: at.s...@everis.com To: users@tomcat.apache.org Subject: RE: Exception in CoyoteAdapter class Date: Fri, 20 Dec 2013 08:30:19 + Hi, We are concerned about the issues we found some weeks ago, do you have any suggestions about it? Best Regards, AT -Mensaje original- De: Christopher Schultz [mailto:ch...@christopherschultz.net] Enviado el: lunes, 09 de diciembre de 2013 22:51 Para: Tomcat Users List Asunto: Re: Exception in CoyoteAdapter class -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 AT, On 12/9/13, 6:43 AM, at.silk wrote: 2. What is in front of Tomcat? An Apache HTTPD server? - Right. Is Apache HTTPD accessed via HTTPS? - Right, via HTTPS How mod_jk is configured there? Is mod_jk configured to pass SSL_SESSION_ID to Tomcat? AT: This is our configuration: AllowCONNECT 443 SSLEngine on SSLProxyEngine on SSLProxyVerify none SSLOptions +StdEnvVars +ExportCertData SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile xxx.crt SSLCertificateKeyFile xxx.key ProxyPass / ajp://localhost:8010/ connectiontimeout=3600 timeout=3600 ProxyPassReverse / ajp://localhost:8010/ Note a note: this is a mod_proxy_ajp configuration, not a mod_jk one. I know that mod_jk uses SSLOptions +StdEnvVars to pass the SSL session id to Tomcat, but I'm sorry, I don't know about mod_proxy_ajp. I can imagine that it would operate in a similar way, but the mod_proxy_ajp documentation isn't as forthcoming as the mod_jk documentation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSpjtYAAoJEBzwKT+lPKRYbp4P/3xElIVs2K47Y/+ppay3Np/7 TyhYLXIdgUAvapRy6p8KC8okiAxgteNkPPtwxywQqR/LkM0mHeFtN3OFJe1MHl0D qJ3ZoyYEKbe+4bGuUm/SLX7YswSO+0nTsf9OGmi2XVZyCXff0faxZFSZ2N1hW+0y 4+J1eLcG+yHAkaN9JSsSHYx+M9hKoMz4ZXIohnB1zfvD1iroSoBpPPlbdl0BXBaa /b6yNjFfpgqxojiCdP8/eA2/Tdd5+p9aNwUWAYiq3vMME6+oDuYMghQifK1pIbzP ezgF4/IObA8y1Zhavnw2hA3ZjtNcXauzSmF9iTxlDQaEhjVeiAtwAv+yrXyhQB6/ J1pc/1DpVTsA+7j/JEGKhpna8W0G6aJc7iIFoqu5g36bHEoZbNDlnLZDE2kZrSda q1zjIklRhmiA1lEqh8tW4N1ushBgkJpQp2PZx5ZNqsvbrr3djbFHSkXUKgus3VsS czdD7vuhGsHX8ER/c3/KD59TF7IDUcjluJWyQRhoc2P+S0xTtDMTHDLvx4WXwLm1 ZU3+pzR/MAoCI0kesq5NxR4lewyT3n9MW3nD62sO1h9ieqoOuhQ8eRqxSpBTsZZH Sy+GorGhXiZmdr02llagtHrdiexrY84oPzTioIPkQ8/C9TlR7zDaxpPE39HjILkd r8ajstixh1CbE3sC2h1C =hEow -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org B�CB�� [��X��ܚX�KK[XZ[� \�\��][��X��ܚX�P �X�] �\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[� \�\��Z[ �X�] �\X�K�ܙ�B�
Re: Exception in CoyoteAdapter class
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/20/13, 4:59 AM, André Warnier wrote: Maybe : your configuration does not seem to make sense. (or it works differently from what you think, or we do not understand what you are telling us) From the history of this thread, it seems so far that you are reporting an issue that should not be possible given the other information that you have provided. So you have got everyone confused. +1 Maybe some facts first : 1) The AJP protocol does NOT support SSL/HTTPS. AJP is its own protocol, different from HTTP/HTTPS. It is used exclusively between a front-end HTTP/HTTPS webserver, and a back-end Tomcat server. It transports or forwards HTTP/HTTPS requests (including HTTP/HTTPS headers and SSL-specific information) between the front-end webserver and the back-end Tomcat, but the format in which it transports this information is not the same as HTTP/HTTPS. And it is always unencrypted. +1 Most connectors (mod_jk, mod_proxy_ajp) are capable of transmitting important information about the HTTPS connection to the back-end... specifically, you can get the client certificate chain, key length and cipher, etc. but, with the information that you have provided so far, it is not clear to the people on this list which of the above schemas you are using, or if you are even using one of the above. So I believe that you should make that clear first, and after that maybe someone can help you answer your questions. +1 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJStKBzAAoJEBzwKT+lPKRYRiIP/0Gri2GHfn9J2z9ItP2fEwkS CQXZRkeGlfrb7YejChWYgescz6rDElW4qi7r/IRxOEhr9p/1toLfcXCFOQv1+nXR CuG3vm7vYjSK3VFVOV257UuhA6SIh5P3+4ceu3FgMrXdO1MpVCNaJgJehVUZCugv M1UggnOkeODmSC6g7XpwuesIvziH8HyzdSzcClTHsRbCvrFxlk59DPUKquqEFjLj mY554nGuNE0FPRsoiQKz9XgioMasp9yAXmKEgXfn7RmCHfbOhiNfycqWJRtYf9XB VWLfjC4QSVIbHxVYzQaqsbsQvCqIb5Z7tAiWFelhiCUA++u/ANz+H+IYUcYIWKAZ 7p1jPRPHrAKqOE/BBk1GSjAcg3vo0dqsJE5AKW15pvreZ6CbxeLi5wlji7PVC+/8 hBIbXBN7TimhvCU8PRbs1xUpLrRWeG2r5b+kATMCZt1oTBPd4XxRG+1StexoUw59 Phc6/UzJhNZQFYqRwzIzDrZOY8Db3K+qNw+3NU5aD6RY16M2In/A77e+MicPjO/4 sUN9AYbtLxbPjgod1OeGzV2yLN6QOVls5s+gPXQGAyP3yD4cOIhWDzUHNaWs4EUR F5Fzis3A/nJALhsNPObb5jWC8DUTkGgqLZWQldXxrYQhXDjxthnyjrbJbohqnOTR GTTfHSVzYQ3KMQJOFKNM =PPMJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Exception in CoyoteAdapter class
Hi Konstantin, My answers below. AT. 2013/12/3 at.silk at.s...@everis.com: Hi, I contact you to talk about an exception we receive in a Tomcat class. Few days ago we get an error in an application integrated with Tomcat. We have tried to get information about it but we don't find any solution, so we would like to know if you are aware about this issue. First we describe our scenario: 1. User logs in the portal and remain static for more than 30 minutes (30 minutes is session expiration time). 2. Afterwards, he refreshes the webpage and session has been expired. 3. During the page reloading, an error occurs while executing the parseSessionSslId method because the SSLSupport.SESSION_ID_KEY is empty. 4. A blank page is displayed because the error is not caught. The exception produced during step 3 belongs to this section: [org\apache\catalina\connector\CoyoteAdapter.java] Method parseSessionSslId: request.setRequestedSessionId(request.getAttribute(SSLSupport.SESSION_ID_KEY).toString()); request.setRequestedSessionSSL(true); This is our context: - Tomcat version: 7.0.25 - OS: Linux distribution - Liferay 6.1GA1 portal integrated with Tomcat - We don't negotiate user session by the sessionid with the cookie but with the certificate. Our server.xml configuration file contains the following connectors: Connector URIEncoding=UTF-8 port=8010 protocol=AJP/1.3 redirectPort=8443 scheme=https secure=true / Connector URIEncoding=UTF-8 port=8443 protocol=HTTP/1.1 SSLEnabled=true clientAuth=false keystoreFile=xxx keystorePass=yyy keystoreType=PKCS12 maxThreads=150 scheme=https secure=true sslProtocol=TLS/ 1. Is Tomcat accessed via AJP or HTTPS ? AT: Tomcat is accessed via AJP: Connector URIEncoding=UTF-8 port=8010 protocol=AJP/1.3 redirectPort=8443 scheme=https secure=true / Connector URIEncoding=UTF-8 port=8443 protocol=HTTP/1.1 SSLEnabled=true clientAuth=false keystoreFile=xxx keystorePass=yyy keystoreType=PKCS12 maxThreads=150 scheme=https secure=true sslProtocol=TLS/ 2. What is in front of Tomcat? An Apache HTTPD server? - Right. Is Apache HTTPD accessed via HTTPS? - Right, via HTTPS How mod_jk is configured there? Is mod_jk configured to pass SSL_SESSION_ID to Tomcat? AT: This is our configuration: AllowCONNECT 443 SSLEngine on SSLProxyEngine on SSLProxyVerify none SSLOptions +StdEnvVars +ExportCertData SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile xxx.crt SSLCertificateKeyFile xxx.key ProxyPass / ajp://localhost:8010/ connectiontimeout=3600 timeout=3600 ProxyPassReverse / ajp://localhost:8010/ 3. How session-config is configured in WEB-INF/web.xml of your web applications and in the shared $CATALINA_BASE/conf/web.xml file? I expect that you have tracking-mode configured in one of those files. session-config session-timeout30/session-timeout tracking-modeSSL/tracking-mode /session-config Are you able to identify what web application is being requested here? (E.g. by looking into the access log)? There is just one web application accessing there. Conclusion: The exception is raised when the session id is empty due to we have an expired session. We have compiled this code section with a try catch and now our application does not receive the error, and we can see our page displayed, obviously with session expired. 4. A full stacktrace = ? java.lang.NullPointerException at org.apache.catalina.connector.CoyoteAdapter.parseSessionSslId(CoyoteAdapter.java:894) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:689) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:402) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Do you think this could be due to some local configuration or is it a general issue? Is there the possibility to contemplate this case to be protected when sessionId is null? If an application is configured to use ssl session as its session identifier, and no ssl session is available, how do you expect it to behave? I looks that one adds a try/catch there, the application will create a new session with every request. Are you OK with that? AT: If there is not already an active session I would agree with creating a new session just for this situation. 5. I do not see how 30 minutes can come into a play here. With my guesses above an application should have failed with the first request. Is some form of single-sign-on configured
Re: Exception in CoyoteAdapter class
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 AT, On 12/9/13, 6:43 AM, at.silk wrote: 2. What is in front of Tomcat? An Apache HTTPD server? - Right. Is Apache HTTPD accessed via HTTPS? - Right, via HTTPS How mod_jk is configured there? Is mod_jk configured to pass SSL_SESSION_ID to Tomcat? AT: This is our configuration: AllowCONNECT 443 SSLEngine on SSLProxyEngine on SSLProxyVerify none SSLOptions +StdEnvVars +ExportCertData SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile xxx.crt SSLCertificateKeyFile xxx.key ProxyPass / ajp://localhost:8010/ connectiontimeout=3600 timeout=3600 ProxyPassReverse / ajp://localhost:8010/ Note a note: this is a mod_proxy_ajp configuration, not a mod_jk one. I know that mod_jk uses SSLOptions +StdEnvVars to pass the SSL session id to Tomcat, but I'm sorry, I don't know about mod_proxy_ajp. I can imagine that it would operate in a similar way, but the mod_proxy_ajp documentation isn't as forthcoming as the mod_jk documentation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSpjtYAAoJEBzwKT+lPKRYbp4P/3xElIVs2K47Y/+ppay3Np/7 TyhYLXIdgUAvapRy6p8KC8okiAxgteNkPPtwxywQqR/LkM0mHeFtN3OFJe1MHl0D qJ3ZoyYEKbe+4bGuUm/SLX7YswSO+0nTsf9OGmi2XVZyCXff0faxZFSZ2N1hW+0y 4+J1eLcG+yHAkaN9JSsSHYx+M9hKoMz4ZXIohnB1zfvD1iroSoBpPPlbdl0BXBaa /b6yNjFfpgqxojiCdP8/eA2/Tdd5+p9aNwUWAYiq3vMME6+oDuYMghQifK1pIbzP ezgF4/IObA8y1Zhavnw2hA3ZjtNcXauzSmF9iTxlDQaEhjVeiAtwAv+yrXyhQB6/ J1pc/1DpVTsA+7j/JEGKhpna8W0G6aJc7iIFoqu5g36bHEoZbNDlnLZDE2kZrSda q1zjIklRhmiA1lEqh8tW4N1ushBgkJpQp2PZx5ZNqsvbrr3djbFHSkXUKgus3VsS czdD7vuhGsHX8ER/c3/KD59TF7IDUcjluJWyQRhoc2P+S0xTtDMTHDLvx4WXwLm1 ZU3+pzR/MAoCI0kesq5NxR4lewyT3n9MW3nD62sO1h9ieqoOuhQ8eRqxSpBTsZZH Sy+GorGhXiZmdr02llagtHrdiexrY84oPzTioIPkQ8/C9TlR7zDaxpPE39HjILkd r8ajstixh1CbE3sC2h1C =hEow -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Exception in CoyoteAdapter class
Hi Mark, This is the application behaviour, and it only happens when the session has expired. I cannot say why this method is still called if there is no session at that time. We just can assure that the exception is triggered by this piece of code, since handling the exception inside this method leads to a correct execution. AT. -Mensaje original- De: Mark Thomas [mailto:ma...@apache.org] Enviado el: martes, 03 de diciembre de 2013 11:40 Para: Tomcat Users List Asunto: Re: Exception in CoyoteAdapter class On 03/12/2013 10:25, at.silk wrote: Hi, I contact you to talk about an exception we receive in a Tomcat class. Few days ago we get an error in an application integrated with Tomcat. We have tried to get information about it but we don't find any solution, so we would like to know if you are aware about this issue. First we describe our scenario: 1. User logs in the portal and remain static for more than 30 minutes (30 minutes is session expiration time). 2. Afterwards, he refreshes the webpage and session has been expired. 3. During the page reloading, an error occurs while executing the parseSessionSslId method because the SSLSupport.SESSION_ID_KEY is empty. 4. A blank page is displayed because the error is not caught. How is that possible? If there is no SSL session the client should not be able to send a request to Tomcat since that would mean that the HTTPS connection had not been established. Since this code is only triggered when parsing a request from the client this error should never be observed. Mark - 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: Exception in CoyoteAdapter class
On 04/12/2013 17:17, at.silk wrote: Hi Mark, This is the application behaviour, and it only happens when the session has expired. I cannot say why this method is still called if there is no session at that time. We just can assure that the exception is triggered by this piece of code, since handling the exception inside this method leads to a correct execution. Without an explanation of how this problem occurs, your patch will not be applied. We don't apply patches to fix problems we don't understand as more often then not that makes the problem worse not better. At best it would be fixing the symptom rather than the root cause and that is not helpful. Mark AT. -Mensaje original- De: Mark Thomas [mailto:ma...@apache.org] Enviado el: martes, 03 de diciembre de 2013 11:40 Para: Tomcat Users List Asunto: Re: Exception in CoyoteAdapter class On 03/12/2013 10:25, at.silk wrote: Hi, I contact you to talk about an exception we receive in a Tomcat class. Few days ago we get an error in an application integrated with Tomcat. We have tried to get information about it but we don't find any solution, so we would like to know if you are aware about this issue. First we describe our scenario: 1. User logs in the portal and remain static for more than 30 minutes (30 minutes is session expiration time). 2. Afterwards, he refreshes the webpage and session has been expired. 3. During the page reloading, an error occurs while executing the parseSessionSslId method because the SSLSupport.SESSION_ID_KEY is empty. 4. A blank page is displayed because the error is not caught. How is that possible? If there is no SSL session the client should not be able to send a request to Tomcat since that would mean that the HTTPS connection had not been established. Since this code is only triggered when parsing a request from the client this error should never be observed. Mark - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception in CoyoteAdapter class
2013/12/3 at.silk at.s...@everis.com: Hi, I contact you to talk about an exception we receive in a Tomcat class. Few days ago we get an error in an application integrated with Tomcat. We have tried to get information about it but we don't find any solution, so we would like to know if you are aware about this issue. First we describe our scenario: 1. User logs in the portal and remain static for more than 30 minutes (30 minutes is session expiration time). 2. Afterwards, he refreshes the webpage and session has been expired. 3. During the page reloading, an error occurs while executing the parseSessionSslId method because the SSLSupport.SESSION_ID_KEY is empty. 4. A blank page is displayed because the error is not caught. The exception produced during step 3 belongs to this section: [org\apache\catalina\connector\CoyoteAdapter.java] Method parseSessionSslId: request.setRequestedSessionId(request.getAttribute(SSLSupport.SESSION_ID_KEY).toString()); request.setRequestedSessionSSL(true); This is our context: - Tomcat version: 7.0.25 - OS: Linux distribution - Liferay 6.1GA1 portal integrated with Tomcat - We don't negotiate user session by the sessionid with the cookie but with the certificate. Our server.xml configuration file contains the following connectors: Connector URIEncoding=UTF-8 port=8010 protocol=AJP/1.3 redirectPort=8443 scheme=https secure=true / Connector URIEncoding=UTF-8 port=8443 protocol=HTTP/1.1 SSLEnabled=true clientAuth=false keystoreFile=xxx keystorePass=yyy keystoreType=PKCS12 maxThreads=150 scheme=https secure=true sslProtocol=TLS/ 1. Is Tomcat accessed via AJP or HTTPS ? 2. What is in front of Tomcat? An Apache HTTPD server? How mod_jk is configured there? Is Apache HTTPD accessed via HTTPS? Is mod_jk configured to pass SSL_SESSION_ID to Tomcat? http://tomcat.apache.org/connectors-doc/reference/apache.html SSLOptions +StdEnvVars JkExtractSSL On 3. How session-config is configured in WEB-INF/web.xml of your web applications and in the shared $CATALINA_BASE/conf/web.xml file? I expect that you have tracking-mode configured in one of those files. Are you able to identify what web application is being requested here? (E.g. by looking into the access log)? Conclusion: The exception is raised when the session id is empty due to we have an expired session. We have compiled this code section with a try catch and now our application does not receive the error, and we can see our page displayed, obviously with session expired. 4. A full stacktrace = ? Do you think this could be due to some local configuration or is it a general issue? Is there the possibility to contemplate this case to be protected when sessionId is null? If an application is configured to use ssl session as its session identifier, and no ssl session is available, how do you expect it to behave? I looks that one adds a try/catch there, the application will create a new session with every request. Are you OK with that? 5. I do not see how 30 minutes can come into a play here. With my guesses above an application should have failed with the first request. Is some form of single-sign-on configured between applications? Is 30 minutes the expiration time from single-sign-on (and not from webapp's session)? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception in CoyoteAdapter class
On 03/12/2013 10:25, at.silk wrote: Hi, I contact you to talk about an exception we receive in a Tomcat class. Few days ago we get an error in an application integrated with Tomcat. We have tried to get information about it but we don't find any solution, so we would like to know if you are aware about this issue. First we describe our scenario: 1. User logs in the portal and remain static for more than 30 minutes (30 minutes is session expiration time). 2. Afterwards, he refreshes the webpage and session has been expired. 3. During the page reloading, an error occurs while executing the parseSessionSslId method because the SSLSupport.SESSION_ID_KEY is empty. 4. A blank page is displayed because the error is not caught. How is that possible? If there is no SSL session the client should not be able to send a request to Tomcat since that would mean that the HTTPS connection had not been established. Since this code is only triggered when parsing a request from the client this error should never be observed. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
