You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "at.silk" <at...@everis.com> on 2013/12/03 11:25:23 UTC
Exception in CoyoteAdapter class
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"/>
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.
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?
Thanks and kind regards,
AT silk.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Exception in CoyoteAdapter class
Posted by Mark Thomas <ma...@apache.org>.
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:markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Exception in CoyoteAdapter class
Posted by "at.silk" <at...@everis.com>.
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:markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Exception in CoyoteAdapter class
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Exception in CoyoteAdapter class
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Exception in CoyoteAdapter class
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Exception in CoyoteAdapter class
Posted by Martin Gainty <mg...@hotmail.com>.
Señor AT
Martín>puerto y el protocolo tienen que estar de acuerdo con la configuración del conector AJP en tomcat server.xml
Martín>El puerto debe ser 8009
Martín>Habilitar el protocolo TLS (pero no SSLv2)
http://www.zeitoun.net/articles/configure-mod_proxy_ajp-with-tomcat/start
Martín>Saludos Cordiales desde Dorchester MA
> From: at.silk@everis.com
> To: users@tomcat.apache.org
> Subject: RE: Exception in CoyoteAdapter class
> Date: Fri, 20 Dec 2013 08:30:19 +0000
>
> 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:chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��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
Posted by "at.silk" <at...@everis.com>.
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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Exception in CoyoteAdapter class
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Exception in CoyoteAdapter class
Posted by "at.silk" <at...@everis.com>.
Hi Konstantin,
My answers below.
AT.
2013/12/3 at.silk <at...@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-timeout>30</session-timeout>
<tracking-mode>SSL</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 between applications? Is 30 minutes the expiration time from single-sign-on (and not from webapp's session)?
AT: There is no any SSO. It seems the application is checking later than Tomcat its own timeout.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Exception in CoyoteAdapter class
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/12/3 at.silk <at...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org