Re: [mod_jk] Is it possible to set the value of a specific attribute via HTTP?
Hi Chris, Am 29.06.23 um 15:00 schrieb Christopher Schultz: All, I've been using mod_jk forever and have some tools[1][2] to check on the status of a worker and change its state using the status worker. One of the samples I check is the "errors" count and if it's above 0 then I report an error to my monitoring system. The problem is that sometimes we just get a random error here or there, and my only recourse is to go into the status worker and "reset" the worker which clears out everything. That may not be a big deal because honestly I don't care what mod_jk thinks the estimated number of sessions on a particular node is, but what I'd prefer to do is bleed-off those errors over time. For example, we check the service every few minutes. If we have more than 0 errors, we start checking more frequently. If, every time we checked, we reduced the error-count by some small number, the count would eventually reach 0 if the event was temporary but it would continue to grow as long as there was some kind of persistent error (like Tomcat-node-is-down). Is there a way to decrement the "errors" count without resetting all counters back to zero? Thanks, -chris [1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do that. [2] https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin/mod_jk no, there is no way to change insdividual runtime counters. As always it would be possible to code it as an addition to the jk manager. One would have to think about which counters for which workers (lb, member, ajp) and whether one should be able to reset to 0, to adjust by some delta or whatever. I have not immediate intention to implement it, at this point just wanted to mention it is not there but doable. Since I try to push people into mod_proxy, I am hesitant to implement more and more features which keep people from switching ;) The last feature I added was putting a request id on the log lines (yet unreleased). Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
View Differences for Tomcat Configuration file versions
>From the following page, the View Differences button nolonger lists the >differences in versions of the Configuration file selected. tomcat.apache.org/migration-9.html#Upgrading_9.0.x Is there another way to easily view the differences?
Re: [SECURITY] CVE-2023-34981 Apache Tomcat - Information disclosure
On 29/06/2023 14:24, George Angeletos wrote: Hello, I presume this only affects setups using AJP connectors - right? Correct. Mark Thanks George On Wed, 21 Jun 2023 at 13:21, Mark Thomas wrote: CVE-2023-34981 Apache Tomcat - Information disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M5 Apache Tomcat 10.1.8 Apache Tomcat 9.0.74 Apache Tomcat 8.5.88 Description: The fix for bug 66512 introduced a regression that was fixed as bug 66591. The regression meant that, if a response did not have any HTTP headers set, no AJP SEND_HEADERS message would be sent which in turn meant that at least one AJP based proxy (mod_proxy_ajp) would use the response headers from the previous request for the current request leading to an information leak. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.0-M6 or later - Upgrade to Apache Tomcat 10.1.9 or later - Upgrade to Apache Tomcat 9.0.75 or later - Upgrade to Apache Tomcat 8.5.89 or later Credit: Hidenobu Hayashi and Yuichiro Fukubayashi of M3, Inc. History: 2023-06-21 Original advisory References: [1] https://tomcat.apache.org/security-11.html [2] https://tomcat.apache.org/security-10.html [3] https://tomcat.apache.org/security-9.html [4] https://tomcat.apache.org/security-8.html [5] https://bz.apache.org/bugzilla/show_bug.cgi?id=66512 [6] https://bz.apache.org/bugzilla/show_bug.cgi?id=66591 - 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: [SECURITY] CVE-2023-34981 Apache Tomcat - Information disclosure
Hello, I presume this only affects setups using AJP connectors - right? Thanks George On Wed, 21 Jun 2023 at 13:21, Mark Thomas wrote: > CVE-2023-34981 Apache Tomcat - Information disclosure > > Severity: Important > > Vendor: The Apache Software Foundation > > Versions Affected: > Apache Tomcat 11.0.0-M5 > Apache Tomcat 10.1.8 > Apache Tomcat 9.0.74 > Apache Tomcat 8.5.88 > > Description: > The fix for bug 66512 introduced a regression that was fixed as bug > 66591. The regression meant that, if a response did not have any HTTP > headers set, no AJP SEND_HEADERS message would be sent which in turn > meant that at least one AJP based proxy (mod_proxy_ajp) would use the > response headers from the previous request for the current request > leading to an information leak. > > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 11.0.0-M6 or later > - Upgrade to Apache Tomcat 10.1.9 or later > - Upgrade to Apache Tomcat 9.0.75 or later > - Upgrade to Apache Tomcat 8.5.89 or later > > Credit: > Hidenobu Hayashi and Yuichiro Fukubayashi of M3, Inc. > > History: > 2023-06-21 Original advisory > > References: > [1] https://tomcat.apache.org/security-11.html > [2] https://tomcat.apache.org/security-10.html > [3] https://tomcat.apache.org/security-9.html > [4] https://tomcat.apache.org/security-8.html > [5] https://bz.apache.org/bugzilla/show_bug.cgi?id=66512 > [6] https://bz.apache.org/bugzilla/show_bug.cgi?id=66591 > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
[mod_jk] Is it possible to set the value of a specific attribute via HTTP?
All, I've been using mod_jk forever and have some tools[1][2] to check on the status of a worker and change its state using the status worker. One of the samples I check is the "errors" count and if it's above 0 then I report an error to my monitoring system. The problem is that sometimes we just get a random error here or there, and my only recourse is to go into the status worker and "reset" the worker which clears out everything. That may not be a big deal because honestly I don't care what mod_jk thinks the estimated number of sessions on a particular node is, but what I'd prefer to do is bleed-off those errors over time. For example, we check the service every few minutes. If we have more than 0 errors, we start checking more frequently. If, every time we checked, we reduced the error-count by some small number, the count would eventually reach 0 if the event was temporary but it would continue to grow as long as there was some kind of persistent error (like Tomcat-node-is-down). Is there a way to decrement the "errors" count without resetting all counters back to zero? Thanks, -chris [1] Hmm... I haven't put my check_mod_jk.py upon GitHub. I should do that. [2] https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bin/mod_jk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Get Client Certificate Information
Hi Timothy
Sorry, I'm a little late to the party for a reply.
On an older project, when pulling cert info (using javax), we grabbed it from
the session, not the request, even though the attribute name says "request".
HttpSession session = httpRequest.getSession();
Object rawSubject = session.getAttribute (
"javax.servlet.request.X509Certificate" );
Not sure if that's relevant to or helps with your situation.
--
Cris Berneburg
CACI Senior Software Engineer
-Original Message-
From: Timothy Ward
Sent: Wednesday, June 21, 2023 4:57 PM
To: Tomcat Users List
Subject: Re: Get Client Certificate Information
EXTERNAL EMAIL - This email originated from outside of CACI. Do not click any
links or attachments unless you recognize and trust the sender.
import javax.servlet.http.HttpServletRequest;
import javax.security.cert.Certificate;
import javax.security.cert.X509Certificate;
public class GrabCert extends Object
{
public static String getCommonName()
{
try
{
X509Certificate[] certs = (X509Certificate[])
HttpServletRequest().getAttribute("jakarta.servlet.request.X509Certificate");
}
catch (Exception ex)
{
System.out.println("Exception caught in getCommonName:");
ex.printStackTrace();
}
}
}
This end up getting:
[Error] (1: 0): GrabCert:48: error: cannot find symbol
[Error] (1: 0): X509Certificate[] certs = (X509Certificate[])
HttpServletRequest().getAttribute("jakarta.servlet.request.X509Certificate");
[Error] (1: 0): ^
[Error] (1: 0): symbol: method HttpServletRequest()
[Error] (1: 0): location: class GrabCert
[Error] (1: 0): 1 error
On Wed, Jun 21, 2023 at 2:32 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Timothy,
>
> On 6/21/23 13:55, Timothy Ward wrote:
> > Not sure it's lined up right, lost in copy/paste I think, the ^
> > seems to
> be
> > initially under the (X509Certificate[]) right before the
> > getHttpServletRequest(), so I thought it didn't like the
> > getHttpServletRequest itself, maybe it doesn't like the getAttribute
> method.
>
> The compiler tells you 100% it's getHttpServletRequest.
>
> You didn't post the rest of the code, so we have no idea what kind of
> class this code exists in. My guess is that whatever class this code
> is in does not have a getHttpServletRequest() method to call.
>
> If you can post more code, we may be able to help.
>
> -chris
>
> > On Wed, Jun 21, 2023 at 1:52 PM Rob Sargent
> wrote:
> >
> >>
> >>
> >>> On Jun 21, 2023, at 11:29 AM, Timothy Ward
> >>>
> >> wrote:
> >>>
> >>> I tried the following:
> >>>
> >>> import javax.servlet.http.HttpServletRequest;
> >>> import javax.security.cert.Certificate; import
> >>> javax.security.cert.X509Certificate;
> >>>
> >>> X509Certificate[] certs = (X509Certificate[])
> >>>
> >>
> getHttpServletRequest().getAttribute("jakarta.servlet.request.X509Cert
> ificate");
> >>>
> >>> and I'm getting:
> >>>
> >>> [Error] (1: 0): GrabCert:33: error: cannot find symbol,
> >>> [Error] (1: 0): X509Certificate[] certs = (X509Certificate[])
> >>>
> >>
> getHttpServletRequest().getAttribute("jakarta.servlet.request.X509Cert
> ificate");,
> >>> [Error] (1: 0): ^,
> >>> [Error] (1: 0): symbol: method getHttpServletRequest(),
> >>> [Error] (1: 0): location: class GrabCert, [Error] (1: 0): 1 error
> >>>
> >>
> >> If I lined that up correctly, it seems to be pointing at “getAttribute”.
> >> Is your getHttpServletRequest giving you what you expect?
> >>
> >>
> >> ---
> >> -- 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
>
>
This electronic message contains information from CACI International Inc or
subsidiary companies, which may be company sensitive, proprietary, privileged
or otherwise protected from disclosure. The information is intended to be used
solely by the recipient(s) named above. If you are not an intended recipient,
be aware that any review, disclosure, copying, distribution or use of this
transmission or its contents is prohibited. If you have received this
transmission in error, please notify the sender immediately.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Tomcat Deployment scripts
Hello Alan, > Von: Alan F > Gesendet: Mittwoch, 28. Juni 2023 18:24 > An: users@tomcat.apache.org > Betreff: Tomcat Deployment scripts > > Anyone have an example deployment script or method used to deploy a simple > war and context root, also with rollback preferably. > > Thanks you could use tomcat-manager. A war file can be deployed using curl for example: https://stackoverflow.com/questions/4432684/tomcat-manager-remote-deploy-script Greetings, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
