RE: How to acess HttpServletRequest in Jaas login module in Tomcat
Hi Mark, Thanks for your reply. I am already extending JAASCallbackHandler and getting Name and password through that. How can we get HTTLServletRequest through JAASCallbackHandler? SAURABH SUMAN Software Developer Markets & International Banking RBS Block No 1, Tower A, Unitech Infospace Complex Sector 21, Gurgaon, Haryana, 122002, India Office: +91 124 6195699 | Mobile: +91 375289 -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, May 18, 2016 1:14 PM To: Tomcat Users List Subject: Re: How to acess HttpServletRequest in Jaas login module in Tomcat * " This message originates from outside our organisation. Consider carefully whether you should click on any links, open any attachments or reply. If in doubt, forward to ~ Phishing" * On 18/05/2016 03:56, saurabh.su...@rbs.com.INVALID wrote: > Hello experts > > How to acess HttpServletRequest in Jaas login module in Tomcat? In > Jboss we can get it through > > > HttpServletRequest request = > (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpS > ervletRequest") > > But it's not working in Tomcat since Jacc is not supported by Tomcat yet. Is > there anyother way in tomcat to get HttpServletRequest in Jaas login module ? Unless you write some custom Tomcat code, no. You'd need to extend the JAASRealm and the JAASCallbackHandler at a minimum. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. The Royal Bank of Scotland N.V. is authorised and regulated by the De Nederlandsche Bank and has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587. Registered Office: Gustav Mahlerlaan 350, Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and The Royal Bank of Scotland plc are authorised to act as agent for each other in certain jurisdictions. This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland N.V. including its affiliates ("RBS group") does not accept responsibility for changes made to this message after it was sent. For the protection of RBS group and its clients and customers, and in compliance with regulatory requirements, the contents of both incoming and outgoing e-mail communications, which could include proprietary information and Non-Public Personal Information, may be read by authorised persons within RBS group other than the intended recipient(s). Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the RBS group in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our website at www.rbs.com *** - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] Java Deserialization, JMX and CVE-2016-3427
2016-05-25 13:42 GMT-04:00 Mark Thomas : (...) > For example, this issue only applies if you are using JMX/RMI. If you > are, it is likely to be a significant risk. If you aren't, it won't > affect you. One of the reasons I published that blog post was to provide > folks with the information they need to figure out whether this affects > them or not. > > Mark > In doubt, I usually prefer to upgrade to latest version. I see no reason to stick to a lower version unless a specific bug is know and has been introduced into the latest version. - Daniel Savard
JSON Logging of Tomcat Access Log.
I am wanting to change the access logging format to JSON (for easier parsing with logstash) I currently have the following config in my server.xml … How would i change this to JSON formatted? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp in the same thread context
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 5/25/16 11:03 AM, Daniel Rocha wrote: > I have a java application that was running with "Embedded" class > from Tomcat 6.0.Now I am trying to upgrade it to run with Tomcat > 7.0.69. > > The current java application is initializing some static objects > and then starts the "Embedded" class with some Servlets.The > Servlets that were initialized access to the static objects from > the application that started them. This works fine with Tomcat > 6.0. > > Now, I am using the "Tomcat" class from Tomcat 7.0 to start the > same Servlets.The servlets are initialized and I can access to > their context path. > > The problem is when I try to access from the Servlet to a static > initialized object from the application that started them.The > object is null here. Where is the .class file located for the servlet? Where is the .class file located for the "static initialized object" reference? You need to be very specific about what's going on, here, because lack of precision can cause all kinds of missteps. > I do not know if this is related to the context class loader. It's almost certainly related to the ClassLoader... probably the WebappClassLoader. > The code looks something like this: > > // Port number int port = 8080; // Create an embedded > serverthis.embedded = new Tomcat(); > this.embedded.setBaseDir(getPath()); this.embedded.setPort(port); > // Set default virtual hostthis.host = this.embedded.getHost(); > this.host.setAppBase(getPath() + "/webapps"); // Create the ROOT > contextthis.rootcontext = this.embedded.addWebapp(this.host, "", > getPath() + "/webapps/ROOT"); > this.rootcontext.setReloadable(false); > this.rootcontext.addWelcomeFile("index.jsp"); // Create servlet > context this.rootcontext = this.embedded.addWebapp(this.host, > "/context", "/home/path/to/app"); > this.rootcontext.setReloadable(false);context.setPrivileged(true); > > // Set connector propertiesConnector connector = > this.embedded.getConnector(); connector.setSecure(false); > connector.setProperty("maxThreads", "10"); > connector.setProperty("acceptCount", "20"); > connector.setProperty("asyncTimeout", "3"); > connector.setProperty("connectionTimeout", "3"); > connector.setProperty("socket.soTimeout", "3"); > connector.setEnableLookups(false); > > this.embedded.setConnector(connector); // Start the embedded > server this.embedded.start(); There is nothing in that code that is going to cause any problem like you describe. Tell us how the code that fails interacts with the code that is (likely) loaded from the wrong ClassLoader. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXReyqAAoJEBzwKT+lPKRYyREP/iFMdNtenVwqDSw3u7senlVs UUQ4QrdiHa1CYtl3DZMNnxq47EnK8oKbHEsR4ELN4K1fJ2MzDC+gCL33AhFF8b1+ bNRczRdj9aq3SbHqWR7Cb06CRj3qZ6FKexlHaHVgAVBuo0o7+Vp1+P843qWjDLCt ZrWQ9gdsMI/9spKXn11QnP/q0yW3SiMoTOTTob5ByEKfhZMFupuhCBZnhqQC2fZh D0iivElIaJer4Q5OXDblo4lBfwFSJtT2Xlkqx4B2xMNVf1obrYai4tGlXNtXVlwI wgsLvmaRT9tOCf/6uSnuTNKlxX5P3FKQYbyecsYUCmHysJ+f6kGIxY3PdwuL4Arq 4OlyfsYX6wDtcHGEw+T9gtG+Z+QQw1RKLwtYv6sasEjQIusVNJGwZbsWgi+TYNS5 C2Ini934fDWJwc9DljEjvr3cYQMEt5ysMKNMVAG0d4SLsL9ug1iBiuv/ZH4LcG0m +PWq6kGOmlpUHq/j7ySvKadg/YvXzr5OTagr7hCn88Z3WU0K+oJcKgE9QA9qDHGc 9a+ZyNFRbdfh4yW5zmCbK+0EYH6BZ9mjKU/tOVjjaiqEU/AJOb9itLVHXz6yek5e LlHXomL1w1tJGQ9zYiJx3/oBHC1px05n0hqfKKkfbRjsUI44Mjuyqo0SpymWxQi/ XuI+yXCgM4Vi7h4mcGFc =jHSA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.0.35 available
Does anybody know if the AES+GCM bug that causes a JVM Crash (I believe only under JDK 8) when running TLS in Tomcat using Java's JSSE has been fixed? I doubt this is a Tomcat issue, but since the bug likely only appears for uses of TLS's AES+GCM in Tomcat, I hope someone here may know the details. I can't seem to track the fix (it's a rather old bug considering the severity of a JVM crash just using TLS) in Java. Thanks, David On 5/25/16 10:52 AM, Mark Thomas wrote: Apologies for the delay in sending this out. The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.35. Apache Tomcat 8.0 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language and Java WebSocket technologies. Apache Tomcat 8.0.35 includes fixes for issues identified in 8.0.33 as well as other enhancements and changes. The notable changes since 8.0.33 include: - Make the default TLS configuration more secure. - Update the packaged version of the Tomcat Native Library to 1.2.7 to pick up the Windows binaries that are based on OpenSSL 1.0.2h and APR 1.5.2. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - 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
[ANN] Apache Tomcat 8.0.35 available
Apologies for the delay in sending this out. The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.35. Apache Tomcat 8.0 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language and Java WebSocket technologies. Apache Tomcat 8.0.35 includes fixes for issues identified in 8.0.33 as well as other enhancements and changes. The notable changes since 8.0.33 include: - Make the default TLS configuration more secure. - Update the packaged version of the Tomcat Native Library to 1.2.7 to pick up the Windows binaries that are based on OpenSSL 1.0.2h and APR 1.5.2. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] Java Deserialization, JMX and CVE-2016-3427
On 25/05/2016 16:12, Christopher Schultz wrote: > Mark, > > On 5/24/16 10:06 AM, Mark Thomas wrote: >> TL;DR If you use remote JMX, you need to update your JVM to address >> CVE-2016-3427 > >> For the longer version, see the blog post I just published on >> this: http://engineering.pivotal.io/post/java-deserialization-jmx/ > > Okay, I give up: what version of Java 8 actually has this patch? 8u91 onwards. If you want the fix in an early Java version then you'll need to be paying Oracle $$$ for extended Java support > Oracle's site gives me the runaround and tells me that it's been patched > in April, but I have no idea what version of Java was published in > April, and Oracle's site seems very reticent to tell me :( > > The CVEs have virtuall no information other than "something bad exists > in some versions of some stuff, and you should upgrade". Upgrade to what > ? At least you can derive that form public information. What annoys me far more is that Oracle provide next to no detail with their CVE announcements so it is impossible for a user to determine if the issue affects them or not. For example, this issue only applies if you are using JMX/RMI. If you are, it is likely to be a significant risk. If you aren't, it won't affect you. One of the reasons I published that blog post was to provide folks with the information they need to figure out whether this affects them or not. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Xwiki-Entreprise-Web-8.1 WAR File Installation issues... Tomcat error
On 25.05.2016 18:09, sebastien.boulia...@cpu.ca wrote: Hi all, I tried to install the Xwiki-Entreprise-Web-8.1 WAR File on Tomcat and I get these errors... http://pastebin.com/T0Kfa7MS http://imgur.com/ejT0zAe ps aux | grep tomcat tomcat2152 4.4 15.0 3802340 724216 ? Ssl 10:45 0:12 /usr/lib/jvm/jre/bin/java -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start root 2208 0.0 0.0 112636 984 pts/0S+ 10:50 0:00 grep --color=auto tomcat If I try with the 8.0 war file, the installation is going perfectly. I would like to know if someone have ever see this king of error and how you fixed it. I checked the permissions and I am running the java-1.8. Any help will be appreciated. Thanks in advance. This looks similar to an issue I experienced recently. You may want to check this thread in the archives : http://markmail.org/thread/typic3k2ztphsfoe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Xwiki-Entreprise-Web-8.1 WAR File Installation issues... Tomcat error
Hi all, I tried to install the Xwiki-Entreprise-Web-8.1 WAR File on Tomcat and I get these errors... http://pastebin.com/T0Kfa7MS http://imgur.com/ejT0zAe ps aux | grep tomcat tomcat2152 4.4 15.0 3802340 724216 ? Ssl 10:45 0:12 /usr/lib/jvm/jre/bin/java -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start root 2208 0.0 0.0 112636 984 pts/0S+ 10:50 0:00 grep --color=auto tomcat If I try with the 8.0 war file, the installation is going perfectly. I would like to know if someone have ever see this king of error and how you fixed it. I checked the permissions and I am running the java-1.8. Any help will be appreciated. Thanks in advance. Sébastien
Xwiki-Entreprise-Web-8.1 WAR File Installation issues... Tomcat error
Hi all, I tried to install the Xwiki-Entreprise-Web-8.1 WAR File on Tomcat and I get these errors... http://pastebin.com/T0Kfa7MS http://imgur.com/ejT0zAe ps aux | grep tomcat tomcat2152 4.4 15.0 3802340 724216 ? Ssl 10:45 0:12 /usr/lib/jvm/jre/bin/java -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start root 2208 0.0 0.0 112636 984 pts/0S+ 10:50 0:00 grep --color=auto tomcat If I try with the 8.0 war file, the installation is going perfectly. I would like to know if someone have ever see this king of error and how you fixed it. I checked the permissions and I am running the java-1.8. Any help will be appreciated. Thanks in advance. Sébastien
Re: [SECURITY] Java Deserialization, JMX and CVE-2016-3427
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 5/25/16 11:41 AM, David kerber wrote: > On 5/25/2016 11:12 AM, Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Mark, >> >> On 5/24/16 10:06 AM, Mark Thomas wrote: >>> TL;DR If you use remote JMX, you need to update your JVM to >>> address CVE-2016-3427 >>> >>> For the longer version, see the blog post I just published on >>> this: >>> http://engineering.pivotal.io/post/java-deserialization-jmx/ >> >> Okay, I give up: what version of Java 8 actually has this patch? >> Oracle's site gives me the runaround and tells me that it's been >> patched in April, but I have no idea what version of Java was >> published in April, and Oracle's site seems very reticent to tell >> me :( >> >> The CVEs have virtuall no information other than "something bad >> exists in some versions of some stuff, and you should upgrade". >> Upgrade to what ? > > Wouldn't it just be the latest? Presumably so, but do you really want to read between the lines for a security advisory? This should be much more clear to the reader. At face value, it appears that precisely 5 versions are effected, when the truth is much worse. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFyhgACgkQ9CaO5/Lv0PBPigCgmCNXhA/kEiJRI5J5sUVunKmG VNgAmwcBS1DRQy9NBnQRoARFdLbUqHu6 =TuoZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secured connection between Apache Httpd and Tomcat over AJP protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, On 5/25/16 11:30 AM, Christopher Schultz wrote: > Mohanavelu, > > On 5/25/16 10:21 AM, Mohanavelu Subramanian wrote: >> I have Httpd process and Tomcat instances both running on 2 >> different machines. The communication between them happens >> through AJP protocol (mod_jk) which doesn't support encryption. >> But we are using some features of mod_jk like automatic passing >> of security information like SSL certificate to tomcat which in >> turn is accessed in our application, validated and verified. > >> Now, we have requirement to make the communication between them >> as Secured. Since AJP doesn't support encryption, I came to know >> that we need to use SSH, IPSec. But I could not find any proper >> document to configure SSH or IPSec for AJP. Could please share if >> you any. > >> I have considered mod_proxy_http as well for supporting security >> which is easy to configure as well. But as I mentioned above we >> are already making use mod_jk features. Again it will require >> more efforts to migrate from mod_jk to mod_proxy_http. > > It's not so bad switching from mod_jk to mod_proxy_http, but you > are right that it does require re-configuration. > > IPsec and SSH tunnels (using the ssh binary) are a total pain. We > use stunnel, and it's fairly simple to set up. stunnel uses SSL/TLS > to tunnel other protocols. It does *not* use the SSH protocol, > which is critical to understanding how it works. > > stunnel is a little more complicated than a normal protocol because > it can be used in a number of different ways. I'll give some > contrived examples to see how you can set it up in different ways, > depending upon the support for encryption of the underlying > protocol. > > Let's say that you have an HTTPS server, but your client can't > speak HTTPS for some reason. If you set up stunnel on the *client* > side, you can connect locally to the stunnel server and have it > establish a secure-connection to the remote server running HTTPS. > Like this: > > client -> localhost:12345 stunnel stunnel -> remote_host:443 > > As far as the client is concerned, it's using HTTP to talk to > localhost. But really it's talking to remove_host:443, so everyone > is happy. (Yes, there are issues with URLs and redirects produced > by the server, but that's out of scope for this discussion). > > Let's take another example: you have clients that are > HTTPS-capable, but the service you are running can only support > HTTP for some reason, and you want to secure it. Set up stunnel on > the *server*, then have your remote clients connect to *it* and > tunnel to localhost. Like this: > > client -> remote_host:443 stunnel localhost:8080 > > As far as the client is concerned, it's using HTTPS to communicate > with remote_host:443, but really it's connecting to > remote_host:8080. (Yes, there are some issues with URLs and > redirects but that's out of scope for this discussion.) > > So what if the underling protocol doesn't support TLS at all? > Well, then you have to set up stunnel on *both sides* of the > tunnel, like this : > > client (mod_jk) -> localhost:12345 stunnel -> remote_host:12345 > stunnel -> localhost:8009 > > The setup for stunnel looks like this for the client (on the web > server) : > > sslVersion = all options = NO_SSLv2 options = NO_SSLv3 client = > yes [ajp13s] accept=localhost:8009 connect=remote_host:8010 > > On the server, it looks like this: > > sslVersion = all options = NO_SSLv2 options = NO_SSLv3 client = no > [ajp13s] accept=8010 connect=localhost:8009 > > On the web server, set your worker's host to "localhost" and port > to 8009. mod_jk will connect to localhost:8009 which stunnel will > accept and forward over the network to remote_host:8010 which will > be accepted by stunnel on the server and forwarded to > localhost:8009 on the server. > > stunnel is great because it will auto-reconnect if the connection > is dropped for some reason. Remember a few things with stunnel: > > 1. Depending upon the version, you might only be able to use TLSv1 > (and not e.g. TLSv1.2) 2. stunnel generally ignores certificate > issues, such as expiration, etc. You might want to configure it > with a little more care than the default. THIS ALSO MEANS IT DOES > NOT AUTHENTICATE THE SERVER BY DEFAULT. You could accidentally > connect to a malicious server. I've added the above to the wiki: https://wiki.apache.org/tomcat/AJP%20with%20stunnel - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFyYcACgkQ9CaO5/Lv0PBz4gCeJRdGjWsJepYG8Ozh1A/Z+d07 r6kAniN465Rw0kv/awlbxEamUPK9MmjI =H8q/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] Java Deserialization, JMX and CVE-2016-3427
On 5/25/2016 11:12 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 5/24/16 10:06 AM, Mark Thomas wrote: TL;DR If you use remote JMX, you need to update your JVM to address CVE-2016-3427 For the longer version, see the blog post I just published on this: http://engineering.pivotal.io/post/java-deserialization-jmx/ Okay, I give up: what version of Java 8 actually has this patch? Oracle's site gives me the runaround and tells me that it's been patched in April, but I have no idea what version of Java was published in April, and Oracle's site seems very reticent to tell me :( The CVEs have virtuall no information other than "something bad exists in some versions of some stuff, and you should upgrade". Upgrade to what ? Wouldn't it just be the latest? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secured connection between Apache Httpd and Tomcat over AJP protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mohanavelu, On 5/25/16 10:21 AM, Mohanavelu Subramanian wrote: > I have Httpd process and Tomcat instances both running on 2 > different machines. The communication between them happens through > AJP protocol (mod_jk) which doesn't support encryption. But we are > using some features of mod_jk like automatic passing of security > information like SSL certificate to tomcat which in turn is > accessed in our application, validated and verified. > > Now, we have requirement to make the communication between them as > Secured. Since AJP doesn't support encryption, I came to know that > we need to use SSH, IPSec. But I could not find any proper document > to configure SSH or IPSec for AJP. Could please share if you any. > > I have considered mod_proxy_http as well for supporting security > which is easy to configure as well. But as I mentioned above we are > already making use mod_jk features. Again it will require more > efforts to migrate from mod_jk to mod_proxy_http. It's not so bad switching from mod_jk to mod_proxy_http, but you are right that it does require re-configuration. IPsec and SSH tunnels (using the ssh binary) are a total pain. We use stunnel, and it's fairly simple to set up. stunnel uses SSL/TLS to tunnel other protocols. It does *not* use the SSH protocol, which is critical to understanding how it works. stunnel is a little more complicated than a normal protocol because it can be used in a number of different ways. I'll give some contrived examples to see how you can set it up in different ways, depending upon the support for encryption of the underlying protocol. Let's say that you have an HTTPS server, but your client can't speak HTTPS for some reason. If you set up stunnel on the *client* side, you can connect locally to the stunnel server and have it establish a secure-connection to the remote server running HTTPS. Like this: client -> localhost:12345 stunnel stunnel -> remote_host:443 As far as the client is concerned, it's using HTTP to talk to localhost. But really it's talking to remove_host:443, so everyone is happy. (Yes, there are issues with URLs and redirects produced by the server, but that's out of scope for this discussion). Let's take another example: you have clients that are HTTPS-capable, but the service you are running can only support HTTP for some reason, and you want to secure it. Set up stunnel on the *server*, then have your remote clients connect to *it* and tunnel to localhost. Like this: client -> remote_host:443 stunnel localhost:8080 As far as the client is concerned, it's using HTTPS to communicate with remote_host:443, but really it's connecting to remote_host:8080. (Yes, there are some issues with URLs and redirects but that's out of scope for this discussion.) So what if the underling protocol doesn't support TLS at all? Well, then you have to set up stunnel on *both sides* of the tunnel, like this : client (mod_jk) -> localhost:12345 stunnel -> remote_host:12345 stunnel -> localhost:8009 The setup for stunnel looks like this for the client (on the web server) : sslVersion = all options = NO_SSLv2 options = NO_SSLv3 client = yes [ajp13s] accept=localhost:8009 connect=remote_host:8010 On the server, it looks like this: sslVersion = all options = NO_SSLv2 options = NO_SSLv3 client = no [ajp13s] accept=8010 connect=localhost:8009 On the web server, set your worker's host to "localhost" and port to 8009. mod_jk will connect to localhost:8009 which stunnel will accept and forward over the network to remote_host:8010 which will be accepted by stunnel on the server and forwarded to localhost:8009 on the server. stunnel is great because it will auto-reconnect if the connection is dropped for some reason. Remember a few things with stunnel: 1. Depending upon the version, you might only be able to use TLSv1 (and not e.g. TLSv1.2) 2. stunnel generally ignores certificate issues, such as expiration, etc. You might want to configure it with a little more care than the default. THIS ALSO MEANS IT DOES NOT AUTHENTICATE THE SERVER BY DEFAULT. You could accidentally connect to a malicious server. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFxP8ACgkQ9CaO5/Lv0PBskQCfUnXqw5wGSTo+Tr9wk6ZvxJCq NPsAoJaPHHhvHCkI8TnAMaCrQ5q3y9x9 =h4AI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] Java Deserialization, JMX and CVE-2016-3427
On Wed, May 25, 2016 at 11:12 AM, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Mark, > > On 5/24/16 10:06 AM, Mark Thomas wrote: >> TL;DR If you use remote JMX, you need to update your JVM to address >> CVE-2016-3427 >> >> For the longer version, see the blog post I just published on >> this: http://engineering.pivotal.io/post/java-deserialization-jmx/ > > Okay, I give up: what version of Java 8 actually has this patch? > Oracle's site gives me the runaround and tells me that it's been patched > in April, but I have no idea what version of Java was published in > April, and Oracle's site seems very reticent to tell me :( > > The CVEs have virtuall no information other than "something bad exists > in some versions of some stuff, and you should upgrade". Upgrade to what > ? When I clicked on the CVE link and the link to oracle page onward in the Reference section (CONFIRM:http://www.oracle.com/technetwork/security-advisory/cpuapr2016v3-2985753.html), I could see the Java version ("Supported Versions Affected" column) in the table when I look up "CVE-2016-3427". > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAldFwPAACgkQ9CaO5/Lv0PBRjQCeOkzoLqUv6DMHkLWkEbfySe74 > tvgAnRnNMavAA9M7Y2FxoTOQ1mo8eIW9 > =g9B3 > -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
Re: Can tomcat be configured for ECDHE and DHE cipher suites
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 5/25/16 10:38 AM, Mark Thomas wrote: > On 25/05/2016 15:17, Utkarsh Dave wrote: >> Hello Mark, >> >> I have a question for SSL Support - BIO and NIO. It is mention >> that useServerCipherSuitesOrder can be used with Java 8 only So >> is there a way (in java 7 and BIO and NIO support ) or another >> parameter we can use with "ciphers" to force client follow the >> order of ciphers. > > No. > >> The JSSE implementation guide documents that the client tells the >> server which cipher suites it has available, and the server >> chooses the best mutually acceptable cipher suite. > > Then the JSSE implementation guide is wrong. The client presents > the ciphers it supports in client preference order and the server > picks the first one it can support. No, it doesn't. The server is free to choose whatever cipher is mutually-supported. Unless "honor server cipher ordering" is enabled, most servers will choose the first cipher presented by the client. The tradition of using the client's favorite cipher suite is just that: a tradition. It's not in the spec at all: " The cipher suite list, passed from the client to the server in the ClientHello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). Each cipher suite defines a key exchange algorithm, a bulk encryption algorithm (including secret key length), a MAC algorithm, and a PRF. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection. If the list contains cipher suites the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites, and process the remaining ones as usual. " (https://tools.ietf.org/html/rfc5246#page-40) The problem here is the definition of "best". If the JSSE implementation guide thinks that "best" is "most preferred by the client" then it will choose the first mutually-supported cipher suite. Your definition of "best" probably means "highest security", and so it will fail your test while passing the client's test of "best". This is why "honor server cipher suite order" was invented: it allows the SERVER to decide what "best" means instead of leaving the decision to "tradition" by whatever definition. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFwuAACgkQ9CaO5/Lv0PCUJwCfQhGYpK6SZJyK1vPejbVbeGe9 vJ4An3nj//KAgd2yPqx1dbktuHXjRXcn =7y3S -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secured connection between Apache Httpd and Tomcat over AJP protocol
On 25.05.2016 16:21, Mohanavelu Subramanian wrote: Hi All, Good Morning. I have Httpd process and Tomcat instances both running on 2 different machines. The communication between them happens through AJP protocol (mod_jk) which doesnt support encryption. But we are using some features of mod_jk like automatic passing of security information like SSL certificate to tomcat which inturn is accessed in our application, validated and verified. Now, we have requirement to make the communication between them as Secured. Since AJP doesnt support encryption, I came to know that we need to use SSH, IPSec. But I could not find any proper document to configure SSH or IPSec for AJP. Could please share if you any. I have considered mod_proxy_http as well for supporting security which is easy to configure as well. But as I mentioned above we are already making use mod_jk features. Again it will require more efforts to migrate from mod_jk to mod_proxy_http. Any other suggestions please. Hi. As far as I know, there is no further information about this on the Tomcat site, probably because it is a relatively unfrequent configuration. In any case, there is nothing really special about this : you will need to build one (or more) standard SSH tunnel(s), between the port(s) mentioned for the workers in the "workers.properties" file, and the AJP port(s) mentioned in the Tomcat AJP s. You can do this with a utility such as "stunnel" (Linux) or plink.exe (Windows) (part of the Putty package). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] Java Deserialization, JMX and CVE-2016-3427
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 5/24/16 10:06 AM, Mark Thomas wrote: > TL;DR If you use remote JMX, you need to update your JVM to address > CVE-2016-3427 > > For the longer version, see the blog post I just published on > this: http://engineering.pivotal.io/post/java-deserialization-jmx/ Okay, I give up: what version of Java 8 actually has this patch? Oracle's site gives me the runaround and tells me that it's been patched in April, but I have no idea what version of Java was published in April, and Oracle's site seems very reticent to tell me :( The CVEs have virtuall no information other than "something bad exists in some versions of some stuff, and you should upgrade". Upgrade to what ? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFwPAACgkQ9CaO5/Lv0PBRjQCeOkzoLqUv6DMHkLWkEbfySe74 tvgAnRnNMavAA9M7Y2FxoTOQ1mo8eIW9 =g9B3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Webapp in the same thread context
Hi, I have a question related to Tomcat 7.0.69 running in a voyage (debian) system. I have a java application that was running with "Embedded" class from Tomcat 6.0.Now I am trying to upgrade it to run with Tomcat 7.0.69. The current java application is initializing some static objects and then starts the "Embedded" class with some Servlets.The Servlets that were initialized access to the static objects from the application that started them. This works fine with Tomcat 6.0. Now, I am using the "Tomcat" class from Tomcat 7.0 to start the same Servlets.The servlets are initialized and I can access to their context path. The problem is when I try to access from the Servlet to a static initialized object from the application that started them.The object is null here. I do not know if this is related to the context class loader. The code looks something like this: // Port numberint port = 8080;// Create an embedded serverthis.embedded = new Tomcat();this.embedded.setBaseDir(getPath());this.embedded.setPort(port); // Set default virtual hostthis.host = this.embedded.getHost();this.host.setAppBase(getPath() + "/webapps");// Create the ROOT contextthis.rootcontext = this.embedded.addWebapp(this.host, "", getPath() + "/webapps/ROOT");this.rootcontext.setReloadable(false);this.rootcontext.addWelcomeFile("index.jsp"); // Create servlet contextthis.rootcontext = this.embedded.addWebapp(this.host, "/context", "/home/path/to/app");this.rootcontext.setReloadable(false);context.setPrivileged(true); // Set connector propertiesConnector connector = this.embedded.getConnector();connector.setSecure(false);connector.setProperty("maxThreads", "10");connector.setProperty("acceptCount", "20");connector.setProperty("asyncTimeout", "3");connector.setProperty("connectionTimeout", "3");connector.setProperty("socket.soTimeout", "3");connector.setEnableLookups(false);this.embedded.setConnector(connector); // Start the embedded serverthis.embedded.start(); Can you please help me with this question? Best regards,Daniel Rocha
Re: Can tomcat be configured for ECDHE and DHE cipher suites
On 25/05/2016 15:17, Utkarsh Dave wrote: > Hello Mark, > > I have a question for SSL Support - BIO and NIO. > It is mention that useServerCipherSuitesOrder can be used with Java 8 only > So is there a way (in java 7 and BIO and NIO support ) or another parameter > we can use with "ciphers" to force client follow the order of ciphers. No. > The JSSE implementation guide documents that the client tells the server > which cipher suites it has available, and the server chooses the best > mutually acceptable cipher suite. Then the JSSE implementation guide is wrong. The client presents the ciphers it supports in client preference order and the server picks the first one it can support. Mark > > I am facing an issue where > > TLS_RSA_WITH_AES_256_CBC_SHA is being chosen from all other available > ECDHE and DHE suites. > > -Utkarsh > > > On Fri, May 20, 2016 at 4:51 PM, Mark Thomas wrote: > >> On 20/05/2016 12:18, Utkarsh Dave wrote: >>> Hi Mark - Thanks. >>> SSLHonorCipherOrder, cna it be configured on Tomcat ? >> >> There would not have been much point telling you about a configuration >> option you could not use would there? >> >> It sounds like you need to spend a few minutes looking over the TLS >> configuration options for the APR/native HTTP connector: >> >> >> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native >> >> Mark >> >> >>> >>> -thanks >>> >>> On Fri, May 20, 2016 at 4:42 PM, Mark Thomas wrote: >>> On 20/05/2016 12:04, Jan Dosoudil wrote: > Hi, > do you have Java Cryptography Extension (JCE) Unlimited Strength > Jurisdiction Policy Files installed? Irrelevant. The OP is using APR / OpenSSL. The available ciphers are controlled by the SSLCipherSuite which follows the OpenSSL config rules for ciphers. You can set SSLHonorCipherOrder to enforce the server's preference order if you wish. Mark > > JD > > 2016-05-20 12:50 GMT+02:00 Utkarsh Dave : > >> Sorry, I missed that information in my earlier mail. >> Tomcat - 7.0.69 configured for SSL >> Connector - APR >> Java - jdk1.7.0_101 >> >> >> On Fri, May 20, 2016 at 4:10 PM, Mark Thomas >> wrote: >> >>> On 20/05/2016 11:37, Utkarsh Dave wrote: Hi Users and Tomcat team, Port 8443 on my product is configured for Tomcat and accepts inbound traffic from 3rd parties. In the TLS handshake, Tomcat chooses TLS_RSA_WITH_AES_256_CBC_SHA >> over >>> some of the more secure cipher options offered by the 3rd party. The 3rd party offers a list of 66 cipher suites that include many ECDHE and DHE variants. Tomcat configured on my product preferred >> cipher suite is AES256-SHA. Can The tomcat be configured for ECDHE and DHE suites must be available and preferred? >>> >>> Tomcat version? >>> >>> Connector type? >>> >>> Java version? >>> >>> Mark >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> - >> 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
Secured connection between Apache Httpd and Tomcat over AJP protocol
Hi All, Good Morning. I have Httpd process and Tomcat instances both running on 2 different machines. The communication between them happens through AJP protocol (mod_jk) which doesnt support encryption. But we are using some features of mod_jk like automatic passing of security information like SSL certificate to tomcat which inturn is accessed in our application, validated and verified. Now, we have requirement to make the communication between them as Secured. Since AJP doesnt support encryption, I came to know that we need to use SSH, IPSec. But I could not find any proper document to configure SSH or IPSec for AJP. Could please share if you any. I have considered mod_proxy_http as well for supporting security which is easy to configure as well. But as I mentioned above we are already making use mod_jk features. Again it will require more efforts to migrate from mod_jk to mod_proxy_http. Any other suggestions please. Thanks in Advance. Best Regards, Mohan
Re: Can tomcat be configured for ECDHE and DHE cipher suites
Hello Mark, I have a question for SSL Support - BIO and NIO. It is mention that useServerCipherSuitesOrder can be used with Java 8 only So is there a way (in java 7 and BIO and NIO support ) or another parameter we can use with "ciphers" to force client follow the order of ciphers. The JSSE implementation guide documents that the client tells the server which cipher suites it has available, and the server chooses the best mutually acceptable cipher suite. I am facing an issue where TLS_RSA_WITH_AES_256_CBC_SHA is being chosen from all other available ECDHE and DHE suites. -Utkarsh On Fri, May 20, 2016 at 4:51 PM, Mark Thomas wrote: > On 20/05/2016 12:18, Utkarsh Dave wrote: > > Hi Mark - Thanks. > > SSLHonorCipherOrder, cna it be configured on Tomcat ? > > There would not have been much point telling you about a configuration > option you could not use would there? > > It sounds like you need to spend a few minutes looking over the TLS > configuration options for the APR/native HTTP connector: > > > http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native > > Mark > > > > > > -thanks > > > > On Fri, May 20, 2016 at 4:42 PM, Mark Thomas wrote: > > > >> On 20/05/2016 12:04, Jan Dosoudil wrote: > >>> Hi, > >>> do you have Java Cryptography Extension (JCE) Unlimited Strength > >>> Jurisdiction Policy Files installed? > >> > >> Irrelevant. The OP is using APR / OpenSSL. > >> > >> The available ciphers are controlled by the SSLCipherSuite which follows > >> the OpenSSL config rules for ciphers. > >> > >> You can set SSLHonorCipherOrder to enforce the server's preference order > >> if you wish. > >> > >> Mark > >> > >> > >>> > >>> JD > >>> > >>> 2016-05-20 12:50 GMT+02:00 Utkarsh Dave : > >>> > Sorry, I missed that information in my earlier mail. > Tomcat - 7.0.69 configured for SSL > Connector - APR > Java - jdk1.7.0_101 > > > On Fri, May 20, 2016 at 4:10 PM, Mark Thomas > wrote: > > > On 20/05/2016 11:37, Utkarsh Dave wrote: > >> Hi Users and Tomcat team, > >> > >> Port 8443 on my product is configured for Tomcat and accepts inbound > >> traffic from 3rd parties. > >> In the TLS handshake, Tomcat chooses TLS_RSA_WITH_AES_256_CBC_SHA > over > > some > >> of the more secure cipher options offered by the 3rd party. The > >> 3rd party offers a list of 66 cipher suites that include many > >> ECDHE and DHE variants. Tomcat configured on my product preferred > cipher > >> suite is AES256-SHA. > >> Can The tomcat be configured for ECDHE and DHE suites must be > >> available and preferred? > > > > Tomcat version? > > > > Connector type? > > > > Java version? > > > > Mark > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Problem with monitoring with JMX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 5/24/16 5:54 PM, André Warnier (tomcat) wrote: > To both : > > Do not guess. Agreed. You should also not guess. > Read the start of the "bin/catalina.sh" script (Linux) or the > "bin/catalina.bat" script (Windows). It explains the difference > between JAVA_OPTS and CATALINA_OPTS. It also recommends that you > should not modify either catalina.sh/bat or startup.bat/sh or > shutdown.bat/sh, but should define these options in a > bin/setenv.bat/sh file, that you create if it is not there yet. > This "bin/setenv.sh/bat" file, if it exists, is called and > executed *before* the JVM that starts (or stops) Tomcat is started, > and thus these options will be set in time to be active when the > JVM runs. > > The reason not to modify the above files, is that they will be > overwritten if you update (or re-install) your Tomcat, and thus > your changes would be lost in that case. > > An exception to the above, is if you run Tomcat as a Service under > Windows. Then you should set the Java options using the > "tomcatw.exe" GUI interface to the Java/Tomcat settings. See here : > http://wiki.apache.org/tomcat/FAQ/Windows#Q11 OP is clearly using Tomcat on *NIX. He's also already using setenv.sh for this purpose, exactly as he's supposed to be doing. This thread is all over the place with no help give so far :( - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFsHUACgkQ9CaO5/Lv0PBjKACgjQj9UpPqPt2X2PwKuDddnvHT gAMAniO4Uh9K4Jv/Ttq11EjQdrbZI/G2 =ZWwH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: nio connector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor, On 5/24/16 6:52 PM, Igor Cicimov wrote: > On 24 May 2016 12:33 pm, "Christopher Schultz" > wrote: >> > Jakub, > > On 5/23/16 8:03 PM, Ja kub wrote: Christopher, Thx for response, pleas confirm or deny if I understand well. BIO uses thread per http connection (tcp connection). (Shame I didn't realize it!) NIO uses thread per request. > > It's more complicated than that, but very close. > With NIO thread is returned to pool as soon as request is finished (doGet ends). > > Yes. > With BIO thread is returned to pool only when tcp connection is closed !!! > > Yes, but even HTTP keepalive has a timeout, and the connection will > be dropped after that timeout, releasing the thread. > Given http://kb.mozillazine.org/Network.http.keep-alive.timeout - Amount of time in seconds to keep keep-alive connections alive. Default: 115 seconds. default tomcat keepAliveTimeout 60 s default tomcat maxThreads is 200 With 200 browsers with ajax pooling server every 50 seconds tomcat connector thread pool will be depleted and client no 201 will not be able to connect to tomcat ? > > Yes. > >> Although there is default accept queue of 100 so theoretically >> the conn 301 will be rejected. Right? Theoretically, yes. The OS has a separate accept queue, so things get a little murky when it comes to exactly which connection will be the first one rejected. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFr38ACgkQ9CaO5/Lv0PCehQCbBnv3VIlGsCzDvU+UTgjcc9i0 ckMAoLC9OKCMkhI7euMOdzQgZKgMAHnP =7eqe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with monitoring with JMX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Edwin, On 5/24/16 6:08 PM, Edwin Quijada wrote: > Tomcat 8.0.33 Java 1.8 Debian 8 Stop Tomcat, change setenv.sh back to use CATALINA_OPTS, and re-launch Tomcat. What is the (sanitized?) command-line you get for the running JVM that results? Usually, "cannot find class" means that some system property has been broken enough to cause the command-line to get all fouled up. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAldFrxgACgkQ9CaO5/Lv0PCYqgCfXTHwjECbO+1GBve+Y2D5gtf8 VCwAnjEIdQColxI54w7WNtWBDryT+z2d =+Lsb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Prepared statements are not cached with XA in tomcat jdbc connection pool implementation
I don't know if it is a bug or not, but I learned today that org.apache.tomcat.jdbc.** is a different tomcat implementation from the default dbcp based implementation (org.apache.tomcat.dbcp.**). And, you seem to use the former one. Therefore, I think you should file a bug in tomcat, not in commons-dbcp, IMHO: - http://tomcat.apache.org/bugreport.html Regards, Woonsan On Wed, May 18, 2016 at 12:51 AM, Sailaja Ravipati wrote: > Thank you. Will do that. > > Regards, > Sailaja. > > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: 18 May 2016 01:24 > To: Tomcat Users List > Subject: Re: Prepared statements are not cached with XA in tomcat jdbc > connection pool implementation > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Sailaja, > > On 5/17/16 6:58 AM, Sailaja Ravipati wrote: >> I am using TomEE version Apache Tomcat Version 7.0.63. I have the >> following test program. >> >> public static void main(String[] args) throws Exception { final >> TransactionManager transactionManager = TransactionManagerFactory >> .getTransactionManager(); final PoolProperties poolProperties = new >> PoolProperties(); SQLServerDataSource dataSource = new >> com.microsoft.sqlserver.jdbc.SQLServerDataSource(); >> dataSource.setUser("sa"); dataSource.setPassword("$9Lserver"); >> dataSource.setURL("jdbc:sqlserver://sdwivedi63ks022:1433;sendStringPar > ametersAsUnicode=false"); >> >> > dataSource.setDatabaseName("himalaya"); >> poolProperties.setDataSource(dataSource); final String >> jdbcInterceptors = >> "org.apache.tomcat.jdbc.pool.interceptor.StatementCache(prepared=true, > callable=true)"; >> >> > poolProperties.setJdbcInterceptors(jdbcInterceptors); >> final org.apache.tomcat.jdbc.pool.DataSource pooledOracleDatasource = >> new org.apache.tomcat.jdbc.pool.XADataSource( poolProperties); final >> javax.sql.DataSource oracleDataSource = new >> org.apache.openejb.resource.jdbc.managed.xa.ManagedXADataSource( >> pooledOracleDatasource, transactionManager, >> TransactionProvider.getTransactionSynchronizationRegistry()); >> Connection connection = oracleDataSource.getConnection(); for(int i=0; >> i<50; i++) { PreparedStatement preparedStatement = >> connection.prepareStatement("insert into MyTableNew values (" + i + >> ")"); System.out.println(preparedStatement.getClass().getName()); >> preparedStatement.execute(); preparedStatement.close(); } >> connection.close(); } >> >> If I run the above program, the output I see is: >> com.sun.proxy.$Proxy11 >> >> If I just change the above program to use XA datasource, i.e. >> Change the following line SQLServerDataSource dataSource = new >> com.microsoft.sqlserver.jdbc.SQLServerDataSource(); To >> SQLServerXADataSource dataSource = new >> com.microsoft.sqlserver.jdbc.SQLServerXADataSource(); The output is >> : com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement >> >> So, if I use XA datasource, prepared statements are not cached. How do >> I log a defect ? > > The problem would be in commons-dbcp, so you should file a bug report in JIRA > here: > > http://commons.apache.org/proper/commons-dbcp/issue-tracking.html > > Bug reports with complete information (or even a patch!) will get more > attention than those without. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXO3bFAAoJEBzwKT+lPKRY1oAP/iy4c6LQNx/Gcg+24MJry0/t > l30JkJsgeCa6uXgs7JUjCLxmaPjhCF3Fw4FtzwzqUgEY13yTF7jlFhvuq1elOoQx > w0eHpcW39iQ0DJvGvbz6cEpsR902mSSXyt6Ar7AAeZoAs7AlYKhLmp9wKBdqq1pq > PSJcBhrwxA0OcIgDscCj667diUYmmi914LRSUXNwiCCH3ymAMsoXFi63FD1/VxEf > W3vqKxJvmKwhlP1Jia0T9mCusqmwQfct2lJXuU+W9dDyCogkBdv4anDBivdRVJA8 > VYRzHPjQQQOg7dwmXkulRLp1vToqFFaAFDhUVL+RSTX+R+Ee9fg+vqssUD4U6ba/ > GCTXMTMck2/n06dDcNcpfF5M20nFDQ8eBUDqsmbP+NBMrTZfdyUTihCaoRW1x1rv > +YVJuD5TA6bNC6n70bWMLT2ybs3cxplB7lwPueO0t88nBehDqsz+XRSS64Si6hXn > wjKaW+CO7tVMhRmf8g9yKFKppklIUCpWX12iyJ4SRWtAVRIBcZ47HFgXfukPo03A > DcUwpjsSHgvyOUpwWe31mVeQMyY5VDu8lFSjqmaHthqQGvRnGaYUPD3VJd71mobV > AqkNTk3xcySN/sirUx6KVm6rwYClIvN2xQswn5cvFeRjRFO6BCGemjsW7+aF40Mu > +Q3ahYmlTYBownFshBV2 > =Vau+ > -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: JNDI DataSource in Tomcat 8: maxTotal and maxWaitMillis
Hi Mark, On Wed, May 25, 2016 at 4:56 AM, Mark Thomas wrote: > On 24/05/2016 23:23, Woonsan Ko wrote: >> Hi, >> >> Since 8.0, I think we should use maxTotal instead of maxActive and >> maxWaitMillis instead of maxWait. [1,2] >> However, if I use maxTotal for instance, the jmx console doesn't show >> it but show the old maxActive value (100, probably the default >> value?). >> Browsing the source, o.a.t.jdbc.pool.PoolConfiguration doesn't seem to >> consider both. >> o.a.t.jdbc.pool.DataSourceFactory#parsePoolProperties(Properties) >> seems even unaware of those new properties. >> Would this be a bug in either code or documentation? >> >> Another question is, why does it ignore 'poolPreparedStatements' >> parameter even though it's supported by the underlying dbcp? > > You are mixing up the two connection pooling options. The default DBCP > based one (org.apache.tomcat.dbcp.dbcp2) and the Tomcat implementation > (org.apache.tomcat.jdbc). > > Which one are you actually using? Thank you very much for asking the right question! :-) Indeed, I overlooked the factory attribute in the existing configuration. The DataSource configuration contained the following: factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" My bad. I should have taken a closer look at it. After removing the attribute to use the default factory (org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory), it works like a charm! Cheers, Woonsan > > Matk > > >> >> Regards, >> >> Woonsan >> >> [1] https://tomcat.apache.org/migration-8.html#Database_Connection_Pooling >> [2] >> http://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html >> >> - >> 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: tomcat8.0.33 classpath/classloader issues
You can put in catalina.properties. There is entry with common.loader in catalina.properties under conf folder. Please see below # Note: Values are enclosed in double quotes ("...") in case either the # ${catalina.base} path or the ${catalina.home} path contains a comma. common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/db2/*.jar","${catalina.home}/mq/*.jar","${catalina.home}/wasejb/*.jar","${catalina.home}/conf","${catalina.home}/properties" Hope this helps. Ambica. -Original Message- From: Venkata Reddy P [mailto:venkata.re...@trianz.com] Sent: Wednesday, May 25, 2016 5:43 AM To: Tomcat Users List Subject: RE: tomcat8.0.33 classpath/classloader issues Many thanks Mark. I will give a retry it. Is there a way to set all jars in folder (c:\poc\lib) to classpath on startup? -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, May 25, 2016 2:25 PM To: Tomcat Users List Subject: Re: tomcat8.0.33 classpath/classloader issues On 25/05/2016 06:14, Venkata Reddy P wrote: > Can anyone please help me on this? Don't mess with the classpath. You should (almost) never need to do that. Put shared JARs in Tomcat's lib directory. Mark > > From: Venkata Reddy P > Sent: 24 May 2016 14:44 > To: Tomcat Users List > Subject: tomcat8.0.33 classpath/classloader issues > > Hi, > > Currently I am migrating my existing tomcat6.0.x to tomcat8.0.33 version. > > > 1) I have deployed four web applications inside webapps folder, all > these 4 web applications use the few common jars which I was (in tomcat6.0.x) > setting as classpath variable in setclasspath.bat as below > rem Adding classpath to existing path. > set CLASSPATH=%CLASSPATH%;%PROJECT_CP% > > %PROJECT_CP% is set by the list of project jars. This way of > setting classpath is not working in tomcat8.0.33. Is it still valid way of > setting the classpath in tomcat8.0.x? > > > 2) Some unknown reason when I start tomcat8.0.x server by running > \bin\startup.bat, > > Its unable to load the default tomcat jars from \lib\ folder > > Do we have any limitation in tomcat8.0.33 version? > > > > In both 1) and 2) cases if I have copy all the required jars to primary roo > class loader \ext\lib folder, then it is loading all the jars as > expected. The way of loading through the jre folder is not good practice in > my project to separate the jars. > > > > Could you please help why default tomcat jars not loading and classpath is > not working in tomcat8.0.33 version? > > Many Thanks in advance. > - 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: tomcat8.0.33 classpath/classloader issues
Many thanks Mark. I will give a retry it. Is there a way to set all jars in folder (c:\poc\lib) to classpath on startup? -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, May 25, 2016 2:25 PM To: Tomcat Users List Subject: Re: tomcat8.0.33 classpath/classloader issues On 25/05/2016 06:14, Venkata Reddy P wrote: > Can anyone please help me on this? Don't mess with the classpath. You should (almost) never need to do that. Put shared JARs in Tomcat's lib directory. Mark > > From: Venkata Reddy P > Sent: 24 May 2016 14:44 > To: Tomcat Users List > Subject: tomcat8.0.33 classpath/classloader issues > > Hi, > > Currently I am migrating my existing tomcat6.0.x to tomcat8.0.33 version. > > > 1) I have deployed four web applications inside webapps folder, all > these 4 web applications use the few common jars which I was (in tomcat6.0.x) > setting as classpath variable in setclasspath.bat as below > rem Adding classpath to existing path. > set CLASSPATH=%CLASSPATH%;%PROJECT_CP% > > %PROJECT_CP% is set by the list of project jars. This way of > setting classpath is not working in tomcat8.0.33. Is it still valid way of > setting the classpath in tomcat8.0.x? > > > 2) Some unknown reason when I start tomcat8.0.x server by running > \bin\startup.bat, > > Its unable to load the default tomcat jars from \lib\ folder > > Do we have any limitation in tomcat8.0.33 version? > > > > In both 1) and 2) cases if I have copy all the required jars to primary roo > class loader \ext\lib folder, then it is loading all the jars as > expected. The way of loading through the jre folder is not good practice in > my project to separate the jars. > > > > Could you please help why default tomcat jars not loading and classpath is > not working in tomcat8.0.33 version? > > Many Thanks in advance. > - 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: Integrated Windows Authentication for TomCat 7
On 25/05/2016 07:02, Clinton Breed wrote: > Good day All > > We are running a web app named n-able Helpdesk Manager via TomCat 7 on a > Windows Server 2008. > > The Tomcat gets installed via the n-able helpdesk installation. I have > been assigned a task to get the Helpdesk Webapp to login automatically > gathering the information from the windows login. (automatic LDAP > authentication) > > I have done some research and found out that it is possible to integrate > the windows authentication through Tomcat (SPNEGO), but my question is, > how to I get past the Login on the Webapp (n-able Helpdesk) > > The authentication options I have on n-able Helpdesk is: > > n-able Help Desk Manager (Where you create user login details) > > CAS 2.0 > > SAML 2.0 > > Servlet Authentication I'd guess this is the option you need. I'd start with a simple web application and make sure that SPNEGO is working correctly. A JSP that displays the current value of HttpServletRequest.getRemoteUser() with an appropriate security constraint should be enough to test with. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JNDI DataSource in Tomcat 8: maxTotal and maxWaitMillis
On 24/05/2016 23:23, Woonsan Ko wrote: > Hi, > > Since 8.0, I think we should use maxTotal instead of maxActive and > maxWaitMillis instead of maxWait. [1,2] > However, if I use maxTotal for instance, the jmx console doesn't show > it but show the old maxActive value (100, probably the default > value?). > Browsing the source, o.a.t.jdbc.pool.PoolConfiguration doesn't seem to > consider both. > o.a.t.jdbc.pool.DataSourceFactory#parsePoolProperties(Properties) > seems even unaware of those new properties. > Would this be a bug in either code or documentation? > > Another question is, why does it ignore 'poolPreparedStatements' > parameter even though it's supported by the underlying dbcp? You are mixing up the two connection pooling options. The default DBCP based one (org.apache.tomcat.dbcp.dbcp2) and the Tomcat implementation (org.apache.tomcat.jdbc). Which one are you actually using? Matk > > Regards, > > Woonsan > > [1] https://tomcat.apache.org/migration-8.html#Database_Connection_Pooling > [2] > http://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html > > - > 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: tomcat8.0.33 classpath/classloader issues
On 25/05/2016 06:14, Venkata Reddy P wrote: > Can anyone please help me on this? Don't mess with the classpath. You should (almost) never need to do that. Put shared JARs in Tomcat's lib directory. Mark > > From: Venkata Reddy P > Sent: 24 May 2016 14:44 > To: Tomcat Users List > Subject: tomcat8.0.33 classpath/classloader issues > > Hi, > > Currently I am migrating my existing tomcat6.0.x to tomcat8.0.33 version. > > > 1) I have deployed four web applications inside webapps folder, all > these 4 web applications use the few common jars which I was (in tomcat6.0.x) > setting as classpath variable in setclasspath.bat as below > rem Adding classpath to existing path. > set CLASSPATH=%CLASSPATH%;%PROJECT_CP% > > %PROJECT_CP% is set by the list of project jars. This way of > setting classpath is not working in tomcat8.0.33. Is it still valid way of > setting the classpath in tomcat8.0.x? > > > 2) Some unknown reason when I start tomcat8.0.x server by running > \bin\startup.bat, > > Its unable to load the default tomcat jars from \lib\ folder > > Do we have any limitation in tomcat8.0.33 version? > > > > In both 1) and 2) cases if I have copy all the required jars to primary roo > class loader \ext\lib folder, then it is loading all the jars as > expected. The way of loading through the jre folder is not good practice in > my project to separate the jars. > > > > Could you please help why default tomcat jars not loading and classpath is > not working in tomcat8.0.33 version? > > Many Thanks in advance. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org