AW: Password in Tomcat 9.x
Hello Alex, I usually remove the password on the p12 file via openssl. Protecting with password and writing the password in clear text somewhere doesn't improve security much I think. Dunno if this is a possible way to go for you. Greetings, Thomas Von: a.grub...@bluewin.ch Gesendet: Dienstag, 17. Januar 2023 21:01:00 An: 'Tomcat Users List' Betreff: AW: Password in Tomcat 9.x Hoi Thomas Received also from Mark an email where he requested an example of the web.xml. Will provide you this tomorrow. Below is what I wrote him. Regards Alex # # # Hi Mark I will provide a config example tomorrow. Let you know the details. I have them on the other machine. In general it is like that - we have a webserver certificate (p12), which we use to have the https protocol. The certificate comes together with a p12.pwd file and this password of the certificate is stored in the web.xml. I want now to remove this password by configuring just the path to this file. In case someone renew the certificate, the restart of tomcat can be done anytime as always the correct password is used. Regards Alexander # # # -Ursprüngliche Nachricht- Von: Thomas Hoffmann (Speed4Trade GmbH) Gesendet: Dienstag, 17. Januar 2023 19:19 An: Tomcat Users List Betreff: AW: Password in Tomcat 9.x Hello Alex, I am not sure what your goal is. Webserver certificate (with private key) is used for encryption / ssl / tls. Password is used for user authentication and in web.xml you only specify the auth method, not any passwords. Or do you plan auth with client certificates? Greetings, Thomas Von: a.grub...@bluewin.ch Gesendet: Dienstag, 17. Januar 2023 18:34:15 An: users@tomcat.apache.org Betreff: Password in Tomcat 9.x Hello together I would like to understand, when implementing passwords into web.xml, then I would like NOT to implement a password, I want to include the path to a certificate (p12.pwd). I want to basically avoid, changing all the time the password, when I renew my webserver certificate in the configuration. Which version of Tomcat 9.x is able to do this? Will it be for seen, that 9.x can do this? If no 9.x can do, which other Tomcat can do this? Thank you Alexander Grubner - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat maven plugin
The official tomcat maven plugin has not been updated for years, for the latest tomcat/Maven support, I would like to use the Cargo maven plugin instead. https://codehaus-cargo.github.io/cargo/Maven+3+Plugin.html Example project: https://github.com/hantsy/jakartaee9-servlet-starter-boilerplate --- Regards, *Hantsy Bai* Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker GitHub: https://github.com/hantsy Twitter: https://twitter.com/@hantsy Medium: https://medium.com/@hantsy On Wed, Jan 18, 2023 at 1:51 AM Mark Thomas wrote: > On 17/01/2023 17:35, Alex O'Ree wrote: > > Is the tomcat maven plugin still maintained? I noticed it hasn't been > > updated in a while > > Not at the moment, but if someone wants to volunteer to do so it is a > great opportunity to start contributing. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
AW: Password in Tomcat 9.x
Hoi Thomas Received also from Mark an email where he requested an example of the web.xml. Will provide you this tomorrow. Below is what I wrote him. Regards Alex # # # Hi Mark I will provide a config example tomorrow. Let you know the details. I have them on the other machine. In general it is like that - we have a webserver certificate (p12), which we use to have the https protocol. The certificate comes together with a p12.pwd file and this password of the certificate is stored in the web.xml. I want now to remove this password by configuring just the path to this file. In case someone renew the certificate, the restart of tomcat can be done anytime as always the correct password is used. Regards Alexander # # # -Ursprüngliche Nachricht- Von: Thomas Hoffmann (Speed4Trade GmbH) Gesendet: Dienstag, 17. Januar 2023 19:19 An: Tomcat Users List Betreff: AW: Password in Tomcat 9.x Hello Alex, I am not sure what your goal is. Webserver certificate (with private key) is used for encryption / ssl / tls. Password is used for user authentication and in web.xml you only specify the auth method, not any passwords. Or do you plan auth with client certificates? Greetings, Thomas Von: a.grub...@bluewin.ch Gesendet: Dienstag, 17. Januar 2023 18:34:15 An: users@tomcat.apache.org Betreff: Password in Tomcat 9.x Hello together I would like to understand, when implementing passwords into web.xml, then I would like NOT to implement a password, I want to include the path to a certificate (p12.pwd). I want to basically avoid, changing all the time the password, when I renew my webserver certificate in the configuration. Which version of Tomcat 9.x is able to do this? Will it be for seen, that 9.x can do this? If no 9.x can do, which other Tomcat can do this? Thank you Alexander Grubner - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Password in Tomcat 9.x
Hi Mark I will provide a config example tomorrow. Let you know the details. I have them on the other machine. In general it is like that - we have a webserver certificate (p12), which we use to have the https protocol. The certificate comes together with a p12.pwd file and this password of the certificate is stored in the web.xml. I want now to remove this password by configuring just the path to this file. In case someone renew the certificate, the restart of tomcat can be done anytime as always the correct password is used. Regards Alexander -Ursprüngliche Nachricht- Von: Mark Thomas Gesendet: Dienstag, 17. Januar 2023 18:49 An: users@tomcat.apache.org Betreff: Re: Password in Tomcat 9.x On 17/01/2023 17:34, a.grub...@bluewin.ch wrote: > Hello together > > I would like to understand, when implementing passwords into web.xml, > then I would like NOT to implement a password, I want to include the > path to a certificate (p12.pwd). I want to basically avoid, changing > all the time the password, when I renew my webserver certificate in the > configuration. > > Which version of Tomcat 9.x is able to do this? Will it be for seen, > that 9.x can do this? > > If no 9.x can do, which other Tomcat can do this? What password are you trying to set in web.xml? Please provide a configuration snippet. 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: SSO Token not found with RewriteRules
On 1/17/2023 12:30 PM, Jerry Malcolm wrote: On 1/17/2023 3:43 AM, Mark Thomas wrote: On 16/01/2023 23:07, Jerry Malcolm wrote: Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. No. The restriction isn't intended. See this discussion around a similar issue: https://github.com/apache/tomcat/pull/479 Generally, not having a ROOT context is sufficiently unusual that it is rare for users to fund bugs like this. A similar approach should fix this - assume the default CookieProcessor if no context is found. Mark Thanks for the reply, Mark. In my philosophy for years (possibly not the best philosophy...), the root was for primarily static stuff. And any JSPs that might need to be in root were sent to other non-root contexts via a rewrite. I've been moving away from that philosophy in recent projects and including a ROOT context. But this current situation is migrating a legacy domain off of httpd/tomcat to pure tomcat. So it bit me. No big deal now that I've figured it out. The cookie processing was inside the Tomcat request object. So I assume that statement about using the default CookieProcessor was meant for TC development. Or is there a way I can control which cookie processor is used? Thanks again... on to the next hill to climb. Jerry Mark, You know a day or two earlier it crossed my mind that order of the valves might be significant. I was convinced that if I found out 'working host A' and 'non-working host B' had the valves declared in different orders then obviously problem solved... But then I saw that they both had SSO above rewrite, and since they were identical and one worked, one didn't, that couldn't be the problem. But now that you mentioned it, I'm wondering if the order could be significant, and having the ROOT domain defined simply masked the ordering differences. If I get some time to play, I'll re-order them and pull the ROOT context temporarily and see what happens. Thanks. Jerry On 1/16/2023 12:40 AM, Jerry Malcolm wrote: I have one virtual host working fine on a Windows 11 TC 9 install. I am adding a 2nd virtual host to that same running installation. This TC is standalone, handling http requests directly (not via httpd). Both virtual hosts have a rewrite.config. On the new domain, I go to a page that requires a login, do the standard login, and it show the page. I can F5 refresh the page and it continues to appear. But if I enter a url that redirects to this same page, I get the signin screen. If I try to sign in again, I get an error "The requested resource [/idmanager/j_security_check] is not available" I enabled redirect logs, and they show SSO token not found. I know the redirect is working fine for the new virtual host since there's no problems going to unprotected (no sign-in) redirected pages. This exact scenario works perfectly fine (with rewrite rules) on the other virtual host in the same TC. I've compared the two host configurations in server.xml and they appear identical other than than the name and path. i.e. SingleSignOn valve is specified on both. The fact that SSO only fails on redirects and not on URLs without redirects, plus the fact that it works fine on one virtual host and not on the other is baffling me. All indications point to some sort of config error or typo on the
Tomcat JDBC CP: Exponential backoff?
Hi, Does Tomcat's CP support exponential backoff in case DB is unavailable for some reason? I didn't find anything in the documentation in this regards. Mfg Thomas -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: SSO Token not found with RewriteRules
On 1/17/2023 3:43 AM, Mark Thomas wrote: On 16/01/2023 23:07, Jerry Malcolm wrote: Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. No. The restriction isn't intended. See this discussion around a similar issue: https://github.com/apache/tomcat/pull/479 Generally, not having a ROOT context is sufficiently unusual that it is rare for users to fund bugs like this. A similar approach should fix this - assume the default CookieProcessor if no context is found. Mark Thanks for the reply, Mark. In my philosophy for years (possibly not the best philosophy...), the root was for primarily static stuff. And any JSPs that might need to be in root were sent to other non-root contexts via a rewrite. I've been moving away from that philosophy in recent projects and including a ROOT context. But this current situation is migrating a legacy domain off of httpd/tomcat to pure tomcat. So it bit me. No big deal now that I've figured it out. The cookie processing was inside the Tomcat request object. So I assume that statement about using the default CookieProcessor was meant for TC development. Or is there a way I can control which cookie processor is used? Thanks again... on to the next hill to climb. Jerry Thanks. Jerry On 1/16/2023 12:40 AM, Jerry Malcolm wrote: I have one virtual host working fine on a Windows 11 TC 9 install. I am adding a 2nd virtual host to that same running installation. This TC is standalone, handling http requests directly (not via httpd). Both virtual hosts have a rewrite.config. On the new domain, I go to a page that requires a login, do the standard login, and it show the page. I can F5 refresh the page and it continues to appear. But if I enter a url that redirects to this same page, I get the signin screen. If I try to sign in again, I get an error "The requested resource [/idmanager/j_security_check] is not available" I enabled redirect logs, and they show SSO token not found. I know the redirect is working fine for the new virtual host since there's no problems going to unprotected (no sign-in) redirected pages. This exact scenario works perfectly fine (with rewrite rules) on the other virtual host in the same TC. I've compared the two host configurations in server.xml and they appear identical other than than the name and path. i.e. SingleSignOn valve is specified on both. The fact that SSO only fails on redirects and not on URLs without redirects, plus the fact that it works fine on one virtual host and not on the other is baffling me. All indications point to some sort of config error or typo on the something in the new virtual host. But I have spent more hours that I want to admit on this, and I simply can't figure out anything that would cause this. I'm sure I made some config change somewhere a long time ago on the first virtual host that's making it work correctly. But I can't find anything, and I'm at a total loss. What could be causing rewrite rules to not find SSO cookies? Where did I mess up? Thanks Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe,
AW: Password in Tomcat 9.x
Hello Alex, I am not sure what your goal is. Webserver certificate (with private key) is used for encryption / ssl / tls. Password is used for user authentication and in web.xml you only specify the auth method, not any passwords. Or do you plan auth with client certificates? Greetings, Thomas Von: a.grub...@bluewin.ch Gesendet: Dienstag, 17. Januar 2023 18:34:15 An: users@tomcat.apache.org Betreff: Password in Tomcat 9.x Hello together I would like to understand, when implementing passwords into web.xml, then I would like NOT to implement a password, I want to include the path to a certificate (p12.pwd). I want to basically avoid, changing all the time the password, when I renew my webserver certificate in the configuration. Which version of Tomcat 9.x is able to do this? Will it be for seen, that 9.x can do this? If no 9.x can do, which other Tomcat can do this? Thank you Alexander Grubner
Re: Tomcat maven plugin
On 17/01/2023 17:35, Alex O'Ree wrote: Is the tomcat maven plugin still maintained? I noticed it hasn't been updated in a while Not at the moment, but if someone wants to volunteer to do so it is a great opportunity to start contributing. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Password in Tomcat 9.x
On 17/01/2023 17:34, a.grub...@bluewin.ch wrote: Hello together I would like to understand, when implementing passwords into web.xml, then I would like NOT to implement a password, I want to include the path to a certificate (p12.pwd). I want to basically avoid, changing all the time the password, when I renew my webserver certificate in the configuration. Which version of Tomcat 9.x is able to do this? Will it be for seen, that 9.x can do this? If no 9.x can do, which other Tomcat can do this? What password are you trying to set in web.xml? Please provide a configuration snippet. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat maven plugin
Is the tomcat maven plugin still maintained? I noticed it hasn't been updated in a while
Password in Tomcat 9.x
Hello together I would like to understand, when implementing passwords into web.xml, then I would like NOT to implement a password, I want to include the path to a certificate (p12.pwd). I want to basically avoid, changing all the time the password, when I renew my webserver certificate in the configuration. Which version of Tomcat 9.x is able to do this? Will it be for seen, that 9.x can do this? If no 9.x can do, which other Tomcat can do this? Thank you Alexander Grubner
Re: How-To apply Tomcat patch
Thanks Chris.. I use the windows installer downloaded from tomcat.apache.org ( apache-tomcat-9.0.70.exe ) -Original Message- From: Tomcat Users List Sent: Jan 17, 2023 9:18 AM To: Subject: Re: How-To apply Tomcat patch Linwood, On 1/17/23 09:03, Linwood Doty wrote: > We have Apache Tomcat 9.0.65 and need to apply .70 patch . > > 1. Is it necessary to uninstall current Tomcat installation and > reinstall with latest target patch - or is there a way to just apply > the patch ? > > environment Windows 2012, Tomcat is used for BSI TaxFactory 11.0 When you install on Windows, how do you do it? Windows installer from tomcat.apache.org? ZIP distribution? Bill Stewart's Setup? Knowing how you install will help answer your question. -chris - 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: How-To apply Tomcat patch
Linwood, On 1/17/23 09:03, Linwood Doty wrote: We have Apache Tomcat 9.0.65 and need to apply .70 patch . 1. Is it necessary to uninstall current Tomcat installation and reinstall with latest target patch - or is there a way to just apply the patch ? environment Windows 2012, Tomcat is used for BSI TaxFactory 11.0 When you install on Windows, how do you do it? Windows installer from tomcat.apache.org? ZIP distribution? Bill Stewart's Setup? Knowing how you install will help answer your question. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat for Apple silicon coming soon?
Mark, On 1/17/23 09:12, Mark Thomas wrote: On 17/01/2023 14:08, Christopher Schultz wrote: Chris and Robert, On 1/16/23 17:08, Mark Thomas wrote: On 16/01/2023 20:40, Robert Turner wrote: You can run an aarm64 version of the Java runtime (various distributions exist) and run Tomcat on that -- it works well. No specific version of Tomcat is required as it a Java package. +1 I've been running the Tomcat unit tests on Apple silicon for a while now. Generally, if there is a JRE that meets the minimum Java version requirement for a platform, then Tomcat will run. The only missing component is tcnative. The Tomcat team provides binary releases of tcnative for Windows platforms because compilers and toolchains are generally unavailable, and Windows environments tend to be very uniform (only x86 and x86-86 for example). We do not distribute binaries for UNIX-like systems. The last time I tried, I was able to build tcnative on MacOS 11.7.1 (Big Sur) with only a few warnings, but that was on x86-84. I do not have an aarm86 MacOS environment to try, but I think others on the team do. If tcnative isn't building in your environment, please let us know and we can try to help. I can confirm that Tomcat Native builds and the associated unit tests pass on Apple silicon. Excellent, thanks. -chris On Mon, Jan 16, 2023 at 3:38 PM m...@cvkimball.com wrote: I'd like to run Tomcat on one of the new Apple products based on the Apple Mac silicon ARM64 architecture. Is a Tomcat release, preferably Tomcat 10.1, for Mac silicon likely in the near future? Thanks, Chris Kimball Redding, CT - 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 - 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: Query: HSTS | Tomcat 9.0.50
Deepti, On 1/16/23 23:00, Deepti Sharma S wrote: 1. There is no reverse proxy in between tomcat and UA in my use case. 2. In Tomcat/conf/server.xml I have below connector settings : When I configure HSTS in Tomcat/conf/web.xml and try to access website via HTTPS https://[domain]:8443, HSTS header is returned but ignored If the HSTS header is returned, that's all Tomcat can do. as in when I change URL to http://[domain]:8080 URL is not changed to secured URL. 3. When I change conf/server.xml with below connector settings along with HSTS : Try to access website via HTTPS https://[domain]:433 URL is changed to https://[domain], HSTS header is returned and honoured as in when I change URL to http://[domain]:80 URL is changed to secured URL https://[domain]. So my query is how to configure HSTS on explicit custom ports(like in my case mentioned in point 2 8080/8443) or what is the recommendation, please suggest? I wonder if browsers are not sensitive to the port number being used for HTTPS. The HSTS header is intended to tell the browser "only use HTTPS on this site" but it does allow a port number to be specified. The browser *could* retain the port number as well, but that might not be correct or it may not be a part of the spec. I'm sorry, I'm not familiar enough with the spec to know whether this could be a problem or not, but it seems plausible. But if Tomcat is returning the HSTS header as expected, there isn't really any more that you can do. Thanks, -chris -Original Message- From: Olaf Kock Sent: 16 January 2023 13:56 To: users@tomcat.apache.org Subject: Re: Query: HSTS | Tomcat 9.0.50 On 16.01.23 06:57, Deepti Sharma S wrote: Hello Team, Can you please help us for below query: Query : How to enable HSTS in Apache Tomcat on non-default ports? We have custom ports for http and https and we want to enable HSTS on those custom ports. Note: We could see HSTS is working with default ports 80/443 though it's not working on other custom ports, please let us know if there are different steps to enable HSTS on non-default ports. In order to "work", HSTS *must* be on https, by specification. When you say you got it working on 80/443, you haven't. You might see the headers, but it's not working. Most likely the header is ignored by the browser. Whereever you handle your https termination - that might be on Tomcat, or on a reverse proxy that sees traffic before Tomcat does - you'll best do the HSTS handling. /That/ server knows it's serving https. And there the header actually is valid and working. If you try to configure a http (not https) connector on Tomcat for adding the HSTS headers, it's well within the specification to ignore that setting. Technically you can do some trickery around that, but to make that sensible and safely would take more than a quick answer. And leave room for misinterpretation and configuration mistakes. So: Configure it anyhwere you terminate https, and ignore it on http. Olaf - 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 for Apple silicon coming soon?
On 17/01/2023 14:08, Christopher Schultz wrote: Chris and Robert, On 1/16/23 17:08, Mark Thomas wrote: On 16/01/2023 20:40, Robert Turner wrote: You can run an aarm64 version of the Java runtime (various distributions exist) and run Tomcat on that -- it works well. No specific version of Tomcat is required as it a Java package. +1 I've been running the Tomcat unit tests on Apple silicon for a while now. Generally, if there is a JRE that meets the minimum Java version requirement for a platform, then Tomcat will run. The only missing component is tcnative. The Tomcat team provides binary releases of tcnative for Windows platforms because compilers and toolchains are generally unavailable, and Windows environments tend to be very uniform (only x86 and x86-86 for example). We do not distribute binaries for UNIX-like systems. The last time I tried, I was able to build tcnative on MacOS 11.7.1 (Big Sur) with only a few warnings, but that was on x86-84. I do not have an aarm86 MacOS environment to try, but I think others on the team do. If tcnative isn't building in your environment, please let us know and we can try to help. I can confirm that Tomcat Native builds and the associated unit tests pass on Apple silicon. Mark -chris On Mon, Jan 16, 2023 at 3:38 PM m...@cvkimball.com wrote: I'd like to run Tomcat on one of the new Apple products based on the Apple Mac silicon ARM64 architecture. Is a Tomcat release, preferably Tomcat 10.1, for Mac silicon likely in the near future? Thanks, Chris Kimball Redding, CT - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat for Apple silicon coming soon?
Chris and Robert, On 1/16/23 17:08, Mark Thomas wrote: On 16/01/2023 20:40, Robert Turner wrote: You can run an aarm64 version of the Java runtime (various distributions exist) and run Tomcat on that -- it works well. No specific version of Tomcat is required as it a Java package. +1 I've been running the Tomcat unit tests on Apple silicon for a while now. Generally, if there is a JRE that meets the minimum Java version requirement for a platform, then Tomcat will run. The only missing component is tcnative. The Tomcat team provides binary releases of tcnative for Windows platforms because compilers and toolchains are generally unavailable, and Windows environments tend to be very uniform (only x86 and x86-86 for example). We do not distribute binaries for UNIX-like systems. The last time I tried, I was able to build tcnative on MacOS 11.7.1 (Big Sur) with only a few warnings, but that was on x86-84. I do not have an aarm86 MacOS environment to try, but I think others on the team do. If tcnative isn't building in your environment, please let us know and we can try to help. -chris On Mon, Jan 16, 2023 at 3:38 PM m...@cvkimball.com wrote: I'd like to run Tomcat on one of the new Apple products based on the Apple Mac silicon ARM64 architecture. Is a Tomcat release, preferably Tomcat 10.1, for Mac silicon likely in the near future? Thanks, Chris Kimball Redding, CT - 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
How-To apply Tomcat patch
Hello, We have Apache Tomcat 9.0.65 and need to apply .70 patch . 1. Is it necessary to uninstall current Tomcat installation and reinstall with latest target patch - or is there a way to just apply the patch ? environment Windows 2012, Tomcat is used for BSI TaxFactory 11.0 Thanks! Linwood Doty - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Query: HSTS | Tomcat 9.0.50
On 17.01.23 13:09, Olaf Kock wrote: On 17.01.23 11:45, Deepti Sharma S wrote: Hello, I have tried with both Chrome and Mozilla in private window where information is not cached. HSTS is not working on custom ports. I'm not confident that HSTS is among those cached values that are not shared between normal and incognito mode. Try curl -v As far as I know, curl does not save any HSTS state anywhere. Thomas' suggestion makes the most sense: Once your browser knows positively that it absolutely must connect through https on port 443, I can easily imagine it never even to attempt to try 8080. I should have edited ^ this after adding the specs from RFC 6797: Once the browser knows that it *must* use https for this host, it will not connect through http, no matter which port. The browser keeps records of this by domain name, not by name/port. Also, according to the specs: The browser will - under no circumstances - connect to your host through http. The specs say: |The UA MUST replace the URI scheme with "https" [RFC2818], and if the URI contains an explicit port component of "80", then the UA MUST convert the port component to be "443", or>> if the URI contains an explicit port component that is not equal to "80", the port component value MUST be preserved; otherwise, if the URI does not contain an explicit port component, the UA MUST NOT add one. NOTE: These steps ensure that the HSTS Policy applies to HTTP over any TCP port of an HSTS Host.| So, if you connect to 8080 from your browser, your browser would try to speak https to port 8080 if it has already seen the HSTS header before. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Query: HSTS | Tomcat 9.0.50
On 17.01.23 11:45, Deepti Sharma S wrote: Hello, I have tried with both Chrome and Mozilla in private window where information is not cached. HSTS is not working on custom ports. I'm not confident that HSTS is among those cached values that are not shared between normal and incognito mode. Try curl -v As far as I know, curl does not save any HSTS state anywhere. Thomas' suggestion makes the most sense: Once your browser knows positively that it absolutely must connect through https on port 443, I can easily imagine it never even to attempt to try 8080. Also, according to the specs: The browser will - under no circumstances - connect to your host through http. The specs say: |The UA MUST replace the URI scheme with "https" [RFC2818], and if the URI contains an explicit port component of "80", then the UA MUST convert the port component to be "443", or>> if the URI contains an explicit port component that is not equal to "80", the port component value MUST be preserved; otherwise, if the URI does not contain an explicit port component, the UA MUST NOT add one. NOTE: These steps ensure that the HSTS Policy applies to HTTP over any TCP port of an HSTS Host.| So, if you connect to 8080 from your browser, your browser would try to speak https to port 8080 if it has already seen the HSTS header before. Olaf
RE: Query: HSTS | Tomcat 9.0.50
Hello, I have tried with both Chrome and Mozilla in private window where information is not cached. HSTS is not working on custom ports. Regards, Deepti Sharma PMP(r) & ITIL -Original Message- From: Thomas Hoffmann (Speed4Trade GmbH) Sent: 17 January 2023 15:40 To: Tomcat Users List Subject: AW: Query: HSTS | Tomcat 9.0.50 Hello, Which browser are you using? Can you clear the hsts information in the browser after changing the port in your configuration? I think browsers cache the hsts and port Informationen and don't switch to other ports with hsts. Greetings, Thomas Von: Deepti Sharma S Gesendet: Dienstag, 17. Januar 2023 05:00:35 An: Tomcat Users List Betreff: RE: Query: HSTS | Tomcat 9.0.50 Hi Olaf, Let me explain more on my use-case : 1. There is no reverse proxy in between tomcat and UA in my use case. 2. In Tomcat/conf/server.xml I have below connector settings : When I configure HSTS in Tomcat/conf/web.xml and try to access website via HTTPS https://[domain]:8443, HSTS header is returned but ignored as in when I change URL to http://[domain]:8080 URL is not changed to secured URL. 3. When I change conf/server.xml with below connector settings along with HSTS : Try to access website via HTTPS https://[domain]:433 URL is changed to https://[domain], HSTS header is returned and honoured as in when I change URL to http://[domain]:80 URL is changed to secured URL https://[domain]. So my query is how to configure HSTS on explicit custom ports(like in my case mentioned in point 2 8080/8443) or what is the recommendation, please suggest? Regards, Deepti Sharma PMP(r) & ITIL -Original Message- From: Olaf Kock Sent: 16 January 2023 13:56 To: users@tomcat.apache.org Subject: Re: Query: HSTS | Tomcat 9.0.50 On 16.01.23 06:57, Deepti Sharma S wrote: > Hello Team, > > Can you please help us for below query: > > Query : How to enable HSTS in Apache Tomcat on non-default ports? > We have custom ports for http and https and we want to enable HSTS on > those custom ports. > > Note: We could see HSTS is working with default ports 80/443 though it's not > working on other custom ports, please let us know if there are different > steps to enable HSTS on non-default ports. > In order to "work", HSTS *must* be on https, by specification. When you say you got it working on 80/443, you haven't. You might see the headers, but it's not working. Most likely the header is ignored by the browser. Whereever you handle your https termination - that might be on Tomcat, or on a reverse proxy that sees traffic before Tomcat does - you'll best do the HSTS handling. /That/ server knows it's serving https. And there the header actually is valid and working. If you try to configure a http (not https) connector on Tomcat for adding the HSTS headers, it's well within the specification to ignore that setting. Technically you can do some trickery around that, but to make that sensible and safely would take more than a quick answer. And leave room for misinterpretation and configuration mistakes. So: Configure it anyhwere you terminate https, and ignore it on http. Olaf - 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: SSO Token not found with RewriteRules
On 17/01/2023 09:43, Mark Thomas wrote: On 16/01/2023 23:07, Jerry Malcolm wrote: Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. No. The restriction isn't intended. See this discussion around a similar issue: https://github.com/apache/tomcat/pull/479 Generally, not having a ROOT context is sufficiently unusual that it is rare for users to fund bugs like this. A similar approach should fix this - assume the default CookieProcessor if no context is found. Quick question. Is the SingleSignOn valve configured before the Rewrite valve in your Host? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Query: HSTS | Tomcat 9.0.50
Hello, Which browser are you using? Can you clear the hsts information in the browser after changing the port in your configuration? I think browsers cache the hsts and port Informationen and don't switch to other ports with hsts. Greetings, Thomas Von: Deepti Sharma S Gesendet: Dienstag, 17. Januar 2023 05:00:35 An: Tomcat Users List Betreff: RE: Query: HSTS | Tomcat 9.0.50 Hi Olaf, Let me explain more on my use-case : 1. There is no reverse proxy in between tomcat and UA in my use case. 2. In Tomcat/conf/server.xml I have below connector settings : When I configure HSTS in Tomcat/conf/web.xml and try to access website via HTTPS https://[domain]:8443, HSTS header is returned but ignored as in when I change URL to http://[domain]:8080 URL is not changed to secured URL. 3. When I change conf/server.xml with below connector settings along with HSTS : Try to access website via HTTPS https://[domain]:433 URL is changed to https://[domain], HSTS header is returned and honoured as in when I change URL to http://[domain]:80 URL is changed to secured URL https://[domain]. So my query is how to configure HSTS on explicit custom ports(like in my case mentioned in point 2 8080/8443) or what is the recommendation, please suggest? Regards, Deepti Sharma PMP® & ITIL -Original Message- From: Olaf Kock Sent: 16 January 2023 13:56 To: users@tomcat.apache.org Subject: Re: Query: HSTS | Tomcat 9.0.50 On 16.01.23 06:57, Deepti Sharma S wrote: > Hello Team, > > Can you please help us for below query: > > Query : How to enable HSTS in Apache Tomcat on non-default ports? > We have custom ports for http and https and we want to enable HSTS on > those custom ports. > > Note: We could see HSTS is working with default ports 80/443 though it's not > working on other custom ports, please let us know if there are different > steps to enable HSTS on non-default ports. > In order to "work", HSTS *must* be on https, by specification. When you say you got it working on 80/443, you haven't. You might see the headers, but it's not working. Most likely the header is ignored by the browser. Whereever you handle your https termination - that might be on Tomcat, or on a reverse proxy that sees traffic before Tomcat does - you'll best do the HSTS handling. /That/ server knows it's serving https. And there the header actually is valid and working. If you try to configure a http (not https) connector on Tomcat for adding the HSTS headers, it's well within the specification to ignore that setting. Technically you can do some trickery around that, but to make that sensible and safely would take more than a quick answer. And leave room for misinterpretation and configuration mistakes. So: Configure it anyhwere you terminate https, and ignore it on http. Olaf - 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: SSO Token not found with RewriteRules
On 16/01/2023 23:07, Jerry Malcolm wrote: Well, after downloading and installing the Tomcat source in my Eclipse environment and tracking through a bunch of breakpoints, I figured out what was happening. SingleSignOn.invoke() was querying for the list of cookies in the request (that were indeed present in the request), but was returning null. Since no cookies were 'found' there was no JSESSIONIDSSO cookie found, and everything failed from that point on. So I started tracking why the cookies that were present were being ignored. convertCookies was called, which did a getContext() which returned null, so everything aborted. getContext() failed apparently because I did not have a ROOT webapp (context) defined. I added a dummy ROOT webapp, and voila So the bottom line to the entire problem is that RewriteRules with SSO is not permitted UNLESS there is a dummy ROOT webapp defined. I'm not sure why this would be a requirement, and I was not able to find any documentation about it. I understand why SSO might require contexts. But the primary purpose of RewriteRules is to hide the plumbing on the URL line. If the requirement for context present is required for SSO, then it would seem to me that the context should be checked on the target of the rewrite, not the original string being rewritten, since it most likely will not have a valid context. And a dummy unused ROOT webapp just takes up resources. The reason it worked in the other virtual host is that I actually did have a need in that host for a ROOT context. This one was painful. Just out of curiosity, is this restriction intended? If so, error messages and/or documentation of it might need a review. No. The restriction isn't intended. See this discussion around a similar issue: https://github.com/apache/tomcat/pull/479 Generally, not having a ROOT context is sufficiently unusual that it is rare for users to fund bugs like this. A similar approach should fix this - assume the default CookieProcessor if no context is found. Mark Thanks. Jerry On 1/16/2023 12:40 AM, Jerry Malcolm wrote: I have one virtual host working fine on a Windows 11 TC 9 install. I am adding a 2nd virtual host to that same running installation. This TC is standalone, handling http requests directly (not via httpd). Both virtual hosts have a rewrite.config. On the new domain, I go to a page that requires a login, do the standard login, and it show the page. I can F5 refresh the page and it continues to appear. But if I enter a url that redirects to this same page, I get the signin screen. If I try to sign in again, I get an error "The requested resource [/idmanager/j_security_check] is not available" I enabled redirect logs, and they show SSO token not found. I know the redirect is working fine for the new virtual host since there's no problems going to unprotected (no sign-in) redirected pages. This exact scenario works perfectly fine (with rewrite rules) on the other virtual host in the same TC. I've compared the two host configurations in server.xml and they appear identical other than than the name and path. i.e. SingleSignOn valve is specified on both. The fact that SSO only fails on redirects and not on URLs without redirects, plus the fact that it works fine on one virtual host and not on the other is baffling me. All indications point to some sort of config error or typo on the something in the new virtual host. But I have spent more hours that I want to admit on this, and I simply can't figure out anything that would cause this. I'm sure I made some config change somewhere a long time ago on the first virtual host that's making it work correctly. But I can't find anything, and I'm at a total loss. What could be causing rewrite rules to not find SSO cookies? Where did I mess up? Thanks Jerry - 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
