Re: Signature broken link.
On 14/01/2021 18:32, My Subs wrote: > Hello, > > The pgp signature link for v10.0.0 seems to be broken: > > https://downloads.apache.org/tomcat/tomcat-10/v10.0.0/bin/apache-tomcat-10.0.0.tar.gz.asc > > I keep getting a 404 on that address. Fixed. Mark > > Best, > > Alex > > > - > 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 server not considering Mime Type - Request urgent help!!
Swathi, On 1/13/21 03:27, Jonnalagadda, Swathi (External) wrote: We could see that when we try to open the xls file separately the browser shows dialogue box to save it so it is nothing to do with browser settings What is the difference between "open[ing] the XLS file separately" and ... whatever your application is doing instead? If you want to force a download, you need to add some response headers otherwise a normal browser will usually try to render the file in the browser window instead of initiating a download. The response header you need is "Content-Disposition" and its value can be complex. Here is what I usually do: Content-Disposition: attachment; filename="[filename]"; filename*=utf-8''[filename in UTF-8 encoding] Note that the above is all on one line and the two single-quotes are not a typo. You will also need to escape any double-quotes in the "filename" and escape any semicolons in the utf8-filename. You can find more information here as well as other places online: https://www.geeksforgeeks.org/http-headers-content-disposition/ The above reference happens to be particularly thorough, even moreso than Mozilla's (typically very good and complete) documentation for Content-Disposition. If your application is not being hosted within a web browser (e.g. it's a mobile application, or an Electron (etc.) application, etc.) then it's entirely up to you to trigger the display of a download dialog when this kind of thing needs to happen. -chris -Original Message- From: Mounika Reddy [mailto:spidermai...@gmail.com] Sent: Wednesday, January 13, 2021 3:48 AM To: Tomcat Users List Cc: Mark Thomas Subject: Re: Tomcat server not considering Mime Type - Request urgent help!! CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Pls check http response headers for the request to confirm if it's returning proper headers. Once they are in place then it may be to do with browser settings not processing headers. On Tue, Jan 12, 2021, 2:48 PM Jonnalagadda, Swathi (External) < swathi.jonnalaga...@xerox.com> wrote: Hi Team We have an application deployed in tomcat9.0.38 server which generates an xls file dynamically and saves at server end. When we try to access the file using application frontend, it is neither showing up in excel format nor showing up pop up to save the file instead it is showing the content of xls file in xml format directly on the browser. Below mime type is set both at web.xml of webapplicatio end and as well as Tomcat9038/conf/web.xml xls application/vnd.ms-excel Could you please help in resolving the issue ASAP Thanks Swathi - 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: Can we get Digest Authentication with TOMCAT 7
Mark and Ravi, On 1/13/21 04:59, Mark Thomas wrote: On 13/01/2021 09:36, Ravi Kumar wrote: Hi Tomcat Team, I am using a Tomcat based webserver container for our web application. All the deplyoment and other task taken care using TOMCAT 7.10.105. Tomcat 7.0.x will reach end of life on 31 March 2021. Currently we are using the BASIC Authentication for the Manager and tomcat web application. Can we migrate and use DIGEST Authentication for the same ? Yes. What are the suggested and recommended way to implement and using DIGEST Authentication with TOMCAT 7 web applications? Simply replace "BASIC" in the application's web.xml file with "DIGEST" Your valuable assistance is much appreciated. If you are storing passwords in digest form note the following: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#Digested_Passwords Generally, you are better off switching from BASIC+http to BASIC+https rather than DIGEST+http. +1 If you are already using BASIC+https then switching to DIGEST+https is unlikely to gain you anything. Switching to HTTP DIGEST authentication is a net loss in security because the passwords must be stored insecurely. Please note that there can be confusion between HTTP DIGEST authentication (which is an authentication scheme) and using "digested" (aka hashed) passwords in your password database. HTTP DIGEST precludes the use of (properly) digested passwords in your database, and digested (hashed) passwords in your password database is a Best Practice. With HTTP DIGEST authentication, the server must have access to the value of MD5(username:realm:password). This can either be done by storing the password in plaintext (insecure!) or storing the value of MD5(username:realm:password) which is also insecure. MD5(username:realm:password) is insecure because the MD5 hashing algorithm is considered weak and also both the username and realm name will be known to any potential attacker. Note that this criticism is not against HTTP DIGEST authentication itself, as the communication of the credential material can be considered secure even though it is using insecure cryptographic primitives (specifically, MD5). This is a criticism about the *storage requirements* on the server-side. If the user database were to be compromised, password recovery is not sufficiently mitigated because you cannot use proper hashing on the stored credentials. Industry best practices are currently to use "salted" and "iterated" hashes of stored credentials, neither of which can be used with HTTP DIGEST. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat server not considering Mime Type - Request urgent help!!
What everyone is telling you is browser is not seeing right headers.. You can modify your tomcat settings as well as apache2 settings to log outgoing content type header. If tomcat and apache2 headers match, problem is in your tomcat side. If there is a mismatch and tomcat is sending right headers. then problem is on apache2 side. You can directly connect to tomact using curl or even in the browser to bypass apache2 and see if it works. How is response returned? How do you set the extension of the file? You said file generated dynamically, are you sure your servlet or whatever service handler you have there is not sending incorrect header? I am not sure, but I believe global mime type settings are only for static files that tomcat serves. Any dynamically generated content has to be managed by response handler. More knowledgeable people here can correct me if I am wrong. Regards, Niranjan On 1/14/21 8:59 AM, Jonnalagadda, Swathi (External) wrote: Could you please elaborate more on this as to where I need to check From: Mounika Reddy Sent: Thursday, January 14, 2021 2:41 AM To: Tomcat Users List Cc: Mark Thomas Subject: Re: Tomcat server not considering Mime Type - Request urgent help!! CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you are via AJP connector, then check if Apache proxy is changing headers. We have a similar environment and when we set content-type, clients see the same but possible it must be overriding On Wed, Jan 13, 2021, 3:14 PM Jonnalagadda, Swathi (External) < swathi.jonnalaga...@xerox.com> wrote: This issue is not resolved yet. The extension of file is clearly .xls but I see content-type in response header is set to text/html. Please note that the request initially hits apache2.4 server which is redirected to tomcat9 server after successful authentication at siteminder. The connection is configured via ajp connector. Is there a possibility that the apache server is overwriting the content-type header in response ? Please advise. Thanks Swathi -Original Message- From: Jonnalagadda, Swathi (External) [mailto: swathi.jonnalaga...@xerox.com] Sent: Wednesday, January 13, 2021 1:57 PM To: Tomcat Users List Cc: Mark Thomas Subject: RE: Tomcat server not considering Mime Type - Request urgent help!! CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thank you for the email We could see that when we try to open the xls file separately the browser shows dialogue box to save it so it is nothing to do with browser settings Could you please advise if I am missing out any setting here. Thanks Swathi -Original Message- From: Mounika Reddy [mailto:spidermai...@gmail.com] Sent: Wednesday, January 13, 2021 3:48 AM To: Tomcat Users List Cc: Mark Thomas Subject: Re: Tomcat server not considering Mime Type - Request urgent help!! CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Pls check http response headers for the request to confirm if it's returning proper headers. Once they are in place then it may be to do with browser settings not processing headers. On Tue, Jan 12, 2021, 2:48 PM Jonnalagadda, Swathi (External) < swathi.jonnalaga...@xerox.com> wrote: Hi Team We have an application deployed in tomcat9.0.38 server which generates an xls file dynamically and saves at server end. When we try to access the file using application frontend, it is neither showing up in excel format nor showing up pop up to save the file instead it is showing the content of xls file in xml format directly on the browser. Below mime type is set both at web.xml of webapplicatio end and as well as Tomcat9038/conf/web.xml xls application/vnd.ms-excel Could you please help in resolving the issue ASAP Thanks Swathi - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Signature broken link.
Hello, The pgp signature link for v10.0.0 seems to be broken: https://downloads.apache.org/tomcat/tomcat-10/v10.0.0/bin/apache-tomcat-10.0.0.tar.gz.asc I keep getting a 404 on that address. Best, Alex - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat server not considering Mime Type - Request urgent help!!
Could you please elaborate more on this as to where I need to check From: Mounika Reddy Sent: Thursday, January 14, 2021 2:41 AM To: Tomcat Users List Cc: Mark Thomas Subject: Re: Tomcat server not considering Mime Type - Request urgent help!! CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you are via AJP connector, then check if Apache proxy is changing headers. We have a similar environment and when we set content-type, clients see the same but possible it must be overriding On Wed, Jan 13, 2021, 3:14 PM Jonnalagadda, Swathi (External) < swathi.jonnalaga...@xerox.com> wrote: > This issue is not resolved yet. The extension of file is clearly .xls but > I see content-type in response header is set to text/html. > > Please note that the request initially hits apache2.4 server which is > redirected to tomcat9 server after successful authentication at siteminder. > > The connection is configured via ajp connector. > > Is there a possibility that the apache server is overwriting the > content-type header in response ? > > Please advise. > > Thanks > Swathi > > -Original Message- > From: Jonnalagadda, Swathi (External) [mailto: > swathi.jonnalaga...@xerox.com] > Sent: Wednesday, January 13, 2021 1:57 PM > To: Tomcat Users List > Cc: Mark Thomas > Subject: RE: Tomcat server not considering Mime Type - Request urgent > help!! > > CAUTION: This email originated from outside the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > Thank you for the email > > We could see that when we try to open the xls file separately the browser > shows dialogue box to save it so it is nothing to do with browser settings > > Could you please advise if I am missing out any setting here. > > Thanks > Swathi > -Original Message- > From: Mounika Reddy [mailto:spidermai...@gmail.com] > Sent: Wednesday, January 13, 2021 3:48 AM > To: Tomcat Users List > Cc: Mark Thomas > Subject: Re: Tomcat server not considering Mime Type - Request urgent > help!! > > CAUTION: This email originated from outside the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > Pls check http response headers for the request to confirm if it's > returning proper headers. > > Once they are in place then it may be to do with browser settings not > processing headers. > > > > On Tue, Jan 12, 2021, 2:48 PM Jonnalagadda, Swathi (External) < > swathi.jonnalaga...@xerox.com> wrote: > > > Hi Team > > > > We have an application deployed in tomcat9.0.38 server which generates > > an xls file dynamically and saves at server end. When we try to access > > the file using application frontend, it is neither showing up in excel > > format nor showing up pop up to save the file instead it is showing > > the content of xls file in xml format directly on the browser. > > > > Below mime type is set both at web.xml of webapplicatio end and as > > well as Tomcat9038/conf/web.xml > > > > > > xls > > application/vnd.ms-excel > > > > > > Could you please help in resolving the issue ASAP > > > > > > Thanks > > Swathi > > >
Re: SingleSignOn does not log debug info?
Hello Mark,
Thank you very much!
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = ALL
does the trick for me:
/...
FINE [http-nio-8080-exec-5]
org.apache.catalina.authenticator.SingleSignOn.invoke SSO processing
request for [/manager/html]
.../...
Cheers,
Luis
El jue, 14 ene 2021 a las 17:04, Mark Thomas () escribió:
> On 14/01/2021 15:52, Luis Rodríguez Fernández wrote:
> > Hello there,
> >
> > I am trying to enable debug for
> > the org.apache.catalina.authenticator.SingleSignOn valve. In my
> > ${CATALINA_BASE}/conf/logging.properties I have set
> >
> > java.util.logging.ConsoleHandler.level = ALL
> > .../...
> > org.apache.catalina.authenticator.SingleSignOn.level = ALL
> >
> > In my ${CATALINA_BASE}/conf/server.xml I've uncommented
> >
> >
> >
> > After a successful authentication in one of my webapps I can see that the
> > JSESSIONIDSSO cookie has been created, so I would expect to see some of
> the
> > containerLog.debug(...) statements of theSingleSignOn.invoke() method.
> >
> > Also If I try with org.apache.catalina.authenticator..level = ALL I can
> see
> > in my catalina.out
> >
> > 14-Jan-2021 16:48:23.326 FINE [main]
> > org.apache.catalina.authenticator.AuthenticatorBase.startInternal Found
> > SingleSignOn Valve at
> > SingleSignOn[StandardEngine[Catalina].StandardHost[localhost]]
> >
> > So I see that my SSO valve has been enabled.
> >
> > Am I missing something?
>
> Because it is the container log, that is the logger you need to
> configure ...level=debug for, not the authenticator package.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
- Samuel Beckett
Re: SingleSignOn does not log debug info?
On 14/01/2021 15:52, Luis Rodríguez Fernández wrote:
> Hello there,
>
> I am trying to enable debug for
> the org.apache.catalina.authenticator.SingleSignOn valve. In my
> ${CATALINA_BASE}/conf/logging.properties I have set
>
> java.util.logging.ConsoleHandler.level = ALL
> .../...
> org.apache.catalina.authenticator.SingleSignOn.level = ALL
>
> In my ${CATALINA_BASE}/conf/server.xml I've uncommented
>
>
>
> After a successful authentication in one of my webapps I can see that the
> JSESSIONIDSSO cookie has been created, so I would expect to see some of the
> containerLog.debug(...) statements of theSingleSignOn.invoke() method.
>
> Also If I try with org.apache.catalina.authenticator..level = ALL I can see
> in my catalina.out
>
> 14-Jan-2021 16:48:23.326 FINE [main]
> org.apache.catalina.authenticator.AuthenticatorBase.startInternal Found
> SingleSignOn Valve at
> SingleSignOn[StandardEngine[Catalina].StandardHost[localhost]]
>
> So I see that my SSO valve has been enabled.
>
> Am I missing something?
Because it is the container log, that is the logger you need to
configure ...level=debug for, not the authenticator package.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
SingleSignOn does not log debug info?
Hello there,
I am trying to enable debug for
the org.apache.catalina.authenticator.SingleSignOn valve. In my
${CATALINA_BASE}/conf/logging.properties I have set
java.util.logging.ConsoleHandler.level = ALL
.../...
org.apache.catalina.authenticator.SingleSignOn.level = ALL
In my ${CATALINA_BASE}/conf/server.xml I've uncommented
After a successful authentication in one of my webapps I can see that the
JSESSIONIDSSO cookie has been created, so I would expect to see some of the
containerLog.debug(...) statements of theSingleSignOn.invoke() method.
Also If I try with org.apache.catalina.authenticator..level = ALL I can see
in my catalina.out
14-Jan-2021 16:48:23.326 FINE [main]
org.apache.catalina.authenticator.AuthenticatorBase.startInternal Found
SingleSignOn Valve at
SingleSignOn[StandardEngine[Catalina].StandardHost[localhost]]
So I see that my SSO valve has been enabled.
Am I missing something?
Thanks in advance,
Luis
ps: my environment looks like this (removing folder paths for brevity):
$ ./bin/catalina.sh version
.../...
Using CLASSPATH:
.../apache-tomcat-9.0.41/bin/bootstrap.jar:.../apache-tomcat-9.0.41/bin/tomcat-juli.jar
Using CATALINA_OPTS:
Server version: Apache Tomcat/9.0.41
Server built: Dec 3 2020 11:43:00 UTC
Server number: 9.0.41.0
OS Name:Linux
OS Version: 4.15.0-130-generic
Architecture: amd64
JVM Version:1.8.0_191-b12
JVM Vendor: Oracle Corporation
$ ps -ef | grep tomcat
.../...
...jdk1.8.0_191/bin/java
-Djava.util.logging.config.file=.../apache-tomcat-9.0.41/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager .../...
--
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
- Samuel Beckett
[SECURITY] CVE-2021-24122 Apache Tomcat Information Disclosure
CVE-2021-24122 Apache Tomcat Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.0.0-M1 to 10.0.0-M9 Apache Tomcat 9.0.0.M1 to 9.0.39 Apache Tomcat 8.5.0 to 8.5.59 Apache Tomcat 7.0.0 to 7.0.106 Description: When serving resources from a network location using the NTFS file system it was possible to bypass security constraints and/or view the source code for JSPs in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 10.0.0-M10 or later - Upgrade to Apache Tomcat 9.0.40 or later - Upgrade to Apache Tomcat 8.5.60 or later - Upgrade to Apache Tomcat 7.0.107 or later Credit: This issue was identified by Ilja Brander. History: 2021-01-14 Original advisory References: [1] https://tomcat.apache.org/security-10.html [2] https://tomcat.apache.org/security-9.html [3] https://tomcat.apache.org/security-8.html [4] https://tomcat.apache.org/security-7.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
