Re: user self registration/account creation

[Alex O'Ree]

thanks i'll look into it

On Mon, Oct 7, 2019 at 3:36 AM Mark Thomas  wrote:

> On 06/10/2019 20:31, Alex O'Ree wrote:
> > i have a password protected web app and would like to provide users with
> > the ability to self register for a new account. looks like the easiest
> way
> > to do this with tomcat is with a jdbc realm to protect the web app and
> > anonymous access to the self registration app.
> >
> > a few questions on this.
> >
> > is there a pre made app that could be used for the user account creation
> > app? i'll probably need something for admins to revoke accounts, disable
> > accounts, edit role memberships etc. ugh, and then there is user password
> > resets and complexity requirements... some kind of captcha thing to
> prevent
> > bots. i also need to track and report to the user when a password
> expires,
> > last login ip address and user agent field. quite a bit of stuff to
> write.
> > if there is something available that is asf license compatible, i'd love
> to
> > hear about it.
>
> CAS:
> https://www.apereo.org/projects/cas
>
> I think CAS does everything you asked for.
>
> Spring Security is the other option that comes to mind but my
> understanding is that you'd need to build some of the management UIs
> yourself.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Bug in org.apache.tomcat.util.codec.binary.Base64.decodeBase64 ?

[Konstantin Kolinko]

ср, 9 окт. 2019 г. в 00:06, :
>
> How do we get access to the dev list for information around release 
> candidates, etc.?

In the same way as for the current (users) mailing list that you are writing to:
either subscribe or read past messages in an archive.
http://tomcat.apache.org/lists.html

And do not forget to follow the rules. They are the same as for the users list:
http://tomcat.apache.org/lists.html#tomcat-users
6. Top-posting is bad.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Bug in org.apache.tomcat.util.codec.binary.Base64.decodeBase64 ?

[jonmcalexander]

How do we get access to the dev list for information around release candidates, 
etc.?


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: Konstantin Kolinko  
Sent: Tuesday, October 8, 2019 5:26 AM
To: Tomcat Users List 
Subject: Re: Bug in org.apache.tomcat.util.codec.binary.Base64.decodeBase64 ?

вт, 8 окт. 2019 г. в 12:24, Arnaud Yahoo :
>
> Hello,
>
> I am using a 3rd party valve for OpenId Connect authentication that 
> stop working upgrading from tomcat 8.5.24 to 8.5.46
>
> I managed to isolate the issue behing this and it is caused by a 
> change in org.apache.tomcat.util.codec.binary.Base64
>
> It can be reproduce with a simple test case
>
> @Test
>  public void decodeBase64Test() {
>  String str =
> "YZJXP8zFDY6WPk1NZx4RtkH95lA4H_GM_XmFjouJImtqy-PD27-GUYVrCq1QM3M09TzRF
> ZTL4aMMTweZFj3h1M-4Pqb4xrRq9URICQ9ffpnB9OGKjEwEpzhICwbE8C8-zEbhFOEgdXc
> yeP0pJc9uHEUH9Z4rTEg0jxmOmffIAbX9zfjhIla0XUsFd2C2QQGXu1nTFrb2EqfhLDls4
> ZLCcnLZE6Be3SpHCtvZiFN4w3xlI0TZitX4S3SjTocK4Xobb3Ey0RnewDP6jw78JniFTbu
> uGB962GlHDJvaQoda2dON9j7Yhv_pTvxBlHDmIKYINYsBfTwEQ_qtLJtmcvv41Q";
>
> assertArrayEquals(org.apache.tomcat.util.codec.binary.Base64.decodeBas
> e64(str), java.util.Base64.getUrlDecoder().decode(str));
>  }
>
> This test is ok with 8.5.24 but fails with 8.5.46. Are there any known 
> issues with Base64 utility ?

Please test with 8.5.47 release candidate that is currently being voted (see 
e-mails on the dev@ list for links).

There have been changes in the decoding code between 8.5.46 and .47.

c8fcc65e74d43b8201a50a30f88836264e565f79
709b45b42020d6cbc59940ab04380f5b0134b946
(on 17 and 18 of September)

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat 7 HTTPS and LDAP authentication issue

[John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco)]

The LDAPS authentication is handled by the application using an external file 
not in Tomcat or the application that contains
the credentials for the generic Active Directory account accessing LDAP, the 
Java keystore location, and the FQDN and port of the LDAPS host.

-John 

-Original Message-
From: Mark Thomas  
Sent: Tuesday, October 8, 2019 1:01 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 7 HTTPS and LDAP authentication issue

On 08/10/2019 19:52, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK 
INFORMATION INC at Cisco) wrote:
> Hi Mark,
> 
> How are you configuring TLS for the Connector?
> 
>   scheme="https"
>  secure="true"
>  protocol="org.apache.coyote.http11.Http11AprProtocol"
>  SSLEnabled="true"
>  SSLCertificateFile="/certs/foo.crt"
>  SSLCertificateKeyFile="/certs/foo.key"
>  maxThreads="150"
>  clientAuth="false"
>  SSLProtocol="all" />
> 
> How are you configuring TLS for LDAP?
> 
> Do you mean inside Tomcat?

Yes. Or is the authentication happening in httpd?

Mark

> 
> Thanks
> -John
> 
> -Original Message-
> From: Mark Thomas 
> Sent: Tuesday, October 8, 2019 11:07 AM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 7 HTTPS and LDAP authentication issue
> 
> On 08/10/2019 18:55, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK 
> INFORMATION INC at Cisco) wrote:
>> Hello,
>>
>> We have an application running on Tomcat 7.0.96. The application 
>> handles authentication by accessing an internal LDAPS host by using 
>> credentials, a keystore, and the LDAPS hostname and port from an 
>> external file from the application and from Tomcat. This works with no 
>> issues, until I enable HTTPS in Tomcat. Once I see sessions are encrypted, 
>> users can no longer logon to the application. When I disable HTTPS the users 
>> can again authenticate in the application. We do have an Apache reverse 
>> proxy for the application, but when Tomcat HTTPS is enabled I need to use 
>> https://hostname:8443/foo to get to the application login screen and not 
>> just https://hostname/foo.
>> With HTTPS disabled I can access the application with 
>> http://hostname/foo. That's obviously a config issue I need to address, but 
>> would that by why the authentication process would be broken when HTTPS in 
>> enabled?
> 
> How are you configuring TLS for LDAP?
> 
> How are you configuring TLS for the Connector?
> 
> I suspect that something somewhere is using the JVM wide TLS configuration 
> properties when it should be using LDAP / Tomcat Connector specific settings?
> 
> 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: Tomcat 7 HTTPS and LDAP authentication issue

[Mark Thomas]

On 08/10/2019 19:52, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK
INFORMATION INC at Cisco) wrote:
> Hi Mark,
> 
> How are you configuring TLS for the Connector?
> 
>   scheme="https"
>  secure="true"
>  protocol="org.apache.coyote.http11.Http11AprProtocol"
>  SSLEnabled="true"
>  SSLCertificateFile="/certs/foo.crt"
>  SSLCertificateKeyFile="/certs/foo.key"
>  maxThreads="150"
>  clientAuth="false"
>  SSLProtocol="all" />
> 
> How are you configuring TLS for LDAP?
> 
> Do you mean inside Tomcat?

Yes. Or is the authentication happening in httpd?

Mark

> 
> Thanks
> -John 
> 
> -Original Message-
> From: Mark Thomas  
> Sent: Tuesday, October 8, 2019 11:07 AM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 7 HTTPS and LDAP authentication issue
> 
> On 08/10/2019 18:55, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK 
> INFORMATION INC at Cisco) wrote:
>> Hello,
>>
>> We have an application running on Tomcat 7.0.96. The application 
>> handles authentication by accessing an internal LDAPS host by using 
>> credentials, a keystore, and the LDAPS hostname and port from an 
>> external file from the application and from Tomcat. This works with no 
>> issues, until I enable HTTPS in Tomcat. Once I see sessions are encrypted, 
>> users can no longer logon to the application. When I disable HTTPS the users 
>> can again authenticate in the application. We do have an Apache reverse 
>> proxy for the application, but when Tomcat HTTPS is enabled I need to use 
>> https://hostname:8443/foo to get to the application login screen and not 
>> just https://hostname/foo.
>> With HTTPS disabled I can access the application with 
>> http://hostname/foo. That's obviously a config issue I need to address, but 
>> would that by why the authentication process would be broken when HTTPS in 
>> enabled?
> 
> How are you configuring TLS for LDAP?
> 
> How are you configuring TLS for the Connector?
> 
> I suspect that something somewhere is using the JVM wide TLS configuration 
> properties when it should be using LDAP / Tomcat Connector specific settings?
> 
> 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: Any tutorials or hints about JSP using javax.script engines instead of Java?

[tomcat]

On 08.10.2019 17:11, Rony G. Flatscher (Apache) wrote:

Does anyone know of any tutorials that would demonstrate how to use any 
javax.script language in
JSPs instead of Java (e.g. using Jython or JavaScript instead)?

If not, any advice/hint how to realize/create such a functionality (for then 
creating such a
tutorial instead) would be highly appreciated!



I know nothing about the subject matter, but was searching Google for "javax.script 
language jsp" and found this :

http://wi.wu.ac.at:8002/rgf/diplomarbeiten/BakkStuff/2010/201007_Ryabenkiy/201007_Ryabenkiy_WebScripting_ApacheTomCat_TagLib.pdf
(look around page 50).
Does this help ?

On the side, even though (or maybe because) I did not previously know anything about this, 
I found this document really impressive in terms of providing a terse but extremely 
readable background of the whole thing, all the way to some practical examples, all in 
less than 100 pages. And this was a bachelor's thesis. So I don't know if it helps you, 
but I enjoyed it.
Looking up the author in Google, it doesn't seem that he really needs my modest plaudits 
though.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9.0.26 best practices

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Raheem,

On 10/8/19 07:54, Raheem Soukath Ali wrote:
> [... On] RHEL Linux 8[,] tomcat is not supplied or supported

Really?

Coty, whassup with RHEL 8?

- -chris

> -Original Message- From: Mark Thomas 
> Sent: Tuesday, October 8, 2019 1:41 PM To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.26 best practices
>
> On 08/10/2019 11:28, Raheem Soukath Ali wrote:
>> Hello,
>>
>> We are planning to install Tomcat 9.0.26 to host Oracle ORDS
>> 19.1 application.
>>
>> Kindly guide us in best practices for deploying Tomcat 9.0.26
>> within RHEL Linux 7 environment.
>
> If you are asking questions that broad then you probably don't want
> to install the latest 9.0.x release but should install the packaged
> version of Tomcat included with RHEL and obtain support for it via
> your RHEL support agreement.
>
> Mark
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> ==
>
>
This is an e-mail from Gulf Air B.S.C. (c). This e mail and any files
transmitted with it are or may be confidential or legally privileged and
are intended solely for the use of the individual or entity to whom they
are addressed. If you are not the named addressee you should not
disseminate, distribute or copy this e mail. Please notify the sender
immediately if you have received this e mail by mistake and delete this
e mail from your system. If you are not the intended recipient you are
notified that disclosing, copying distributing or taking action in
reliance on the contents of this information is strictly prohibited.
Although Gulf Air B.S.C. (c) has taken reasonable precautions to ensure
no viruses are present in this e mail, it accepts no liability for any
loss or damage arising from the use of this e mail or its attachments.
For details of how we handle your personal data, please see our Privacy
Policy at https://www.gulfair.com/transparency/privacy-policy
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2c4e0ACgkQHPApP6U8
pFh36BAAvjZjBYS1+Aud4JTIv7ltWK8Qcc4zRlAChwh7dFOBT3Cl8n8YJPqGI5Oz
3fOTnIN+k9vdRzd1e/0szF1x1hLr9agycuOrkYamFdYjMfMuCQlXoJ95GmWblIsj
XRrzm8zsXayGSnHgolQuYlqlstsUs1JneRociMvn+Esdk/5L7I9xQ75dq7emWyIR
7/bdtdRc96Hd//N1+ho18XQbBMCZTSMA1pHTGVr36N2M+6e6mkDCRMAgJWDa5dI7
m/GynNnsHrcmY/8SFlV/mrtJv3nhpC1IlWyHP0LHKkAA+lQb07q3EQVRzfq+OqH5
66tW5938ut/jY0KN0qtRtQB2KaVoC0UDsSyB0k9/Qww/SxK1BXkwKKPNK+g1MPCI
x/RFo+iOxlTZ5a5nMvC2+I+Y+lnXBzWzVuSU9A17kibORS9fP0h6nG5qnhMtv3/i
oH5zulZiisH7D9g/u7TtT7/xojGU8qYGGE2j/9+8b1yoIcr9hYk8OcP1fv3WOYEM
zXLjyd7VZwR0pCzAW9E0UBJw0YODAjhY82By4651DNVZuFFVSUxh92TEgdfp2ke8
1LJhiJJ3wwStNIWyVgMDCZnlR57A0TWniGuCTIvXI8wDhjxZhJlJk4neWZGHEbFL
ZPM8NsNlK44mnk8mAGF2k8lYjy1lBcTzOaRUrWw2plURnIMATw8=
=d3M1
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Acessing static content - Tomcat 7 vs. Tomcat9

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 10/7/19 11:45, Martin Knoblauch wrote:
> On Mon, Oct 7, 2019 at 5:10 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> Martin,
>>
>> On 10/7/19 07:22, Martin Knoblauch wrote:
>>> The mod_jk configuration basically looks like:
>>>
>>>  LoadModule jk_module modules/mod_jk.so
>>>
>>> JkWorkersFile "conf/cb2/workers.properties" JkShmFile
>>> "logs/jk-runtime-status" JkLogFile "logs/mod_jk.log"
>>> JkLogLevel info JkWatchdogInterval 60 
>>
>> So, you only configure mod_jk if it's NOT available? You have a
>> "!" in your  which looks like it's going to never ever
>> work.
>>
>>
> For a second you worried me. As far as I understand the
> documentation the section above means that I configure mod_jk if it
> is not yet loaded. And years of operations indicate my
> understanding is right :-)

Sorry, I actually didn't notice the "LoadModule" in there.

It's strange to see a LoadModule and the other configuration all
together for me. Typically, I load modules in one section and
configure then in another. It's all rather subjective, of course.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2c3ScACgkQHPApP6U8
pFg8+xAAsuyGXzxffPyIOZI/f0gjSm8JkNmE+SvKV2F5XuL5FeZlmxZq2Y2H7ibb
DJLIafutH+4ZzSnrQD5nMwbqLpYLOKUYV4Uc0aw+MH/hnbu2IFsR4f8wuhhck6xy
QDnHPM2Av2jjhkU1abd1z/qYFeRlhtMPp91GZMLr45lT0D9Plyo2awUNGqQz41Kk
mLKmiIuUayzrZSR2AX8FZMMM8jR3scgw0t43EJOuo+u2rwGjshwDhWs/tZUrAWU3
EGZWf/MNwGYg7Ku23uxZ3HgzQRyTOUi+kG9CBfJMGGSWoFQWUXe3oJ9wgNMauK/E
i+yex/l0r840M+C8voxlL2L6ohSr64zIvmVesTyK2HT8xvna+qhxp5V/dlUBtsiv
mbp3lrGga9HxFbQf1cnQxFMP0/KEhdmlS9LZt4GI+KW6iOufdOPpC/egSnXx9yHD
q8C02BLR83inY/da1pBQvPWSqDLV7Lh9i2rjcBL1gZiAJRHXhRHN/TJj85EvrK76
9RsybJil3n4Yt8RzBtNnKDMtm1kBNeUFpdYx6gO0ElYftK4BWHZ7O/qw6NRzuMNX
A/BrcJsbg2osEpjLXsKhbtUBWxGNFgmNVDQmLx9msE28slEgN4OjLFV/tBvCQopo
vUZudKrsnVS3yNr2v/MhsgmEWrNby2gH9jLOmm7n7cU1ERyH/z4=
=uXJX
-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 HTTPS and LDAP authentication issue

[John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco)]

Hi Mark,

How are you configuring TLS for the Connector?



How are you configuring TLS for LDAP?

Do you mean inside Tomcat? 

Thanks
-John 

-Original Message-
From: Mark Thomas  
Sent: Tuesday, October 8, 2019 11:07 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 7 HTTPS and LDAP authentication issue

On 08/10/2019 18:55, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK 
INFORMATION INC at Cisco) wrote:
> Hello,
> 
> We have an application running on Tomcat 7.0.96. The application 
> handles authentication by accessing an internal LDAPS host by using 
> credentials, a keystore, and the LDAPS hostname and port from an 
> external file from the application and from Tomcat. This works with no 
> issues, until I enable HTTPS in Tomcat. Once I see sessions are encrypted, 
> users can no longer logon to the application. When I disable HTTPS the users 
> can again authenticate in the application. We do have an Apache reverse proxy 
> for the application, but when Tomcat HTTPS is enabled I need to use 
> https://hostname:8443/foo to get to the application login screen and not just 
> https://hostname/foo.
> With HTTPS disabled I can access the application with 
> http://hostname/foo. That's obviously a config issue I need to address, but 
> would that by why the authentication process would be broken when HTTPS in 
> enabled?

How are you configuring TLS for LDAP?

How are you configuring TLS for the Connector?

I suspect that something somewhere is using the JVM wide TLS configuration 
properties when it should be using LDAP / Tomcat Connector specific settings?

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: Tomcat 7 HTTPS and LDAP authentication issue

[Mark Thomas]

On 08/10/2019 18:55, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK
INFORMATION INC at Cisco) wrote:
> Hello,
> 
> We have an application running on Tomcat 7.0.96. The application handles 
> authentication by accessing an internal LDAPS host by using credentials, a 
> keystore, and the
> LDAPS hostname and port from an external file from the application and from 
> Tomcat. This works with no issues, until I enable HTTPS in Tomcat. Once I see 
> sessions
> are encrypted, users can no longer logon to the application. When I disable 
> HTTPS the users can again authenticate in the application. We do have an 
> Apache reverse
> proxy for the application, but when Tomcat HTTPS is enabled I need to use 
> https://hostname:8443/foo to get to the application login screen and not just 
> https://hostname/foo.
> With HTTPS disabled I can access the application with http://hostname/foo. 
> That's obviously a config issue I need to address, but would that by why the 
> authentication process
> would be broken when HTTPS in enabled?

How are you configuring TLS for LDAP?

How are you configuring TLS for the Connector?

I suspect that something somewhere is using the JVM wide TLS
configuration properties when it should be using LDAP / Tomcat Connector
specific settings?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 7 HTTPS and LDAP authentication issue

[John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco)]

Hello,

We have an application running on Tomcat 7.0.96. The application handles 
authentication by accessing an internal LDAPS host by using credentials, a 
keystore, and the
LDAPS hostname and port from an external file from the application and from 
Tomcat. This works with no issues, until I enable HTTPS in Tomcat. Once I see 
sessions
are encrypted, users can no longer logon to the application. When I disable 
HTTPS the users can again authenticate in the application. We do have an Apache 
reverse
proxy for the application, but when Tomcat HTTPS is enabled I need to use 
https://hostname:8443/foo to get to the application login screen and not just 
https://hostname/foo.
With HTTPS disabled I can access the application with http://hostname/foo. 
That's obviously a config issue I need to address, but would that by why the 
authentication process
would be broken when HTTPS in enabled?

Thank you
-John

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

On 08.10.2019 17:53, Zero wrote:
> On 10/8/19 5:11 PM, Rony G. Flatscher (Apache) wrote:
>> Does anyone know of any tutorials that would demonstrate how to use any 
>> javax.script language in
>> JSPs instead of Java (e.g. using Jython or JavaScript instead)?
>>
>> If not, any advice/hint how to realize/create such a functionality (for then 
>> creating such a
>> tutorial instead) would be highly appreciated!
>>
>> ---rony
>
>
> How about TutorialsPoint ?

Thank you, already went through that but did not find anything related to 
javax.script languages (it
documents the "language" attribute (giving "java" as a value) in the page 
directive
(https://www.tutorialspoint.com/jsp/page_directive.htm).

---rony


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

[Zero]

On 10/8/19 5:11 PM, Rony G. Flatscher (Apache) wrote:

Does anyone know of any tutorials that would demonstrate how to use any 
javax.script language in
JSPs instead of Java (e.g. using Jython or JavaScript instead)?

If not, any advice/hint how to realize/create such a functionality (for then 
creating such a
tutorial instead) would be highly appreciated!

---rony



How about TutorialsPoint ?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Any tutorials or hints about JSP using javax.script engines instead of Java?

[Rony G. Flatscher (Apache)]

Does anyone know of any tutorials that would demonstrate how to use any 
javax.script language in
JSPs instead of Java (e.g. using Jython or JavaScript instead)?

If not, any advice/hint how to realize/create such a functionality (for then 
creating such a
tutorial instead) would be highly appreciated!

---rony




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9.0.26 best practices

[Sriram Narayanan]

I offer consultation on production ready setups and customisation.

Let me know if you are interested

Ram

On Tue, 8 Oct 2019 at 8:04 PM, Raheem Soukath Ali <
raheem.soukath...@gulfair.com> wrote:

> Hello,
>
> Thanks for your suggestion.
>
> Soon we are planning to upgrade RHEL to 8 version and from RHEL Linux 8
> tomcat is not supplied or supported, So in this case we are planning to
> install latest 9.0.x instead of supplied tomcat within RHEL.
>
> Please provide us the best practices for deploying Tomcat 9.0.26 within
> RHEL Linux 7 environment,  Thanks.
>
>
> Regards,
>
>
> Raheem Soukath Ali
> Senior Database Administrator
> Gulf Air - Information Technology
> Tel: +973-17-33-8514
> E-mail: raheem.soukath...@gulfair.com
> Website: www.gulfair.com
>
> Gulf Air, The Most Friendly way to fly!
> -Original Message-
> From: Mark Thomas 
> Sent: Tuesday, October 8, 2019 1:41 PM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.26 best practices
>
> On 08/10/2019 11:28, Raheem Soukath Ali wrote:
> > Hello,
> >
> > We are planning to install Tomcat 9.0.26 to host Oracle ORDS 19.1
> > application.
> >
> > Kindly guide us in best practices for deploying Tomcat 9.0.26 within
> > RHEL Linux 7 environment.
>
> If you are asking questions that broad then you probably don't want to
> install the latest 9.0.x release but should install the packaged version of
> Tomcat included with RHEL and obtain support for it via your RHEL support
> agreement.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> ==
> This is an e-mail from Gulf Air B.S.C. (c). This e mail and any files
> transmitted with it are or may be confidential or legally privileged and
> are intended solely for the use of the individual or entity to whom they
> are addressed. If you are not the named addressee you should not
> disseminate, distribute or copy this e mail. Please notify the sender
> immediately if you have received this e mail by mistake and delete this e
> mail from your system. If you are not the intended recipient you are
> notified that disclosing, copying distributing or taking action in reliance
> on the contents of this information is strictly prohibited. Although Gulf
> Air B.S.C. (c) has taken reasonable precautions to ensure no viruses are
> present in this e mail, it accepts no liability for any loss or damage
> arising from the use of this e mail or its attachments. For details of how
> we handle your personal data, please see our Privacy Policy at
> https://www.gulfair.com/transparency/privacy-policy
>

Re: Acessing static content - Tomcat 7 vs. Tomcat9

[tomcat]

On 08.10.2019 13:41, Martin Knoblauch wrote:

Hi Andre,

thanks for the extensive response. this is really appreciated. See below
for comments

On Mon, Oct 7, 2019 at 10:27 PM André Warnier (tomcat) 
wrote:


Hi.
see at end.



Then the browser tells me that "The page isn’t redirecting properly".

What one can see above is that the POST is now redirected, but the

trailing

"/" is not added as I would have expected using the two mapper directives
...

Not only that, but also all the subsequent browser GET requests for
"/cb2/docs", get a 302
response with a HTTP header :
Location: /cb2/docs
So the browser immediately re-issues a request for "/cb2/docs", which
receives the same
response, etc.
Until the (smart) browser realises that it is always requesting and
receiving the same
thing and calls quits.





What you are showing above as log, is only the httpd access log.
Do you have an access log enabled in tomcat, and do you see these same
accesses there ?
(And if yes, then forget all the rest below).



Yes, we have access logging enabled for Tomcat and for the TC9 setup I *DO
NOT* see requests for "/cb2/docs" in there.

Looking at the TC7 setup I can find the access and redirect in the Tomcat
access log:

160.46.219.110 - - [08/Oct/2019:12:49:31 +0200] "POST /cb2/docs HTTP/1.1"
302 -



Aha.  So it looks like, with Tomcat 9 in the back-end, these requests are not even being 
proxied to Tomcat, and that it is httpd in that case which returns the 302's.

Why that would be, with everything else being identical, is also a puzzle to me.
But it's still better that looking uselessly in some Tomcat configuration issue.

Maybe this will give someone else on the list an idea ..

In the meantime, a question : considering your JkMount/JkUnmount directives below, you do 
have some files locally under Apache httpd's filesystem, which you want to serve directly 
from httpd.
Would you have any other configuration sections with  which cover these 
files, and /may/ be interfering/overriding the JkMount/unmount logic ?
(Agreed, this is a long shot, and whatever they are, they should do the same whether it is 
t7 or t9 in the back-end, but again, one never knows..)





Or else, can you modify the "LogLevel" directive in httpd, so that you see

(in the httpd
error log) how (or if) these accesses are really being proxied to tomcat ?
(à la "Loglevel info proxy:debug proxy_ajp:debug" e.g.)



Have added "JkLogLevel debug" to the mod_jk setup. Nothing interesting to
see there. So I am still confused here.

Based on this, from a previous post :

quote
#
# CB2 - Portal
#
# Mount the "/cb2" application to worker "cb2"
#
   JkMount /cb2/* cb2
#
# Unmount "/cb2/docs" from worker "cb2" to allow static content
# beeing served by apache. Same for "/cb2/cgi-bin"
#
   JkUnMount /cb2/docs/* cb2

So we JkUnMount the "/cb2/docs" directory from the application base in
order to server the content directly from Apache. "docs" itself is a
symbolic link pointing outside the application base.

unquote

, I would indeed tend to say that a request with the URL "/cb2/docs"
SHOULD be proxied to
tomcat (and that the redirect should thus be coming from tomcat), but
better make
absolutely sure maybe ? (hence the additional logging above)

The thing I'm unsure of myself, is this :
Apache httpd gets the original request first. Initially, it doesn't know
if this request
should be proxied to tomcat or not. So, in its "map to storage" phase -
which happens
fairly early in the request processing -, it might try to map this URL to
its local
filesystem. Because you do indeed have files locally under /cb2/docs/, it
would then find
that "/cb2/docs" is indeed a directory (or a link to ditto).
Now two things can happen, depending on the stage at which the mod_jk
proxying directives
intervene in httpd :
- either httpd considers that the request, being for a directory, should
have a trailing
"/", and *httpd* issues the 302 redirect to the browser, without even
getting to the
proxying-to-tomcat stage
- or the proxying directive has insinuated itself somewhere in-between,
and httpd does in
fact proxy the original request to tomcat (rather than trying to map it to
its own
filesystem first), and it is tomcat (which also would need to find a
directory at
../webapps/cb2/docs) which issues that redirect.

I do not know which of the above is true, because I am unsure of the httpd
request cycle
stage at which mod_jk inserts its URL mapping logic.
But the logs which you have so far provided do not really *prove* that
these requests make
it to tomcat. So, if it was me, before spending time maybe looking in the
wrong place, I
would want to make sure of that first.

Another way would be to enable some local debugging console in the
browser, and have a
look at what these 302 replies look like. Apart from the "Location:"
header, there must be
a header there indicating from which webserver this response is coming
(httpd or tomcat).

Again, because of the configuration that 

Re: Tomcat 8 epoll spinning issue (100% CPU)

[Emmanuel Lecharny]

On 2019/10/07 10:18:43, Rémy Maucherat  wrote: 
> On Mon, Oct 7, 2019 at 11:15 AM Emmanuel Lecharny 
> wrote:
> 
> >
> >
> > On 2019/10/05 11:12:46, Rémy Maucherat  wrote:
> > > On Fri, Oct 4, 2019 at 10:38 PM Emmanuel Lecharny 
> > > wrote:
> > >
> > > > Hi remy,
> > > >
> > > > On 2019/10/04 15:37:36, Rémy Maucherat  wrote:
> > > > > On Fri, Oct 4, 2019 at 3:40 PM Emmanuel Lecharny <
> > elecha...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi !
> > > > > >
> > > > > > I filled a ticket yesterday about a pb we face with many NIO
> > framework,
> > > > > > which I think could hit Tomcat too (see
> > > > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=63802). Actually, I
> > > > think
> > > > > > I'm facing this problem on a project I'm working on atm.
> > > > > >
> > > > > > Remy suggested we discuss it on this mailing list.
> > > > > >
> > > > > > Bottom line, what happens is that under some circumstances not well
> > > > > > defined, the call to select() might end to an infinite loop eating
> > all
> > > > the
> > > > > > CPU (select() returns 0, so select is immediately called again,
> > and we
> > > > > > loop).
> > > > > >
> > > > > > In various NIO framworks - and being a MINA committer, I have
> > > > implemented
> > > > > > the discussed workaround -, we are controlling this situation by
> > > > breaking
> > > > > > this infinite loop this way :
> > > > > > - if the select() call returns 0
> > > > > > - then if we have called select() more than N times in less than M
> > ms
> > > > > > (N=10, M=100 in MINA)
> > > > > > - then we create a new Selector, register all the selectionKey that
> > > > were
> > > > > > registered on the broken selector, and ditch the old selector.
> > > > > >
> > > > > > This workaround does not cost a lot when the selector works as
> > > > designed,
> > > > > > as a select() call should never return 0.
> > > > > >
> > > > >
> > > > > There's actually a very similar hack for APR that has been placed by
> > > > myself
> > > > > a long time ago [
> > > > >
> > > >
> > https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/net/AprEndpoint.java#L1410
> > > > > ], I don't even know if it's actually useful and it's certainly not
> > > > > testable. Overall what it does is pretty terrible :(
> > > > >
> > > > > Personally I would like to know more about this "long lived bug
> > either in
> > > > > the JDK or even in Linux epoll implementation" like actual platform
> > > > details
> > > > > and JVM versions used since I've never heard about it in the first
> > place.
> > > >
> > > > for the record, I had a discussion yesterday with one of my close
> > friend
> > > > and co-worker back in the 90's. He remember clearly, while working on
> > the
> > > > SUN TCP stack,  that such a problem occorded back then. Yes, 25 years
> > > > ago... Ok, that was just for the fun, it's likely be perfectly
> > unrelated ;-)
> > > >
> > > > At MINA, we were hit by this bug in 2009 (see
> > > > https://issues.apache.org/jira/browse/DIRMINA-678), and it was linked
> > to
> > > > a bug reported on Jetty (
> > > >
> > http://jetty.4.x6.nabble.com/jira-Created-JETTY-937-SelectChannelConnector-100-CPU-usage-on-Linux-td36385.html
> > ),
> > > > itself related to some JDK bugs, supposedly fixed since then.
> > > >
> > > > I had a long conversation with Jean-François Arcand somewhere around
> > this
> > > > date, and he suggested we adopt the same workaround he applied to
> > Grizzly.
> > > > We also had a convo with Alan Bateman during a Java One in SF, but
> > nothing
> > > > specific resulted from this convo, except that AFAICR, he aknowledge
> > there
> > > > is an issue.
> > > >
> > > > So this problem started with JDK 6, but I can't guarantee it wasn't
> > > > already present in JDK 5 or 4, on linux, and not on any other OS like
> > > > windows or Mac OSX. It's not exactly fresh in my mind, because it was
> > > > already 10 years ago.
> > > >
> > >
> > > NIO support was added in Tomcat 6.0, supporting Java 5+, it wasn't very
> > > good then. It's only with Java 6 that NIO started getting epoll support
> > ant
> > > I'm pretty sure the original issue did not actually survive. Despite the
> > > popularity of the NIO connector this was not reported for Tomcat, if we
> > got
> > > the report at the same time as the others it would be more logical so
> > > something is different here.
> > > https://github.com/netty/netty/issues/327 has details but I'm still not
> > > very convinced. You should give details on your platform and everything
> > > else since it's obvious at this point this is far less common with
> > Tomcat.
> >
> > There is not much I can tell about this issue, beside what I already said.
> > I can just stress out that for a few users of MINA, this was a real burden,
> > and the very same for Netty, Grizzly and Jetty. I would be *very* surprised
> > that those four different projects, all based on NIO, are facing such an
> > issue, but that Tomcat is immune to 

RE: Tomcat 9.0.26 best practices

[Raheem Soukath Ali]

Hello,

Thanks for your suggestion.

Soon we are planning to upgrade RHEL to 8 version and from RHEL Linux 8 tomcat 
is not supplied or supported, So in this case we are planning to install latest 
9.0.x instead of supplied tomcat within RHEL.

Please provide us the best practices for deploying Tomcat 9.0.26 within RHEL 
Linux 7 environment,  Thanks.


Regards,


Raheem Soukath Ali
Senior Database Administrator
Gulf Air - Information Technology
Tel: +973-17-33-8514
E-mail: raheem.soukath...@gulfair.com
Website: www.gulfair.com

Gulf Air, The Most Friendly way to fly!
-Original Message-
From: Mark Thomas 
Sent: Tuesday, October 8, 2019 1:41 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.26 best practices

On 08/10/2019 11:28, Raheem Soukath Ali wrote:
> Hello,
>
> We are planning to install Tomcat 9.0.26 to host Oracle ORDS 19.1
> application.
>
> Kindly guide us in best practices for deploying Tomcat 9.0.26 within
> RHEL Linux 7 environment.

If you are asking questions that broad then you probably don't want to install 
the latest 9.0.x release but should install the packaged version of Tomcat 
included with RHEL and obtain support for it via your RHEL support agreement.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


==
This is an e-mail from Gulf Air B.S.C. (c). This e mail and any files 
transmitted with it are or may be confidential or legally privileged and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the named addressee you should not disseminate, 
distribute or copy this e mail. Please notify the sender immediately if you 
have received this e mail by mistake and delete this e mail from your system. 
If you are not the intended recipient you are notified that disclosing, copying 
distributing or taking action in reliance on the contents of this information 
is strictly prohibited. Although Gulf Air B.S.C. (c) has taken reasonable 
precautions to ensure no viruses are present in this e mail, it accepts no 
liability for any loss or damage arising from the use of this e mail or its 
attachments. For details of how we handle your personal data, please see our 
Privacy Policy at https://www.gulfair.com/transparency/privacy-policy

Re: Acessing static content - Tomcat 7 vs. Tomcat9

[Martin Knoblauch]

Hi Andre,

thanks for the extensive response. this is really appreciated. See below
for comments

On Mon, Oct 7, 2019 at 10:27 PM André Warnier (tomcat) 
wrote:

> Hi.
> see at end.
>
>
> > Then the browser tells me that "The page isn’t redirecting properly".
> >
> > What one can see above is that the POST is now redirected, but the
> trailing
> > "/" is not added as I would have expected using the two mapper directives
> > ...
> Not only that, but also all the subsequent browser GET requests for
> "/cb2/docs", get a 302
> response with a HTTP header :
> Location: /cb2/docs
> So the browser immediately re-issues a request for "/cb2/docs", which
> receives the same
> response, etc.
> Until the (smart) browser realises that it is always requesting and
> receiving the same
> thing and calls quits.
>
> >
>
> What you are showing above as log, is only the httpd access log.
> Do you have an access log enabled in tomcat, and do you see these same
> accesses there ?
> (And if yes, then forget all the rest below).
>
>
Yes, we have access logging enabled for Tomcat and for the TC9 setup I *DO
NOT* see requests for "/cb2/docs" in there.

Looking at the TC7 setup I can find the access and redirect in the Tomcat
access log:

160.46.219.110 - - [08/Oct/2019:12:49:31 +0200] "POST /cb2/docs HTTP/1.1"
302 -


Or else, can you modify the "LogLevel" directive in httpd, so that you see
> (in the httpd
> error log) how (or if) these accesses are really being proxied to tomcat ?
> (à la "Loglevel info proxy:debug proxy_ajp:debug" e.g.)
>
>
Have added "JkLogLevel debug" to the mod_jk setup. Nothing interesting to
see there. So I am still confused here.

Based on this, from a previous post :
> quote
> #
> # CB2 - Portal
> #
> # Mount the "/cb2" application to worker "cb2"
> #
>   JkMount /cb2/* cb2
> #
> # Unmount "/cb2/docs" from worker "cb2" to allow static content
> # beeing served by apache. Same for "/cb2/cgi-bin"
> #
>   JkUnMount /cb2/docs/* cb2
>
> So we JkUnMount the "/cb2/docs" directory from the application base in
> order to server the content directly from Apache. "docs" itself is a
> symbolic link pointing outside the application base.
>
> unquote
>
> , I would indeed tend to say that a request with the URL "/cb2/docs"
> SHOULD be proxied to
> tomcat (and that the redirect should thus be coming from tomcat), but
> better make
> absolutely sure maybe ? (hence the additional logging above)
>
> The thing I'm unsure of myself, is this :
> Apache httpd gets the original request first. Initially, it doesn't know
> if this request
> should be proxied to tomcat or not. So, in its "map to storage" phase -
> which happens
> fairly early in the request processing -, it might try to map this URL to
> its local
> filesystem. Because you do indeed have files locally under /cb2/docs/, it
> would then find
> that "/cb2/docs" is indeed a directory (or a link to ditto).
> Now two things can happen, depending on the stage at which the mod_jk
> proxying directives
> intervene in httpd :
> - either httpd considers that the request, being for a directory, should
> have a trailing
> "/", and *httpd* issues the 302 redirect to the browser, without even
> getting to the
> proxying-to-tomcat stage
> - or the proxying directive has insinuated itself somewhere in-between,
> and httpd does in
> fact proxy the original request to tomcat (rather than trying to map it to
> its own
> filesystem first), and it is tomcat (which also would need to find a
> directory at
> ../webapps/cb2/docs) which issues that redirect.
>
> I do not know which of the above is true, because I am unsure of the httpd
> request cycle
> stage at which mod_jk inserts its URL mapping logic.
> But the logs which you have so far provided do not really *prove* that
> these requests make
> it to tomcat. So, if it was me, before spending time maybe looking in the
> wrong place, I
> would want to make sure of that first.
>
> Another way would be to enable some local debugging console in the
> browser, and have a
> look at what these 302 replies look like. Apart from the "Location:"
> header, there must be
> a header there indicating from which webserver this response is coming
> (httpd or tomcat).
>
> Again, because of the configuration that you showed, and because the
> behaviour seems to
> change after making a change in the tomcat configuration, I would tend to
> believe that
> these requests are being proxied to tomcat. But let's be 100% sure, rather
> than 99%..
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de

Re: Bug in org.apache.tomcat.util.codec.binary.Base64.decodeBase64 ?

[Mark Thomas]

On 08/10/2019 11:26, Konstantin Kolinko wrote:
> вт, 8 окт. 2019 г. в 12:24, Arnaud Yahoo :
>>
>> Hello,
>>
>> I am using a 3rd party valve for OpenId Connect authentication that stop
>> working upgrading from tomcat 8.5.24 to 8.5.46
>>
>> I managed to isolate the issue behing this and it is caused by a change
>> in org.apache.tomcat.util.codec.binary.Base64
>>
>> It can be reproduce with a simple test case
>>
>> @Test
>>  public void decodeBase64Test() {
>>  String str =
>> "YZJXP8zFDY6WPk1NZx4RtkH95lA4H_GM_XmFjouJImtqy-PD27-GUYVrCq1QM3M09TzRFZTL4aMMTweZFj3h1M-4Pqb4xrRq9URICQ9ffpnB9OGKjEwEpzhICwbE8C8-zEbhFOEgdXcyeP0pJc9uHEUH9Z4rTEg0jxmOmffIAbX9zfjhIla0XUsFd2C2QQGXu1nTFrb2EqfhLDls4ZLCcnLZE6Be3SpHCtvZiFN4w3xlI0TZitX4S3SjTocK4Xobb3Ey0RnewDP6jw78JniFTbuuGB962GlHDJvaQoda2dON9j7Yhv_pTvxBlHDmIKYINYsBfTwEQ_qtLJtmcvv41Q";
>>
>> assertArrayEquals(org.apache.tomcat.util.codec.binary.Base64.decodeBase64(str),
>> java.util.Base64.getUrlDecoder().decode(str));
>>  }
>>
>> This test is ok with 8.5.24 but fails with 8.5.46. Are there any known
>> issues with Base64 utility ?
> 
> Please test with 8.5.47 release candidate that is currently being
> voted (see e-mails on the dev@ list for links).
> 
> There have been changes in the decoding code between 8.5.46 and .47.
> 
> c8fcc65e74d43b8201a50a30f88836264e565f79
> 709b45b42020d6cbc59940ab04380f5b0134b946
> (on 17 and 18 of September)

And you probably want
org.apache.tomcat.util.codec.binary.Base64.decodeBase64URLSafe(String)

The short(ish) version is:
- Commons CODEC fixed a bug to handle incomplete encodings at the end of
  the input (CODEC-134)
- That triggered a failure in one of Tomcat's unit tests
- Fixing the particular failure meant removing the "seamless" decoding
  of both standard and URL-safe Base64 with the same code
- We (OK, I) incorrectly thought Tomcat didn't need the URL-safe
  decoding so it was removed - this triggered the issue you describe
  above
- Testing of the HTTP/2 showed we did need it so it was restored but
  separate methods were provided for standard and URL-safe decoding

HTH,

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9.0.26 best practices

[Mark Thomas]

On 08/10/2019 11:28, Raheem Soukath Ali wrote:
> Hello,
> 
> We are planning to install Tomcat 9.0.26 to host Oracle ORDS 19.1
> application.
> 
> Kindly guide us in best practices for deploying Tomcat 9.0.26 within
> RHEL Linux 7 environment.

If you are asking questions that broad then you probably don't want to
install the latest 9.0.x release but should install the packaged version
of Tomcat included with RHEL and obtain support for it via your RHEL
support agreement.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Bug in org.apache.tomcat.util.codec.binary.Base64.decodeBase64 ?

[Konstantin Kolinko]

вт, 8 окт. 2019 г. в 12:24, Arnaud Yahoo :
>
> Hello,
>
> I am using a 3rd party valve for OpenId Connect authentication that stop
> working upgrading from tomcat 8.5.24 to 8.5.46
>
> I managed to isolate the issue behing this and it is caused by a change
> in org.apache.tomcat.util.codec.binary.Base64
>
> It can be reproduce with a simple test case
>
> @Test
>  public void decodeBase64Test() {
>  String str =
> "YZJXP8zFDY6WPk1NZx4RtkH95lA4H_GM_XmFjouJImtqy-PD27-GUYVrCq1QM3M09TzRFZTL4aMMTweZFj3h1M-4Pqb4xrRq9URICQ9ffpnB9OGKjEwEpzhICwbE8C8-zEbhFOEgdXcyeP0pJc9uHEUH9Z4rTEg0jxmOmffIAbX9zfjhIla0XUsFd2C2QQGXu1nTFrb2EqfhLDls4ZLCcnLZE6Be3SpHCtvZiFN4w3xlI0TZitX4S3SjTocK4Xobb3Ey0RnewDP6jw78JniFTbuuGB962GlHDJvaQoda2dON9j7Yhv_pTvxBlHDmIKYINYsBfTwEQ_qtLJtmcvv41Q";
>
> assertArrayEquals(org.apache.tomcat.util.codec.binary.Base64.decodeBase64(str),
> java.util.Base64.getUrlDecoder().decode(str));
>  }
>
> This test is ok with 8.5.24 but fails with 8.5.46. Are there any known
> issues with Base64 utility ?

Please test with 8.5.47 release candidate that is currently being
voted (see e-mails on the dev@ list for links).

There have been changes in the decoding code between 8.5.46 and .47.

c8fcc65e74d43b8201a50a30f88836264e565f79
709b45b42020d6cbc59940ab04380f5b0134b946
(on 17 and 18 of September)

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: user and certificate info is not passed to tomcat

[Mark Thomas]

There is no Tomcat, mod_jk nor httpd bug here.

The root cause of this thread is a configuration error.

>From the httpd docs for Location:


The URL may use wildcards. In a wild-card string, ? matches any single
character, and * matches any sequences of characters. Neither wildcard
character matches a / in the URL-path.


Note - in particular - the final sentence.

>From the JkMount docs:


Inside Location, one omits the first argument (path), which gets
inherited verbatim from the Location argument. Whereas 
matches any URI beginning with "/myapp", any JkMount nested in such a
Location block will only match for requests with exact URI /myapp.
Therefore nesting JkMount in Location is typically not the right thing
to do.


Again, note - in particular - the final sentence.

The original configuration was:


JkMount  worker1
SSLVerifyClient require
SSLOptions +StdEnvVars
SSLOptions +ExportCertData
...


As per the documentation, configuration in the Location block and the
JkMount DO NOT apply to the same set of URLs as the matching rules are
different. Hence the behaviour that is observed.

For example "/servlet/foo" will match the JkMount directive but NOT the
location block.


It isn't clear what the intended configuration is but I suspect it is
something along these lines:


SSLVerifyClient require
SSLOptions +StdEnvVars
SSLOptions +ExportCertData
...

JkMount  /servlet worker1
JkMount  /servlet/*   worker1

Mark



On 08/10/2019 02:09, André Warnier (tomcat) wrote:
> On 08.10.2019 00:50, Magosányi Árpád wrote:
>> On 10/7/19 11:29 PM, André Warnier (tomcat) wrote:
>>> 
>>>  DirectoryIndex off
>>>  RewriteEngine Off
>>>  AuthType openid-connect
>>>  AllowOverride None
>>>  AuthzDBDQuery "a correct database query"
>>>  Require dbd-group allrepo
>>>  LogLevel debug
>>> 
>>
>> Nice. It have solved the problem, thank you very much. By adding the ssl
>> related directives here I could pass the ssl info as well. So basically
>> we have put the JkMount in a Location, and the other directives in
>> another similar directive, as a kind of workaround?
> 
> Think of it as follows :
> When httpd gets a request,
> - step 1 : it first looks only at the request URL, and it applies any
> directives that it finds in  or  sections which
> match that URL.
> - step 2 : then it tries to match the URL, with the filesystem on disk,
> and IF it finds a file that corresponds to that URL
> - step 3 : then it applies any  or  that
> apply to that file
> - step 4 : httpd serves the file back to the browser
> 
> If you have JkMount directives that match the URL, then step 2, 3 and 4
> above never happen, because the request will be passed to tomcat anyway,
> so it will never map to a file on the httpd filesystem. And if you have
> JkUnmount directives, that also match the URL, then they partially
> negate the matching JkMount, and they /force/ step 2, 3 and 4.
> 
> The combination of JkMount/JkUnmount directives, with the httpd
>  and  sections, is sometimes a bit
> unclear, specially when they overlap.
> 
> There is another syntax applicable to the proxying via mod_jk, which I
> prefer because I find that it makes the httpd URL mapping clearer, in a
> httpd configuration logic sense.
> You can find it here :
> http://tomcat.apache.org/connectors-doc/reference/apache.html
> section : Using SetHandler and Environment Variables
> 
> Using that form, you do NOT use any "JkMount/JkUnmount" directives, you
> use only  blocks, like :
> 
> 
>   SetHandler jakarta-servlet
>   SetEnv JK_WORKER_NAME worker1
>   DirectoryIndex off
>   RewriteEngine Off
>   AuthType openid-connect
>   AllowOverride None
>   AuthzDBDQuery "a correct database query"
>   Require dbd-group allrepo
>   LogLevel debug
> 
> 
> The combination of the , SetHandler and
> SetEnv, does the same as a separate "JkMount /servlet* worker1" and (in
> my view) it makes it clearer in the Apache httpd configuration file, to
> know which URLs get proxied to tomcat and which do not get proxied.
> Look at the example "" to see how you can have some
> static documents served by the httpd front-end directly (= not proxied
> to tomcat), and the real calls to tomcat servlets being proxied to tomcat.
> 
> 
> 
>>
>>
>>
>> -
>> 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

Tomcat 9.0.26 best practices

[Raheem Soukath Ali]

Hello,





We are planning to install Tomcat 9.0.26 to host Oracle ORDS 19.1 application.



Kindly guide us in best practices for deploying Tomcat 9.0.26 within RHEL Linux 
7 environment.







Thanks & Regards,


Raheem Soukath Ali
Senior Database Administrator
Gulf Air - Information Technology
Tel: +973-17-33-8514
E-mail: raheem.soukath...@gulfair.com
Website:www.gulfair.com
[cid:Current_Email_Banner_b9c1c345-f4d3-4d67-8439-f24e053f35f1.jpg]
Stay in touch with @gulfair
[cid:Facebook_d8116275-243e-44d8-b34e-8f2d7d0c6699.png][cid:Twitter_66099a04-5d61-439d-84ca-8f9ef9d392eb.png][cid:Instagram_f252d159-347a-4a52-86aa-087124e42729.png][cid:Youtube_114ddb42-81fe-4311-96b4-3c37c773877a.png][cid:Linkedin_848da850-f158-445f-91e4-1abb7f7a0542.png]

==
This is an e-mail from Gulf Air B.S.C. (c). This e mail and any files 
transmitted with it are or may be confidential or legally privileged and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the named addressee you should not disseminate, 
distribute or copy this e mail. Please notify the sender immediately if you 
have received this e mail by mistake and delete this e mail from your system. 
If you are not the intended recipient you are notified that disclosing, copying 
distributing or taking action in reliance on the contents of this information 
is strictly prohibited. Although Gulf Air B.S.C. (c) has taken reasonable 
precautions to ensure no viruses are present in this e mail, it accepts no 
liability for any loss or damage arising from the use of this e mail or its 
attachments. For details of how we handle your personal data, please see our 
Privacy Policy at https://www.gulfair.com/transparency/privacy-policy

Bug in org.apache.tomcat.util.codec.binary.Base64.decodeBase64 ?

[Arnaud Yahoo]

Hello,

I am using a 3rd party valve for OpenId Connect authentication that stop 
working upgrading from tomcat 8.5.24 to 8.5.46


I managed to isolate the issue behing this and it is caused by a change 
in org.apache.tomcat.util.codec.binary.Base64


It can be reproduce with a simple test case

@Test
    public void decodeBase64Test() {
        String str = 
"YZJXP8zFDY6WPk1NZx4RtkH95lA4H_GM_XmFjouJImtqy-PD27-GUYVrCq1QM3M09TzRFZTL4aMMTweZFj3h1M-4Pqb4xrRq9URICQ9ffpnB9OGKjEwEpzhICwbE8C8-zEbhFOEgdXcyeP0pJc9uHEUH9Z4rTEg0jxmOmffIAbX9zfjhIla0XUsFd2C2QQGXu1nTFrb2EqfhLDls4ZLCcnLZE6Be3SpHCtvZiFN4w3xlI0TZitX4S3SjTocK4Xobb3Ey0RnewDP6jw78JniFTbuuGB962GlHDJvaQoda2dON9j7Yhv_pTvxBlHDmIKYINYsBfTwEQ_qtLJtmcvv41Q";


assertArrayEquals(org.apache.tomcat.util.codec.binary.Base64.decodeBase64(str), 
java.util.Base64.getUrlDecoder().decode(str));

    }

This test is ok with 8.5.24 but fails with 8.5.46. Are there any known 
issues with Base64 utility ?


Arnaud



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org