Re: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Btw, I tried my luck on Tomcat 7.0.100 before when 9.0.31 not work, also hit the same problem, just fyi. thanks again for helping me out! On Thu, Mar 12, 2020, 11:55 KC Mok wrote: > thank you very much, it is working now! > > On Thu, Mar 12, 2020, 11:50 Mills, Robert - CTR [ASM Research] > wrote: > >> Hi KC >> >> I hit that also. Turns out if I added this: >> >>allowedRequestAttributesPattern=".*" >> >> Then I got past the 403. I think this is supposed to be fixed in the >> next release of tomcat. >> >> Give it a shot. >> >> Toby >> >> -Original Message- >> From: KC Mok >> Sent: Wednesday, March 11, 2020 11:36 PM >> To: users@tomcat.apache.org >> Subject: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is >> not "working" when SSL enabled in IIS >> >> Hi All, >> I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. >> >> Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. >> >> I have set the new required attributes of the AJP connector in the new >> 9.0.31 version, and it is working fine when using http. >> However, it returns error (403 Access is denied) when I use https to >> access the site. >> >> I tried with the lastest 1.2.48 version isapi_redirect.dll, still not >> working. After that, I tried to revert back to Tomcat 9.0.22, everything is >> working fine. >> >> Does anyone have the same problem? >> I wonder if I hit a bug in the new version... >> please help... >> >> Thanks and regards, >> KC >> >> >> The information contained in this message may be privileged and/or >> confidential and protected from disclosure. If the reader of this message >> is not the intended recipient or agent responsible for delivering this >> message to the intended recipient, you are hereby notified that any >> dissemination, distribution or copying of this communication is strictly >> prohibited. If you have received this communication in error, please notify >> the sender immediately by replying to this message and deleting the >> material from any computer. >> >
Re: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
thank you very much, it is working now! On Thu, Mar 12, 2020, 11:50 Mills, Robert - CTR [ASM Research] wrote: > Hi KC > > I hit that also. Turns out if I added this: > >allowedRequestAttributesPattern=".*" > > Then I got past the 403. I think this is supposed to be fixed in the next > release of tomcat. > > Give it a shot. > > Toby > > -Original Message- > From: KC Mok > Sent: Wednesday, March 11, 2020 11:36 PM > To: users@tomcat.apache.org > Subject: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is > not "working" when SSL enabled in IIS > > Hi All, > I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. > > Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. > > I have set the new required attributes of the AJP connector in the new > 9.0.31 version, and it is working fine when using http. > However, it returns error (403 Access is denied) when I use https to > access the site. > > I tried with the lastest 1.2.48 version isapi_redirect.dll, still not > working. After that, I tried to revert back to Tomcat 9.0.22, everything is > working fine. > > Does anyone have the same problem? > I wonder if I hit a bug in the new version... > please help... > > Thanks and regards, > KC > > > The information contained in this message may be privileged and/or > confidential and protected from disclosure. If the reader of this message > is not the intended recipient or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any > dissemination, distribution or copying of this communication is strictly > prohibited. If you have received this communication in error, please notify > the sender immediately by replying to this message and deleting the > material from any computer. >
RE: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Hi KC I hit that also. Turns out if I added this: allowedRequestAttributesPattern=".*" Then I got past the 403. I think this is supposed to be fixed in the next release of tomcat. Give it a shot. Toby -Original Message- From: KC Mok Sent: Wednesday, March 11, 2020 11:36 PM To: users@tomcat.apache.org Subject: [External] After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS Hi All, I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. I have set the new required attributes of the AJP connector in the new 9.0.31 version, and it is working fine when using http. However, it returns error (403 Access is denied) when I use https to access the site. I tried with the lastest 1.2.48 version isapi_redirect.dll, still not working. After that, I tried to revert back to Tomcat 9.0.22, everything is working fine. Does anyone have the same problem? I wonder if I hit a bug in the new version... please help... Thanks and regards, KC The information contained in this message may be privileged and/or confidential and protected from disclosure. If the reader of this message is not the intended recipient or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting the material from any computer.
RE: After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Set this on AJP Connector in tomcat server.xml allowedRequestAttributesPattern="CERT_(ISSUER|SUBJECT|COOKIE|FLAGS|SERIALNUMBER)|HTTPS_(SERVER_(SUBJECT|ISSUER)|(SECRETKEYSIZE|KEYSIZE))" All on one line. I can see tomcat fixing this in 9.0.32 which isn't yet released. Thanks, P. -Original Message- From: KC Mok Sent: Thursday, March 12, 2020 9:06 AM To: users@tomcat.apache.org Subject: After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS Hi All, I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. I have set the new required attributes of the AJP connector in the new 9.0.31 version, and it is working fine when using http. However, it returns error (403 Access is denied) when I use https to access the site. I tried with the lastest 1.2.48 version isapi_redirect.dll, still not working. After that, I tried to revert back to Tomcat 9.0.22, everything is working fine. Does anyone have the same problem? I wonder if I hit a bug in the new version... please help... Thanks and regards, KC
After upgraded to Tomcat 9.0.31, ISAPI Redirector is not "working" when SSL enabled in IIS
Hi All, I am using ISAPI redirector to connect IIS to Tomcat via AJP connector. Recently I have replaced the Tomcat 9.0.22 with the new version 9.0.31. I have set the new required attributes of the AJP connector in the new 9.0.31 version, and it is working fine when using http. However, it returns error (403 Access is denied) when I use https to access the site. I tried with the lastest 1.2.48 version isapi_redirect.dll, still not working. After that, I tried to revert back to Tomcat 9.0.22, everything is working fine. Does anyone have the same problem? I wonder if I hit a bug in the new version... please help... Thanks and regards, KC
Re: Autoflush is not "working"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ed, On 3/11/20 11:14, e...@wolfecomputerservices.com wrote: > Tomcat 9 > > NetBeans 11.3 > > Windows 10 > > > > The JspWriter.autoFlush setting seems to be ignored. I confired > that isAutoFlush() is true (and it is) but my output (using > JspWriter.print()) is truncated. If I explicitly put flush() in my > output loop, I get all the data. Any direction would be > appreciated Are you ever printing a newline? How much data are you printing? What is your buffer size? "autoflush" doesn't flush after every print operation. It only automatically flushes the buffer when the buffer fills or when the response has been completed (e.g. the JSP execution completes). Can you share a sample of what you are doing? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5pEZcACgkQHPApP6U8 pFgnxA//SEZ76gk1hdiQSY6HPHZl9OQMfgt+CGQXukocnhe9M6Km3ZMOCby7V5PX 8/aXtWIMHaIiUU8xJtPMSJSfVhYA3SErADloIlAFHuU73BjRiEdgGMv/ObnI6M9I cVMxPdakYAtJKp2CmoopdXrEs8N+9NegmcgOdKlDerAwel73HR7gif2rEGvZ3EnF prHWB8Wmw7O3eo6R/YNvR5tiOCWelZVwhUDI6PB5HYAus4BrRkdbYQBEq8qM5Mnv rMJy23Wto5RZS1uVUemEL9swv4ykoITNasHYnbLIFsilGBrBrI33XAwaS55prNMq kU4Dqhebhu23S90pzEOAQ/z/H+TJHgSSOyw4dE1eUyrn8Diq8YBuJYrbqo3OfQOw yCawqmGh7cG+SWDiHaR+0RTrJMNVXzkhL1BaRF2shChMKsmMfLDHlR7lPc+G0ZDF TBk6pDXysYM6o7HCWx8w4MTlm7KmT40xxJaLI5ZhXvL7+qigg2qIiG/36cyLPf9q PBCvsWBPp5EpO79Qbe42yEtt+ClrwZfXKpuknBCZDGUH0S8e/uz3kbQruvlofSJ3 Vg8f1cYqgB22hmjZh69nkG5sFgP8ytLB1OBhxaVmGOYF6XdWqVlD5EKTipghxM+C Al95DpaFPPq6GGv0LcAm1ZTEO3snLWtFBnMq3Vybog49X9NbwUw= =422W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SameSite cookies shows as "Unset" but Header shows Correct Value
Just to confirm, we know that Chrome will block JSESSIONID it if sent over unsecure connection and with SameSite=None. But we saw the previously mentioned issue in Firefox. Thanks, On Wed, 11 Mar 2020 at 15:33, M. Manna wrote: > Hi All, > > Due to the recent issues with Chrome 80, we have had to make some changes > for our context.xml to have SameSite attribute setup for CookieProcessor > > What we've noticed is that even though CookieProcessorBase captures and > assigns the correct value (e.g. "None" or "Lax"), the Network tab of > browsers (e.g. Firefox, Chrome) always shows SameSite as "Unset". But if > you observe the response header, it's actually setting the correct value. > > The question is - Would this be expected? Or, do we have to fix something > here for browsers? > > Regards, > M. MAnna >
SameSite cookies shows as "Unset" but Header shows Correct Value
Hi All, Due to the recent issues with Chrome 80, we have had to make some changes for our context.xml to have SameSite attribute setup for CookieProcessor What we've noticed is that even though CookieProcessorBase captures and assigns the correct value (e.g. "None" or "Lax"), the Network tab of browsers (e.g. Firefox, Chrome) always shows SameSite as "Unset". But if you observe the response header, it's actually setting the correct value. The question is - Would this be expected? Or, do we have to fix something here for browsers? Regards, M. MAnna
Autoflush is not "working"
Tomcat 9 NetBeans 11.3 Windows 10 The JspWriter.autoFlush setting seems to be ignored. I confired that isAutoFlush() is true (and it is) but my output (using JspWriter.print()) is truncated. If I explicitly put flush() in my output loop, I get all the data. Any direction would be appreciated
Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
On 10.03.2020 15:44, Martin Grigorov wrote: On Tue, Mar 10, 2020 at 3:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 3/10/20 04:43, Martin Grigorov wrote: We can define custom address like "loopback" for which Tomcat will bind on both "127.0.0.1" and "::1" depending on the values of java.net.preferIPv4Stack and java.net.preferIPv6Addresses, but I am not sure whether it is worth it This is kind of an interesting suggestion, as would maybe supporting "all" as an alias for both 0.0.0.0 and :: together (the old default behavior, which is no longer possible with a single ). Are there any examples of these kinds of things in other products, or does everyone just manually define two separate connector-like entities? httpd just does: Listen 0.0.0.0 Listen :: Which is pretty simple. Tomcat's configuration is a lot more verbose and so repeating it is doubly so. Another option is to make "address" attribute multi valued, e.g. comma/space separated. My 2 cent : Since the changes were necessary, have been made and are presumably there to stay, and since this seems to have caused a lot of confusion with a lot of sysadmins, mainly among the ones which had a working front-end/back-end configuration, which suddenly stopped working when they made a minor version upgrade. And since even so, it seems that when the change was made, there was quite an underestimate of the side-effects and the impact this would have in the practical reality out there, should there not be a separate addition to the documentation, explaining this AJP Connector and its settings "from the ground up", starting with the fact that currently, it is basically insecure if used on an open network (and that this was not its original purpose). (At least that's my sysadmin-level understanding of what I've read here so far). And when talking about changing some Connector attributes, maybe a review should be made first, downwards as well as upwards : - downwards : ultimately a Connector represents a socket (or more than one ?), at the OS TCP/IP stack level. Some information from that OS-level socket presumably "filters up" through whatever layers there can be between it, and the container level and the Java servlets running inside that container. Is that information liklely to be used at the application level, and would proposed changes be neutral in that respect ? - upwards : it seems from the accumulated discussions here, that (for example) to implement some of the changes/improvement, users (sysadmins) may have to go as far as duplicating the whole Connector tag, to implement the "listen only on localhost" feature (but, that this depends both on the underlying OS and on the in-between layer between that OS and the Connector). And, if some application software currently "interrogates" the Connector to find out about its IP address (or the IP address of the client connected to it), what answer would it get if the "address" attribute would become multi-value ? /Could/ it even get such an answer, if the underlying socket is not one, but two ? I don't know the answer to the above questions, and I don't even know whether they really are valid questions. But again, I look at this from a sysadmin configurator point of view, without necessarily a deep understanding on the Java finery underlying all this, and I'm quite confused and worried that I could inadvertently break some user application and not really understand why. And maybe another underlying question : is it really unthinkable to have an AJP connection capable of running under SSL ? (I mean directly, not under some external setup like stunnel e.g.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
On 11.03.2020 09:30, Piyush Kumar Nayak wrote: What's the point of " ipv6v6only" attribute. The doc says : "If listening on an IPv6 address on a dual stack system, should the connector only listen on the IPv6 address? If not specified the default is false and the connector will listen on the IPv6 address and the equivalent IPv4 address if present." So if I set address to "::1" and " ipv6v6only" is left to its default, shouldn’t, the connector listen to both the addresses. I guess it depends on the precise meaning of "on a dual stack system" .. -Original Message- From: Martin Grigorov Sent: Tuesday, March 10, 2020 8:14 PM To: Tomcat Users List Subject: Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31 On Tue, Mar 10, 2020 at 3:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 3/10/20 04:43, Martin Grigorov wrote: We can define custom address like "loopback" for which Tomcat will bind on both "127.0.0.1" and "::1" depending on the values of java.net.preferIPv4Stack and java.net.preferIPv6Addresses, but I am not sure whether it is worth it This is kind of an interesting suggestion, as would maybe supporting "all" as an alias for both 0.0.0.0 and :: together (the old default behavior, which is no longer possible with a single ). Are there any examples of these kinds of things in other products, or does everyone just manually define two separate connector-like entities? httpd just does: Listen 0.0.0.0 Listen :: Which is pretty simple. Tomcat's configuration is a lot more verbose and so repeating it is doubly so. Another option is to make "address" attribute multi valued, e.g. comma/space separated. Martin - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5nnHEACgkQHPApP6U8 pFirYA/9HvjI2fX//oqTFvmgGXW/7memXkrUkMiQ3JrUhwc5KrSn4CJAamwiqzTr Lm+CACeEuiMK4qGbQ+NSpfql0k1pb8BUTX7Ut/KW1lsa8t/DY2DU0SNBw3mvnfL1 XoTsAbQgswpoxozZe11ZZyo42O2BCqTcO8Yp2X3K6DUAGvusPl00VMzpYfgsoLCv ZvxljLPRY5szRfCf7qrXOtPoByxvnKX2coQBIKJ8+MEKIo6ZApNX8OPf2HNGjvPT /OCRef/+uIXQaGIYOS8OlNxmFLEs/iGPZ2412l0rAA1hArlW4yCe7eDe3RCbiMeH FKHbqgbTRPNXWTqf3/BqEimcQj6YdXm+k019IDWGS7vhfPkiBci6qbKO9GLVjSct 4R9J++/s5CQp7zC3aM1kS5Paoho+CMevMneD0c6m4lGvM007jX4yr1z3QZxtFzqg KpcYieJgWGl0pOVw4s5YnngK1WXosb7gyjEN7ktPEE4xdeTk57shceGg1YDDRpyG n9gtwiXJf1zwUMOq0ttHNNvLdXL+y2Ud7adG5Sjg/5Y3RCP9vAQNdq+CcHS3aLGo WVfME5zcrSJlpD0arqg5ZNduYMAwgvO1GEnqfFEfEKpPXJNXAzX9YtCm0/ckFMC6 gB7xVv72Ow7kmsftA478+nPCiZTwmkVyLqVoOIr0+OSTn0tiDu0= =ewrT -END PGP SIGNATURE- - 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: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
What's the point of " ipv6v6only" attribute. The doc says : "If listening on an IPv6 address on a dual stack system, should the connector only listen on the IPv6 address? If not specified the default is false and the connector will listen on the IPv6 address and the equivalent IPv4 address if present. " So if I set address to "::1" and " ipv6v6only" is left to its default, shouldn’t, the connector listen to both the addresses. -Original Message- From: Martin Grigorov Sent: Tuesday, March 10, 2020 8:14 PM To: Tomcat Users List Subject: Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31 On Tue, Mar 10, 2020 at 3:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Martin, > > On 3/10/20 04:43, Martin Grigorov wrote: > > We can define custom address like "loopback" for which Tomcat will > > bind on both "127.0.0.1" and "::1" depending on the values of > > java.net.preferIPv4Stack and java.net.preferIPv6Addresses, but I am > > not sure whether it is worth it > This is kind of an interesting suggestion, as would maybe supporting > "all" as an alias for both 0.0.0.0 and :: together (the old default > behavior, which is no longer possible with a single ). > > Are there any examples of these kinds of things in other products, or > does everyone just manually define two separate connector-like entities? > > httpd just does: > > Listen 0.0.0.0 > Listen :: > > Which is pretty simple. Tomcat's configuration is a lot > more verbose and so repeating it is doubly so. > Another option is to make "address" attribute multi valued, e.g. comma/space separated. Martin > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5nnHEACgkQHPApP6U8 > pFirYA/9HvjI2fX//oqTFvmgGXW/7memXkrUkMiQ3JrUhwc5KrSn4CJAamwiqzTr > Lm+CACeEuiMK4qGbQ+NSpfql0k1pb8BUTX7Ut/KW1lsa8t/DY2DU0SNBw3mvnfL1 > XoTsAbQgswpoxozZe11ZZyo42O2BCqTcO8Yp2X3K6DUAGvusPl00VMzpYfgsoLCv > ZvxljLPRY5szRfCf7qrXOtPoByxvnKX2coQBIKJ8+MEKIo6ZApNX8OPf2HNGjvPT > /OCRef/+uIXQaGIYOS8OlNxmFLEs/iGPZ2412l0rAA1hArlW4yCe7eDe3RCbiMeH > FKHbqgbTRPNXWTqf3/BqEimcQj6YdXm+k019IDWGS7vhfPkiBci6qbKO9GLVjSct > 4R9J++/s5CQp7zC3aM1kS5Paoho+CMevMneD0c6m4lGvM007jX4yr1z3QZxtFzqg > KpcYieJgWGl0pOVw4s5YnngK1WXosb7gyjEN7ktPEE4xdeTk57shceGg1YDDRpyG > n9gtwiXJf1zwUMOq0ttHNNvLdXL+y2Ud7adG5Sjg/5Y3RCP9vAQNdq+CcHS3aLGo > WVfME5zcrSJlpD0arqg5ZNduYMAwgvO1GEnqfFEfEKpPXJNXAzX9YtCm0/ckFMC6 > gB7xVv72Ow7kmsftA478+nPCiZTwmkVyLqVoOIr0+OSTn0tiDu0= > =ewrT > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
