Re: Tomcat Clustering Support
On 15/08/18 20:52, Mark Thomas wrote: > On 15/08/18 20:43, Scott Evans wrote: >> Hi, >> >> Our system is on Apache Tomcat Version 8.0.47. >> OS is Windows Server 2012 R2 Datacenter. >> >> We are looking for someone that may be interested in paid contract work to >> assist with troubleshooting and resolving a Tomcat clustering issue in our >> system. >> >> The system is composed of multiple Java PrimeFaces applications running in >> a clustered Tomcat environment which is experiencing occasional >> deadlocking issues from an unknown source requiring the Nodes to be cycled >> in order to resolve. The issue is only occurring in our Production >> environment and we've determined that the issues are occurring at random >> with the replication threads. >> >> We would need someone to help investigate our configuration and determine >> if there are any further changes that can be made to our system to catch >> these deadlock issues before they occur (requiring a Node cycle). >> >> Please let me know if you or someone you know may be interested or if you >> have further questions I can help answer. > > If you can provide a thread dump of the deadlock when it occurs we can > probably help you here for free. Scott provided me with a sanitised copy of the thread-dump off-line. I'm sharing my analysis with the list (with Scott's permission) as I think the root cause is likely to be of wider interest. There was, indeed, a deadlock. The issues was follows. The application is using JSF. Specifically, the Mojarra implementation from Oracle. There are multiple concurrent requests for the same session. Each request is processed by a dedicated thread (this is mandated by the Servlet spec although it may not be expressed that way). The threads in question are: A. ajp-apr-8009-exec-9005 B. ajp-apr-8009-exec-9000 Thread A is in the middle of processing a request. It is evaluating some EL which requires access to the view map which in turn causes the ViewMap to update the session. com.sun.faces.application.view.ViewScopeManager.processEvent locks the ViewMap object. It then tries to update the session. To do this it requires the session lock. Thread A is waiting for this lock. Thread B is at the end of a request. The session has been updated and it is attempting to write the updated session attributes to the cluster. The session lock has been obtained. The individual attributes are being written. The code has reached the ViewMap object. In order to write this object, the ViewMap object must be locked. Thread B is waiting for this lock. So, thread A holds the lock that thread B wants and is waiting for the lock thread B is holding. Thread B holds the lock the thread A wants and is waiting for the lock thread A is holding. Deadlock. This is, in essence, cause by a combination of how Tomcat's clustering is designed and Mojarra is implemented. The application is using the BackupManager. I assume with sticky sessions. Therefore, I would expect session failover between nodes to be a rare event. My recommendation is to investigate excluding the ViewMap from the replication via sessionAttributeNameFilter. You'd need a regular expression that matched anything except "com.sun.faces.application.view.activeViewMaps" I don't know how integral this object is to Mojarra. Mojarra may simply recreate this object if required. If not, you may need to trigger recreation after failover. I don't know how feasible this solution is. This will require some testing and possibly code changes. Has anyone on the users list come across this problem before? If so, how have you solved it? Suggestions for alternative solutions also welcome. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect
On 08/10/18 21:55, Michael Yoder wrote: > On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas wrote: >> CVE-2018-11784 Apache Tomcat - Open Redirect > > Is it possible to get more information on the "specially crafted URL"? > I'd like more information so that I can test if some of our apps are > vulnerable. Generally, there is a balance to strike here between making it easy for the less technically competent attackers to construct an attack and making it easy for end users to figure out if they are vulnerable. The way we typically do this is by describing the conditions necessary for an attack to be possible as completely as possible but not providing details of how to perform an attack. We also provide references to the commit that fixed the issue. For someone with the right skills, there is usually enough information in the description and the commit for a successful attack to be reverse engineered. > In addition, I'd like to verify that the value of > mapperContextRootRedirectEnabled defaults to "true", For the latest release of each supported Tomcat version, that is correct. Historically, that is version dependent. Check the docs for the version you are using. > so if we don't > alter that value we aren't susceptible? Incorrect. As per the announcement both mapperDirectoryRedirectEnabled and mapperContextRootRedirectEnabled need to be true to avoid this vulnerability if you are not using a fixed version. The default for mapperDirectoryRedirectEnabled is false. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
To Support at Tomcat, Got an issue Finding Maths.
I have spent many hours searching for a organised way to ask for a
Public void setter(double value){
Value = Maths.sin(param1);
}
Here is an example of files used from Java to JSP.
[Calculus Beanjava – Measures.jsp]
Nothing has been compatible, is there a licence restriction?
Ian burton.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark and Michael, On 10/10/18 05:15, Mark Thomas wrote: > On 08/10/18 21:55, Michael Yoder wrote: >> On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas >> wrote: >>> CVE-2018-11784 Apache Tomcat - Open Redirect >> >> Is it possible to get more information on the "specially crafted >> URL"? I'd like more information so that I can test if some of our >> apps are vulnerable. > > Generally, there is a balance to strike here between making it easy > for the less technically competent attackers to construct an attack > and making it easy for end users to figure out if they are > vulnerable. The way we typically do this is by describing the > conditions necessary for an attack to be possible as completely as > possible but not providing details of how to perform an attack. > > We also provide references to the commit that fixed the issue. For > someone with the right skills, there is usually enough information > in the description and the commit for a successful attack to be > reverse engineered. It doesn't look like Sergey has posted anything (that I can find) that might be called a full disclosure. If he had, I'd point it out. If I were you, I'd just make sure that you either (a) upgrade or (b) use the existing settings to mitigate the potential problem, as described in the announcement. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+C0QACgkQHPApP6U8 pFhCJQ/9Gw/G8dw46y4ItHFCsPTDiTxGenxMmVAlxt7kisblb8H3o9vK8PU96+PD Nb44/Vf5hp5XKN5Xuu3czyNjQ2l0QFb/WxZyqSnlWPEWOQs7a6ZFez9MQZ1W1H13 t6qRCSgcOWcrHvXBKjshspHzY6XeQq2Q5kzHntbVZKjQMQif/Cd73XYX0/GIukcF 4tKhQIXRNh99/NOsw6Ot+DgVjksVhVgg62sOuAe7gUh/UNginc07JvYBa9rKgAz+ JP3Z+PvUyCJFzGSoT1cYAniU+ZNiayquEmMxVeJ4VX6ZK2PMhPjEt58yD3NTOCaN fAE7ct9UICZ8g9WP22OcTAfaYgUSBGSCOxd7DkqM/o06Lv2bTsiWYtOr8bhHNnrO S7hJJ5a6Tm7TbN4Insm+BQhvts5FeDAsKM92TWGTrAZ52LEhdS2twsRcmCQDE69z +mmjRTl+W9UTxl6JTmDHj10d/aWYaA3f2SpZ4A18rRP4JSXQm7Ls/st8hR/TwdKC LsQ9RnmrDLgtSyql9keWhwaD28iQix5KgfFXOLrByCByzORnbP3z9VEu1knO1r1f Voe8wq8lDf56vRsr5VjjqSgmkeabtz8uxymOSbt8b3spQ6Q2J7y86MDA3/I7ZjTx cqgS2JyYAgtlD6vyiNeYRG14XBly3vFZeoCmw6CKFSTFSdK8r3I= =2IHD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: log4j: Logging to same file from multiple contexts?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 10/8/18 14:27, David Filip wrote:
> Dear Tomcat Users,
>
> Apologies if this is more of a log4j question, but I thought that
> I'd start here, in case Tomcat has any easy remedies.
>
> I have a common webapp that I deploy to multiple, different
> contexts.
>
> In log4j.properties, I have a few different log files defined,
> e.g., for logins:
>
> log4j.appender.logins=org.apache.log4j.DailyRollingFileAppender
> log4j.appender.logins.file=${catalina.home}/logs/logins.log
> log4j.appender.logins.datePattern='.'-MM-dd
> log4j.appender.logins.append=true
> log4j.appender.logins.layout=org.apache.log4j.PatternLayout
> log4j.appender.logins.layout.ConversionPattern=[%d{MM/dd/
> HH:mm:ss}] [%p] [%C{1}]: %m%n
>
> log4j.logger.com.colornet.CAP.Actions.LoginAction=info, logins
> log4j.logger.com.colornet.CAP.Util.LoginTokenTag=info, logins
>
> However, as you may have guessed, if I have the same log4j
> configuration file for each context, the contexts tend to
> over-write each other.
>
> Is there any way to have the SAME log4j.properties deployed too
> multiple contexts play nicely and not overwrite each other, but
> merely append each other?
>
> Extra credit question (although sounds even more like a log4j
> question, so apologies): If not, is there any way to define the
> file path, e.g.:
>
> log4j.appender.logins.file=${catalina.home}/logs/logins.log
>
> to include the specific context? I have found a few references on
> the 'Net, e.g., ${contextPath}, ${servletName}, etc., which don't
> seem to work.
>
> My goal (desire?) is to have the same webapp and configuration and
> web.xml and log4j.properties, etc., deployed to every web context,
> but not have one context overwrite another content's entries.
>
> Of course, as the Mick once said, "You can't always have what you
> want".
>
> Please let me know if this is possible.
I'm not sure it's really a great idea to have all these separate
context logging to the same log file(s), but here is a way to do this:
1. Move (*move!*) your log4j.jar file from WEB-INF/lib to Tomcat's
lib/ directory
2. Move (*move!) your log4j.properties file from WEB-INF/classes to
Tomcat's lib/ directory. You may have to wrap it in a JAR file.
This ought to allow log4j to initialize a single time, and each
application will use that singly-initialized log4j instance.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+EwQACgkQHPApP6U8
pFjKIA//UL0KHt11kczm28Yv9Ab9WbdHXxnG3dqC25q+HTA1Eq5wu/pTfCGPoa03
R4Sc5r3HpapyeMtZR1XFCPVFPAgbiHQeCD7Bkduw0bCKV8ZOvRJJOgqiXHYiW0cF
RuThsq/txShzRZ1KLqGOuZvfA6MsjIEXdWNdnbSH5g5lDT1mRsabzEpdqbkWXc8W
wru1VWZBNHQwU1k1wZ7ts1jVKZQzJhcO1scs/RWXIHNs8R+dADNsWcsqWzYyeuAm
nWYfhsN03/ilQwBjpAqDBsSnt7a3TvLW4Zh9XrcJylHenOdewj53MdL4AnjS7zUS
+TL3xHB+y8GEIUEsxuuAZy0sKVoPfApEHVovp6cTXzSUi+4fn+gBG2E0zL2o87GD
dfoBsgN3gpMw3oGqB2C67El/ECLIVdo6gU/kw1Pq/asMJPwFMK9OPWk06ScXec7n
ff52KuNt9Oedsm12J7d/GkfMb/8KtvTvzRI30FVf5phCvdkZrOPA0Nsuy40z+jcI
vOwIVcqONUDuG1rkD6Qnm5KwoBDJfkkNTy7BxJS5qtQmCV3dUDm3vvcm5cNzFXlK
b5yvp7UvAPyg13AdjGQd6C0rtG8p+RtTmwJvEZU4bQ16ZYWyQUDhVdLAnvgjb9Iv
jJxF2gAvcLxoqMnEh2AdWCSJjfrQkrZi/4vAYaFYK60EMnElh4w=
=5bwl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TLS1.3 support for tomcat 7 with APR/tomcat-native
Thanks Cristopher, I already did. All that´s left is to get the latest patch backported to tomcat 7 От: Christopher Schultz Отправлено: 10 октября 2018 г. 17:47:47 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for tomcat 7 with APR/tomcat-native -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Усманов, On 10/6/18 17:27, Усманов Азат Анварович wrote: > I've been searching the web for any idea why Chrome can do throw > empty response error with tls1.3 and found this bug > https://bugzilla.redhat.com/show_bug.cgi?id=1619389 at fedora , it > looks like the same sort of a problem,Interestingly enough it does > have a fix. My knowledge of C is quite limited, so could anyone > please look at the patch provided by these guys and see if it is > of any use in case of tomcat-native ? Have a look at the recent bug comments, especially Rainer's comment about Chrome/ff versions. - -chris > От: Усманов Азат Анварович > Отправлено: 25 сентября 2018 г. 11:39 Кому: > Tomcat Users List Тема: Re: TLS1.3 support for tomcat 7 with > APR/tomcat-native > > Do I need to file a separate feature request for Tomcat itself? The > one I already > filed(https://bz.apache.org/bugzilla/show_bug.cgi?id=62748) is for > tomcat-native component. I looked through Tomcat changelog, I've > found that previously TLS1.2 support was added via enhancement > request to tomcat native . > (https://bz.apache.org/bugzilla/show_bug.cgi?id=53952) > От: Усманов Азат Анварович > Отправлено: 20 сентября 2018 г. 12:05:07 Кому: > users@tomcat.apache.org Тема: Re: TLS1.3 support for tomcat 7 with > APR/tomcat-native > > I did file a feature -enhancement in bugzilla > > https://bz.apache.org/bugzilla/show_bug.cgi?id=62748 > > От: Christopher Schultz > Отправлено: 19 сентября 2018 г. > 23:31:28 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for > tomcat 7 with APR/tomcat-native > > Усманов, > > On 9/19/18 05:56, Усманов Азат Анварович wrote: >> Hi Christopher! I did remove supportedProtocols attribute >> entirely (SSL Labs server test confirms it ). > You mean that SSL Labs then tells you that other protocols are > available (e.g. TLSv1.0, etc.)? SSL Labs should tell you if TLSv1.3 > is available, so testing with e.g. Chrome shouldn't be necessary. > >> > maxPostSize="10485760 " maxHttpHeaderSize="1048576" >> protocol="org.apache.coyote.http11.Http11AprProtocol" >> connectionTimeout="2" redirectPort="8443" >> SSLHonorCipherOrder="true" >> SSLCertificateFile="/home/idis/STAR_ieml_ru.crt" >> SSLCertificateKeyFile="/home/idis/server.key" >> SSLCertificateChainFile="/home/idis/authorities.crt" > >> maxThreads="350" minSpareThreads="25" SSLEnabled="true" >> enableLookups="false" disableUploadTimeout="true" >> acceptCount="100" scheme="https" secure="true" >> compression="force" >> SSLCipherSuite="TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA384,T L > >> S_AES_128_GCM_SHA256,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-GC > M-SHA384,ECDHE-ECDSA-AES256-GCM-SHA256,ECDHE-RSA-AES256-GCM-SHA384,ECD HE > > - -RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES128-GCM-SHA256, >> ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-SHA384,ECDHE-RSA-AES25 6 > >> - -SHA384,ECDHE-ECDSA-AES128-SHA256,ECDHE-RSA-AES128-SHA256, > > > ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES256-SHA"/> > >> I did put >> TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA384,TLS_AES_128_GCM_S H > >> A256 >> as tls 1.3 ciphers for tls 1.3 , so my guess is that more work >> is required for tls.1.3 to work in my case > > Yes, you will definitely have to mention the TLSv1.3 ciphers in > order to allow a TLSv1.3 handshake to succeed. > > But yes, it does indeed look like Tomcat requires some work. > > Can you please file an enhancement request in Bugzilla? > > Thanks, -chris > >> От: Christopher Schultz >> Отправлено: 18 сентября 2018 г. >> 23:27 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for >> tomcat 7 with APR/tomcat-native > >> Усманов, > >> On 9/18/18 6:43 AM, Усманов Азат Анварович wrote: >>> I have a java7 web application that runs on tomcat 7.0.70 I'm >>> using Apr/tomcat-native w OpenSSL for TLS connections >>> .(Tomcat-native 1.2.17 APR 1.6,OpenSSL 1.1.1 RHEL 6 ) Latest >>> stable OpenSSL release (1.1.1) has TLS 1.3 support ,I have >>> upgraded to it successfully. My question is if and when >>> tomcat 7 will be upgraded to support TLS1.3 through w >>> APR/tomcat-native/OpenSSL? do such plans even exist? > >> Try not specifying any "supported protocol" (e.g. allow all >> protocol flavors), and OpenSSL should allow TLSv1.3 to be >> negotiated. > >>> I'm guessing it will not happen at least untill both Chrome >>> and firefox release theirbrowser updates for RFC8446 >>> support (which are both scheduled for Mid october Crome 70 and >>> firefox 63) but would like to know more about it > >> I for
Re: To Support at Tomcat, Got an issue Finding Maths.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ian,
On 10/10/18 06:19, Ian Burton wrote:
> I have spent many hours searching for a organised way to ask for a
>
> Public void setter(double value){
>
> Value = Maths.sin(param1);
>
> }
>
> Here is an example of files used from Java to JSP.
>
> [Calculus Beanjava – Measures.jsp]
>
> Nothing has been compatible, is there a licence restriction?
It's unclear what you're asking, here.
Can you explain a little more what you are trying to do?
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+Ci0ACgkQHPApP6U8
pFi2og//VUVPW1xIV7mRbuYhLZOc3Um8YdsBYhH+ynQ14a77XyZPlhF6wslsIXmD
7eF3Ese1Sqvj2rYjuWch7+Wh/AVPKMST1MOossMtpP+br5txC22795/D86ypv0xU
qRUQ0n3INYsLRCuzlZfU97ibhLCQQgv05bFOlydBoKrUyjha5mHCkicpxm365//Y
iS/39vvTg0M2oaLGii5g0lD8LPUZy+trj7XTOmxcsmqNZpTFwHWZkFsFtv0VA7TM
nbxmuvYthPwFgPeL/y7e82A+VwT7Un6K9XplycqWwjpd8bBM2Cmpa1nIObK4uBoK
GnLbbWag4BNswEdE9VjT+3MeLdRI6dVT4C683emhCclzZqVKUge97inXtr04X6lh
qIr/YPDrlk/+0yzEbltgBnjVUurzstL/Atx9I2edgAmPxPusUuzXLiRoPxuNG68A
rIenPoDGtzrGBbN093fYXSgqnkMoDxGAvVNTdUsmgJ1I5+5FVimnDOelv0DYjvcM
j3HtfoPIn2/gBWRGeYsrgMowQ0E4CgSMv6EocCt4fWtfSQGfT4hIaXNer0qDQgJo
qyQI96jfhB7J1m34+Ux6ZSCZeRAxndehclWqp26tSs34VeTtVt8nm8o62t1ehtOs
G3KkwxKKEfWwtMR4/+p/BKJCNnSkZ1HxSu7rIpP2fL/PCeMrRh4=
=TJbJ
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat JNDI Authentication - No Login
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Lee,
On 10/9/18 08:11, Lee Broom wrote:
> Hello My aim is to introduce a domain level
> authentication/authorisation security layer when accessing the
> http://localhost:8080/sample/ application. I don't want this web
> application to be openly accessible and without challenging an
> operator.
You should be using HTTPS. This won't cause an erorr, but it is not a
secure configuration.
> After a frustrating and fruitless week I now reach out to the
> apache community for assistance because I have been unsuccessful
> enabling this function. The current behaviour is that
> http://localhost:8080/sample does not throw a login prompt.
>
> I can only assume it is caused by my Apache Tomcat code snippet
> configuration is all wrong. I am running version Apache
> Tomcat/7.0.91 on Redhat 7 in an ec2 AWS instance. I have installed
> and integrated Winbind on the OS and is happily talking to my AD
> domain example.com. Confirmation of this is realm connecting
> successful, I can see groups and users and I have masked the domain
> format 'example/user1' so it appears as 'user1'. Other factors; 1)
> I have found similar issues posted by others but none of the
> solutions worked for me 2)There are no errors found within
> /usr/local/tomcat7/logs/.
If you have the option, I'd use a more recent version of Tomcat. It
sounds like you are starting from scratch, so using e.g. Tomcat 9
should not represent too much of a burden.
> I had downloaded and installed sample.war from
> https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/ into my
> tomcat installation /usr/local.tomcat7/webapps/ directory.
>
> I would appreciate any assistance or a hefty kick in the right
> direction.
>
> There are 3 files in total that I have attempted to configure;
> /conf/server.xml, /webapps/sample/WEB-INF/web.xml &
> /conf/tomcat-users.xml
>
> My JNDI Realm entry in /usr/local/tomcat7/conf/server.xml
> configuration looks like this:
> --
-
>
>
debug="99"
What's the "debug for?
> connectionURL="ldap://example.com:389;
You should be using LDAPS. This won't cause an error, but it is not a
secure configuration.
> authentication="simple" referrals="follow"
> connectionName="ou=users,ou=lab,dc=example,dc=com"
> userSearch="(sAMAccountName={0})" userBase="dc=example,dc=com"
> userSubtree="true" roleSearch="(member={0})" roleName="cn"
> roleSubtree="true" roleBase="ou=users,ou=lab,dc=example,dc=com" />
This all looks okay to me at first glance, but I haven't set up Tomcat
LDAP authentication before.
Where is your defined in conf/server.xml? Within the
or where your application will live? If not, it needs to be in
one of those places. If you just replaced the existing from
the stock conf/server.xml file, then you should be good.
> --
-
>
> Also, I have commented the following:
> --
-
>
>
> --
-
>
> My /usr/local/tomcat7/webapps/sample/WEB-INF/web.xml file looks
> like this:
> --
-
>
>
> http://java.sun.com/xml/ns/j2ee;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version="2.4">
>
> Hello, World Application
> This is a simple web application with a source code
> organization based on the recommendations of the Application
> Developer's Guide.
>
> HelloServlet
> mypackage.Hello
>
> HelloServlet
> /hello
>
>
> Entire Application
> /*
>
You have a security-constraint which covers the entire URL space and
does not require any user roles. As explained in [1]:
"
An authorization constraint establishes a requirement for
authentication and names the roles authorized to access the URL
patterns and HTTP methods declared by this security constraint. If
there is no authorization constraint, the container must accept the
request without requiring user authentication.
"
I believe this is the core of your problem.
>
>
> All Users
> All
> Users /*
>
> User
>
You have mapped a second security-constraint to the same URL space.
> Admin Users
> Admin
> Users /*
>
> Admin
>
You have mapped a third security-constraint to the same URL space.
In case of a conflict, I believe the "let everyone in" constraint,
specified first above, will win.
> Webapp Admins
> Admin domain
> admins
>
> Webapp Users
> User domain users
>
>
> BASIC
> /sample/login.html
> /sample/error_login.jsp
>
>
>
> --
-
>
> The only change
Re: Redirecting to https URL when https port is accessed with http scheme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martynas, On 10/6/18 06:31, Martynas Jusevičius wrote: > see also this thread: > https://mail-archives.apache.org/mod_mbox/tomcat-users/201808.mbox/%3C cae35vmwcm9dkxmvabofgjb5d_oa07a6mrjxwcgknksbzgjh...@mail.gmail.com%3E > > I did this with front nginx eventually. In this case, Ettra is wanting to make an HTTP request to an HTTPS service, which usually just fails to establish a TLS handshake. Instead of failing, Ettra would prefer to have Tomcat respond with an HTTP response with no encryption. This is how Apache httpd currently behaves: === CUT === $ telnet localhost 443 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET / Host: localhost HTTP/1.1 400 Bad Request Date: Wed, 10 Oct 2018 14:52:08 GMT Server: Apache/2 Content-Length: 432 Connection: close Content-Type: text/html; charset=iso-8859-1 400 Bad Request Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Apache/2 Server at phobos.chadis.com Port 443 Connection closed by foreign host. === CUT === Tomcat will simply close the connection in its current implementation. - -chris > On Sat, Oct 6, 2018 at 7:29 AM ettra lancelot > wrote: >> >> Thank you for the detailed answer, Chris. >> >> On Sat, Oct 6, 2018 at 2:41 AM Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> > Etcy, > > On 10/5/18 14:57, ettra lancelot wrote: > I would like to know whether it's possible to configure > tomcat to automatically redirect to the https URL when > https port is access using http scheme instead of https*.* > > There is no way to get Tomcat to do this for you right now. > > There is, however, the possibility of adding such a feature to > Tomcat. > > If you make an HTTP request to Apache httpd on a TLS-enabled port, > you'll get a response that says "Looks like you made a mistake". > > In the past, that would have been a huge pain in the neck for > Tomcat, since the TLS handshake was handled *entirely* by the > underlying crypto system (e.g. JSSE or APR/OpenSSL). AIUI, that > code has been re-written and Tomcat is buffering everything > internally and probing the handshake, etc. > > It should therefore be possible to respond in the way you > describe, but I'm not sure how much appetite there is for issuing a > redirect rather than just an informational page such as the one > httpd returns. > > Unfortunately, Bill is incorrect when he says that you can write a > Filter for this. No application code will ever see a connection > over a connection which failed a TLS handshake. > > -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 > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+El4ACgkQHPApP6U8 pFh7BA//WfMVYmUI97gCsgHuNIVwUbDnFYYJaiefGkexhW+ujQTqP+WeqPO4YJYW FqZ2d2ZJ+e6VWfb9poB9c/couTh9shyIefPGE6CBXLD0AaWXdbT6s9fzQEq9803f G3w9AnK20r4tCcE4bZkz5NWGcnvII8LVr78PR/QEuCkKMlabSMZ1hY12XrPXUO/3 IjGBdiuEqedLAOxrqp65ZXbZ5hKA5UXYSxIxrT+PN52TpncmIpVecJO29yjrTIAo cBFOoOqYP0I1ylvSTRTPMsk+1pNE9V+KxIyqwxGC24gJvE/x0U+xvvehj5NUlsFz IwHRolJ1iQYtE1OONEQ1jDtqGUjllme3JJ79cZFRDbhUgMum+4V91bK9Oou6Lrwq 85oIudC2kFc9CMoq7QocOaTJTMNVwLj2/xHZIO4tPXw7S1Tw3eHEyqe6vReWDlKf B7qQTqgA2EKFp3BZOLV94IazMxK/Gf5lBFyL9f9j4OVKunEiJ9NSNjmwB23vhsNT Kmz/RyvRHd0EF4127YwUqjVQqOeWfhnNivZRf4GQGX1AbrcrJBfVOgp60z+VI9lD iO/5u+zeFflocbvDHxEfDfWZZYdB1XXdH16ug6n6BaoERs/gRRNFAuEqP4Qk5joI CfDz3SDdaqI+Ve0PXMOINxm3EqtdgpCo5l6tl3U2h/ITxijYr4Q= =ULFh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 8.5 cachingAllowed=false ramifications?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cris, On 10/9/18 11:59, Berneburg, Cris J. - US wrote: > Thanks Chris > > cjb> of TC 8.5.32 on Java 8u181, report output Excel cjb> files > won't load (immediately). An error is cjb> displayed to the user. > [...] cjb> 1. What are the ramifications of disabling the cache? > cjb> IOW, what are the potential side-effects? [...] cjb> 2. Is > there a "better" way to specify the setting? [...] cjb> 3. Is there > a "better" way to solve the problem? [...] > > cs> Long ago, we added something similar to what you cs> are > talking about. Basically, it was a file- cs> upload capability for > images. We waffled about cs> whether to just map the > /uploaded-images/ URL cs> space directly to the disk and have > DefaultServlet cs> serve the bytes or to write our own servlet > [...] > > cs> Re-reading the documentation for cs> (specifically, > ), it seems that: cs> cs> > cachingAllowed="false" cs> base="/base/path/to/image/files/" cs> > className="org.apache.catalina.webresources.DirResourceSet" cs> > webAppMount="/uploaded-images/" /> cs> cs> ... might do the trick, > and it would only disable caching for that portion of the disk. > cs> cs> Perhaps this would be a better solution, because cs> it > only disabled caching for a *portion* of the cs> requests you'll be > handling. > > Yes, exactly! I might experiment with something like that "next". > > cjb> Is it possible to declare only the Excel reports cjb> output > folder as non-cache-able but leave the cjb> (default) context cache > setting as-is so everything cjb> else can be cached in the default > way? That is, cjb> set up the Excel report output folder as a > separate cjb> "resource" with an independent cache setting? cjb> > Right now the Excel folder is embedded in the app cjb> file system: > TC/webapps/app/excel. > > Although I wonder if having the Excel folder embedded in the app > content folder and specifying it in a "PostResources" clause at the > same time would somehow conflict with the default servlet already > serving it. Good thought: the DefaultServlet will use the "resources" as set-up by the context, so "post resources" will fall at the end of the list of things to check. If the "excel documents" folder is actually rooted in the web root of the context, then yes, you'll achieve nothing. On the other hand, you shouldn't put your excel files into a directory rooted in the web root of the context because they will be deleted if you undeploy the web application. (oops) Also, using PreResources is a potential security hazard, as "pre resources" are checked for *classes* before the regular WEB-INF/classes and WEB-INF/lib/*.jar files and so it's easy to inject a rogue class into your application if an attacker can arrange for that kind of things to happen. In your use-case, you are building the document internally (so the user isn't uploading files), but it's worth pointing-out that in an upload-situation, use of "pre resources" to serve uploaded files can get you compromised in a hurry. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+CeUACgkQHPApP6U8 pFi8aA//YhQ5C+aevSfPoYYyooN+M2Kw9PWWhVDkVJs2esOPkSrwNFG7TCHnLn52 cBcgqOSKX6nvlanwyk+3aFlk2OdRrZL2IRqszXuugQr2fZpC18qvHru9xi6JpCDJ kFr+qhp0xQ6WNlG/+DnaOXLg8/x3m0N+iihjNOgxbtvwcag1AksADpRpYnscnen1 bimNvvBatyiSyBUZ3m5FQjF3E3iuB63MXygT3emwWsOrGya7PafoeG9Wbr+nD6dc z4nEp6UOqVk0FSyYgaFDoUYAZIa7PNVaHWs+SCFwm749pSjvg9vgnMBoYsBPN0XH t0jHvSMu5ye5H+sACxgjaY0S/2l78ps1dg9ULlHDJM3zIdqM8TQIMObmUUAk7tUJ LDXf0KJEZa8sLYm9o6PEaUHReLrM8I2WylwW6puTSTvRDDjkcoKUj4Nc8xEsDppb yu79aHG5EiiCJfJ6rdo5OdGRKKHaFa27upxdy4yzr9whzCLG8vqpPUmKGiKHPw9O 9lQ6RVhaGO3NYromew614BaujgJbkIHNYtLNkIzVvAK5EuyiRewLSrIKUaC+R5JO wY41Z37ai6bN4mR2chiqFIyPX871OUYFUWMzIbmKZB8xXugKhhdl3syq4vp+uiIr kgStOuxlaUeMUXWW6q5Tvdq5rUc7mzkkVsixyeqHKqw6zjhtfY0= =TguN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request for a technical review
Hi Mallory, I can have a look. Please let me know further details. Thanks, Deepak Behera
Request for a technical review
Hi all, I work for Datadog and am writing a guide about monitoring Tomcat (with or without Datadog). I'd love to get some feedback on the technical content. The project maintainers we reached out to recommended we post a request here. Would anyone be up for that? I can send the post link to someone directly. Appreciate your help and time! -- Mallory Mooney Technical Content Writer
Security Alerts Email Subscription
Hello Team Is there a mailing list for subscription to just the security alerts for Apache HTTP and Tomcat Server, If there is one can you please send it to me. Thanks Pradeep This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies
Re: TLS1.3 support for tomcat 7 with APR/tomcat-native
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Усманов, On 10/6/18 17:27, Усманов Азат Анварович wrote: > I've been searching the web for any idea why Chrome can do throw > empty response error with tls1.3 and found this bug > https://bugzilla.redhat.com/show_bug.cgi?id=1619389 at fedora , it > looks like the same sort of a problem,Interestingly enough it does > have a fix. My knowledge of C is quite limited, so could anyone > please look at the patch provided by these guys and see if it is > of any use in case of tomcat-native ? Have a look at the recent bug comments, especially Rainer's comment about Chrome/ff versions. - -chris > От: Усманов Азат Анварович > Отправлено: 25 сентября 2018 г. 11:39 Кому: > Tomcat Users List Тема: Re: TLS1.3 support for tomcat 7 with > APR/tomcat-native > > Do I need to file a separate feature request for Tomcat itself? The > one I already > filed(https://bz.apache.org/bugzilla/show_bug.cgi?id=62748) is for > tomcat-native component. I looked through Tomcat changelog, I've > found that previously TLS1.2 support was added via enhancement > request to tomcat native . > (https://bz.apache.org/bugzilla/show_bug.cgi?id=53952) > От: Усманов Азат Анварович > Отправлено: 20 сентября 2018 г. 12:05:07 Кому: > users@tomcat.apache.org Тема: Re: TLS1.3 support for tomcat 7 with > APR/tomcat-native > > I did file a feature -enhancement in bugzilla > > https://bz.apache.org/bugzilla/show_bug.cgi?id=62748 > > От: Christopher Schultz > Отправлено: 19 сентября 2018 г. > 23:31:28 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for > tomcat 7 with APR/tomcat-native > > Усманов, > > On 9/19/18 05:56, Усманов Азат Анварович wrote: >> Hi Christopher! I did remove supportedProtocols attribute >> entirely (SSL Labs server test confirms it ). > You mean that SSL Labs then tells you that other protocols are > available (e.g. TLSv1.0, etc.)? SSL Labs should tell you if TLSv1.3 > is available, so testing with e.g. Chrome shouldn't be necessary. > >> > maxPostSize="10485760 " maxHttpHeaderSize="1048576" >> protocol="org.apache.coyote.http11.Http11AprProtocol" >> connectionTimeout="2" redirectPort="8443" >> SSLHonorCipherOrder="true" >> SSLCertificateFile="/home/idis/STAR_ieml_ru.crt" >> SSLCertificateKeyFile="/home/idis/server.key" >> SSLCertificateChainFile="/home/idis/authorities.crt" > >> maxThreads="350" minSpareThreads="25" SSLEnabled="true" >> enableLookups="false" disableUploadTimeout="true" >> acceptCount="100" scheme="https" secure="true" >> compression="force" >> SSLCipherSuite="TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA384,T L > >> S_AES_128_GCM_SHA256,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-GC > M-SHA384,ECDHE-ECDSA-AES256-GCM-SHA256,ECDHE-RSA-AES256-GCM-SHA384,ECD HE > > - -RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES128-GCM-SHA256, >> ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-SHA384,ECDHE-RSA-AES25 6 > >> - -SHA384,ECDHE-ECDSA-AES128-SHA256,ECDHE-RSA-AES128-SHA256, > > > ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES256-SHA"/> > >> I did put >> TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA384,TLS_AES_128_GCM_S H > >> A256 >> as tls 1.3 ciphers for tls 1.3 , so my guess is that more work >> is required for tls.1.3 to work in my case > > Yes, you will definitely have to mention the TLSv1.3 ciphers in > order to allow a TLSv1.3 handshake to succeed. > > But yes, it does indeed look like Tomcat requires some work. > > Can you please file an enhancement request in Bugzilla? > > Thanks, -chris > >> От: Christopher Schultz >> Отправлено: 18 сентября 2018 г. >> 23:27 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for >> tomcat 7 with APR/tomcat-native > >> Усманов, > >> On 9/18/18 6:43 AM, Усманов Азат Анварович wrote: >>> I have a java7 web application that runs on tomcat 7.0.70 I'm >>> using Apr/tomcat-native w OpenSSL for TLS connections >>> .(Tomcat-native 1.2.17 APR 1.6,OpenSSL 1.1.1 RHEL 6 ) Latest >>> stable OpenSSL release (1.1.1) has TLS 1.3 support ,I have >>> upgraded to it successfully. My question is if and when >>> tomcat 7 will be upgraded to support TLS1.3 through w >>> APR/tomcat-native/OpenSSL? do such plans even exist? > >> Try not specifying any "supported protocol" (e.g. allow all >> protocol flavors), and OpenSSL should allow TLSv1.3 to be >> negotiated. > >>> I'm guessing it will not happen at least untill both Chrome >>> and firefox release theirbrowser updates for RFC8446 >>> support (which are both scheduled for Mid october Crome 70 and >>> firefox 63) but would like to know more about it > >> I for one would like to see TLSv1.3 supported as quickly as >> possible. > >> The OpenSSL project states that 1.1.1 is a drop-in API- and >> ABI-compatible replacement for 1.1.0 and therefore TLSv1.3 >> should "just work" under certain
Re: Security Alerts Email Subscription
Pradeep, On 10/10/2018 11:03 AM, Goutam, Pradeep wrote: Hello Team Is there a mailing list for subscription to just the security alerts for Apache HTTP and Tomcat Server, If there is one can you please send it to me. You should subscribe to the Announce mailing list: http://tomcat.apache.org/lists.html#tomcat-announce Igal - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request for a technical review
On 10/10/18 17:44, Mallory Mooney wrote: > Hi all, > > I work for Datadog and am writing a guide about monitoring Tomcat (with or > without Datadog). I'd love to get some feedback on the technical content. > The project maintainers we reached out to recommended we post a request > here. > > Would anyone be up for that? I can send the post link to someone directly. > > Appreciate your help and time! Why not post the link here so the community can review the document? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Clustering Support
> From: Mark Thomas [mailto:ma...@apache.org] > Subject: Re: Tomcat Clustering Support > Thread A is in the middle of processing a request. It is evaluating some > EL which requires access to the view map which in turn causes the > ViewMap to update the session. > com.sun.faces.application.view.ViewScopeManager.processEvent locks the > ViewMap object. It then tries to update the session. To do this it > requires the session lock. Thread A is waiting for this lock. Assuming the ViewMap is used by multiple sessions, this locking order goes against the usual protocol of more local before more global. Might be possible to file a bug report with Mojarra, but given that the code appears to be in a com.sun class, that might not get anywhere. > Thread B is at the end of a request. The session has been updated and it > is attempting to write the updated session attributes to the cluster. > The session lock has been obtained. The individual attributes are being > written. The code has reached the ViewMap object. In order to write this > object, the ViewMap object must be locked. Thread B is waiting for this > lock. This is the generally the more desirable order. > Has anyone on the users list come across this problem before? If so, how > have you solved it? Suggestions for alternative solutions also welcome. Can the thread doing the session synchronization lock the session, get a shallow copy of the attributes, unlock the session, then process the attributes? Not sure if that would maintain sufficient coherency. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. smime.p7s Description: S/MIME cryptographic signature
