Re: persistance cache
Hi. The recommendation on this forum is to not use top posting, but to keep the flow of conversation natural, and respond below the question to which your question refers. See http://tomcat.apache.org/lists.html, Important, 6) Kaouthar Ghorbel wrote: 2015-06-23 12:00 GMT+01:00 André Warnier a...@ice-sa.com: hello. Kaouthar Ghorbel wrote: hello, I have a method that returns a list of items when I change the data in this list in the database ,the return of the method does not take into account this change. here is the configuration of persistance.xml ?xml version=1.0 encoding=UTF-8? persistence version=2.1 xmlns=http://xmlns.jcp.org/xml/ns/persistence xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd; persistence-unit name=persistancePU transaction-type=RESOURCE_LOCAL providerorg.eclipse.persistence.jpa.PersistenceProvider/provider classcom.csys.pointeuse2.model.AccessControl/class classcom.csys.pointeuse2.model.Accompagnantgouvernante/class classcom.csys.pointeuse2.model.Chambre/class classcom.csys.pointeuse2.model.Client/class classcom.csys.pointeuse2.model.EtatCha/class classcom.csys.pointeuse2.model.EtatChambre/class classcom.csys.pointeuse2.model.Etatmessage/class classcom.csys.pointeuse2.model.Messagechambre/class classcom.csys.pointeuse2.model.PrmEtage/class exclude-unlisted-classestrue/exclude-unlisted-classes shared-cache-modeNONE/shared-cache-mode validation-modeNONE/validation-mode properties property name=javax.persistence.jdbc.url value=jdbc:sqlserver://192.168.2.58:1415;databaseName=database/ property name=javax.persistence.jdbc.password value=12355/ property name=javax.persistence.jdbc.driver value=com.microsoft.sqlserver.jdbc.SQLServerDriver/ property name=javax.persistence.jdbc.user value=ka/ /properties /persistence-unit /persistence thanks ... But is this related to Tomcat somehow ? If yes, could you explain how, and provide some versions of the software used ? hello, I think it is a cache problem , because when I restart tomcat the resulting list is correct, the problem lies only for this method. i use tomcat 8.0.2 Honestly, I am a bit out of my depth here. But the above configuration which you provide (thank you) leads me to believe that the cache in question belongs to the /application/ (*), not to Tomcat. The fact that the cache is cleared when you restart Tomcat, is probably due to the fact that when you restart Tomcat, you also restart the application, which probably clears the cache /of the application/. I don't think that Tomcat itself knows anything about this cache. Or am I reading this wrong ? (*) which from the names used (**), seems to be some kind of hotel rooms management system (**) and my knowledge of French, and my long-time-ago studies in hotel management.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: persistance cache
hello, I think it is a cache problem , because when I restart tomcat the resulting list is correct, the problem lies only for this method. i use tomcat 8.0.2 2015-06-23 12:00 GMT+01:00 André Warnier a...@ice-sa.com: hello. Kaouthar Ghorbel wrote: hello, I have a method that returns a list of items when I change the data in this list in the database ,the return of the method does not take into account this change. here is the configuration of persistance.xml ?xml version=1.0 encoding=UTF-8? persistence version=2.1 xmlns=http://xmlns.jcp.org/xml/ns/persistence xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd; persistence-unit name=persistancePU transaction-type=RESOURCE_LOCAL providerorg.eclipse.persistence.jpa.PersistenceProvider/provider classcom.csys.pointeuse2.model.AccessControl/class classcom.csys.pointeuse2.model.Accompagnantgouvernante/class classcom.csys.pointeuse2.model.Chambre/class classcom.csys.pointeuse2.model.Client/class classcom.csys.pointeuse2.model.EtatCha/class classcom.csys.pointeuse2.model.EtatChambre/class classcom.csys.pointeuse2.model.Etatmessage/class classcom.csys.pointeuse2.model.Messagechambre/class classcom.csys.pointeuse2.model.PrmEtage/class exclude-unlisted-classestrue/exclude-unlisted-classes shared-cache-modeNONE/shared-cache-mode validation-modeNONE/validation-mode properties property name=javax.persistence.jdbc.url value=jdbc:sqlserver://192.168.2.58:1415;databaseName=database/ property name=javax.persistence.jdbc.password value=12355/ property name=javax.persistence.jdbc.driver value=com.microsoft.sqlserver.jdbc.SQLServerDriver/ property name=javax.persistence.jdbc.user value=ka/ /properties /persistence-unit /persistence thanks ... But is this related to Tomcat somehow ? If yes, could you explain how, and provide some versions of the software used ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: the session tracking of tomcat 6 and tomcat 7 behaves strangely
On Wed, 2015-06-24 at 11:55 +0200, André Warnier wrote: Hi. Hi. The recommendation on this forum is to not use top posting, but to keep the flow of conversation natural, and respond below the question to which your question refers. See http://tomcat.apache.org/lists.html, Important, 6) I have modified you latest post accordingly below. chedana jayasinghe wrote: On Tue, Jun 23, 2015 at 2:46 PM, André Warnier a...@ice-sa.com wrote: chedana jayasinghe wrote: In my web application, in a jsp there is a javascript which sends request to a servlet every twenty seconds, so it kills my applications user idle time tracking by resetting the lastAccessed time in session. the funny thing is lastAccessed time doesn't get updated in tomcat 6 and my applications idle time tracking works fine in it, but in 7 it gets updated and kills that functionality of the application . so I'm little bit confused about the changes in the session tracking of tomcat 6 and tomcat 7. I don't know what happened in Tomcat 6 as compared to what happens in other versions. But from a purely logical point of view, I would tend to think that, from the server point of view, whether a request comes from the user pressing a button or from a javascript module in a page sending a request, does not make a difference : the application has been accessed, so the last accessed time should be updated. That is probably the point even, of many such javascript snippets out there in the wild. So again from a purely logical point of view, if Tomcat 6 then did not update the last access time, that would sound more like a bug, that was corrected later. Maybe the fact that it updates this or not, depends on whether the application that is called retrieves the session or not, and if so you may have control over it, by making sure that whatever your javascript calls, it does /not/ retrieve the session. Caveat : I do not really /know/ how it works, so there is a lot of speculation here. I just put a debug point an checked. In tomcat 6,the request comes to the servlet with a null session,but in tomcat 7 and later versions the valid session is there in the request Yes, but the /call/ that contains this jsession-id, comes from the javascript that is in the HTML page currently shown in the browser. So the question is : why does that /call/, now, contain this jsessionid parameter, when under Tomcat 6 it did not ? Or to put this another way : how does the local javascript in the browser *know* this jsession-id ? Or in yet another way : the javascript in the browser does not /know/ if it is talking to a Tomcat 6 or a Tomcat 7 or a Tomcat 8 server, right ? So how comes that in one case, it sends a request /without/ a jsessionid, and in the other cases /with/ a jsessionid ? Haven't been following this thread too closely, so ignore this if it's a total non sequitur, but perhaps TC6 does NOT mark the cookie as HttpOnly while later versions do? - 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: the session tracking of tomcat 6 and tomcat 7 behaves strangely
Hi. Hi. The recommendation on this forum is to not use top posting, but to keep the flow of conversation natural, and respond below the question to which your question refers. See http://tomcat.apache.org/lists.html, Important, 6) I have modified you latest post accordingly below. chedana jayasinghe wrote: On Tue, Jun 23, 2015 at 2:46 PM, André Warnier a...@ice-sa.com wrote: chedana jayasinghe wrote: In my web application, in a jsp there is a javascript which sends request to a servlet every twenty seconds, so it kills my applications user idle time tracking by resetting the lastAccessed time in session. the funny thing is lastAccessed time doesn't get updated in tomcat 6 and my applications idle time tracking works fine in it, but in 7 it gets updated and kills that functionality of the application . so I'm little bit confused about the changes in the session tracking of tomcat 6 and tomcat 7. I don't know what happened in Tomcat 6 as compared to what happens in other versions. But from a purely logical point of view, I would tend to think that, from the server point of view, whether a request comes from the user pressing a button or from a javascript module in a page sending a request, does not make a difference : the application has been accessed, so the last accessed time should be updated. That is probably the point even, of many such javascript snippets out there in the wild. So again from a purely logical point of view, if Tomcat 6 then did not update the last access time, that would sound more like a bug, that was corrected later. Maybe the fact that it updates this or not, depends on whether the application that is called retrieves the session or not, and if so you may have control over it, by making sure that whatever your javascript calls, it does /not/ retrieve the session. Caveat : I do not really /know/ how it works, so there is a lot of speculation here. I just put a debug point an checked. In tomcat 6,the request comes to the servlet with a null session,but in tomcat 7 and later versions the valid session is there in the request Yes, but the /call/ that contains this jsession-id, comes from the javascript that is in the HTML page currently shown in the browser. So the question is : why does that /call/, now, contain this jsessionid parameter, when under Tomcat 6 it did not ? Or to put this another way : how does the local javascript in the browser *know* this jsession-id ? Or in yet another way : the javascript in the browser does not /know/ if it is talking to a Tomcat 6 or a Tomcat 7 or a Tomcat 8 server, right ? So how comes that in one case, it sends a request /without/ a jsessionid, and in the other cases /with/ a jsessionid ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. You know, I don't want to discourage you, but.. Assuming even that this was a bug that was fixed on its own, and not some side-effect of some other change.. As you know, Tomcat is an open-source and free software, developed and supported by volunteers, who apart from their Tomcat involvement, all have a paying job which they do on the side.. This user's list is the same. Tomcat 6.0.24 is at least 5 years old. The current Tomcat version is 8.0.23. Between these two, there are 5 years and probably close to 100 versions. Some of these versions correct real bugs or security issues which could leave any lower version vulnerable to hacking. The Tomcat developers, having a limited amount of time to dedicate to it, rather understandably prefer to spend this time working on and supporting the latest version, rather than very old ones. All of this to say that unless there is a very strong incentive for someone to go and dig through the documentation and the code, your chances of getting real help on this apparently minor and peripheral issue, affecting an old version of Tomcat but not more recent ones, are really slim. If your sysadmin does not understand the benefits of upgrading to a more recent version, rather than this very old one, then the problem is with him, not with you and not with the Tomcat developers. Maybe you should just take the change logs, starting with 6.0.44 and working back to 6.0.24, append them to one another, and send this to him as a token of what he is missing in terms of bug corrections and security fixes, by /not/ upgrading. And if he still does not understand the issue, or cannot give you a better reason to want to stay with 6.0.24, send the list to his boss. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2015 2:40 PM, André Warnier wrote: Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. You know, I don't want to discourage you, but.. Assuming even that this was a bug that was fixed on its own, and not some side-effect of some other change.. As you know, Tomcat is an open-source and free software, developed and supported by volunteers, who apart from their Tomcat involvement, all have a paying job which they do on the side.. This user's list is the same. Tomcat 6.0.24 is at least 5 years old. The current Tomcat version is 8.0.23. Between these two, there are 5 years and probably close to 100 versions. Some of these versions correct real bugs or security issues which could leave any lower version vulnerable to hacking. The Tomcat developers, having a limited amount of time to dedicate to it, rather understandably prefer to spend this time working on and supporting the latest version, rather than very old ones. All of this to say that unless there is a very strong incentive for someone to go and dig through the documentation and the code, your chances of getting real help on this apparently minor and peripheral issue, affecting an old version of Tomcat but not more recent ones, are really slim. If your sysadmin does not understand the benefits of upgrading to a more recent version, rather than this very old one, then the problem is with him, not with you and not with the Tomcat developers. Maybe you should just take the change logs, starting with 6.0.44 and working back to 6.0.24, append them to one another, and send this to him as a token of what he is missing in terms of bug corrections and security fixes, by /not/ upgrading. And if he still does not understand the issue, or cannot give you a better reason to want to stay with 6.0.24, send the list to his boss. There's another issue when comparing vendor-packaged versus Apache-distributed Tomcat versions. Vendors often backport various fixes from later Apache-distributed versions to vendor-packaged versions. For example, you may see the following in RedHat (I'm running Fedora 22 or CentOS 6) distributions: CentOS 6 Name: tomcat6 Arch: x86_64 Version : 6.0.24 Release : 83.el6_6 Size: 92 k Repo: updates First of all, you have to select Tomcat 6 as opposed to Tomcat on CentOS 6.6. I understand that the Tomcat 7 version is only available in the EPEL repository. Here's the information for tomcat.noarch from the EPEL repository. Name: tomcat Arch: noarch Version : 7.0.33 Release : 4.el6 Size: 86 k Repo: epel The key thing to look at in both of these listings is the Release tag. RedHat (and I suppose other vendors) release updates to their packages that include backports for certain issues. In general, RedHat addresses security issues, but avoids backporting API changes between releases of their Linux platform. It is very difficult to compare RedHat's version of 6.0.24 or 7.0.33 with the Apache release. You would have to compare both sets of change logs to find out how RedHat's release compared to Apache's release. Then, since it doesn't appear that this particular problem was uniquely identified in the Apache Tomcat changelogs, you would have to determine what change (and when) fixed the issue. Finally, you would then have to lobby RedHat to include the appropriate change into their repackaging of Tomcat. Lots of work . . . This is one of the reasons why most people on the list advocate using Apache-distributed packages. In the end, it's easier for everyone (mailing list members, Apache Tomcat users, and system administrators). As André pointed out above, this is a system administrator issue, not a Tomcat issue. If there are policies in place that preclude third party packaged applications running in production, then there are also corporate policy issues. In short, there are few reasons to stay with a vendor-distributed packaging of Tomcat, and quite a few good reasons to move to the Apache-distributed packages. . . . happily running Apache-distributed packages everywhere /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2
Re: Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
Le 25 juin 2015 à 00:23, Mark Eggers its_toas...@yahoo.com.INVALID a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/24/2015 2:40 PM, André Warnier wrote: Pascal Abaziou wrote: Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. You know, I don't want to discourage you, but.. Assuming even that this was a bug that was fixed on its own, and not some side-effect of some other change.. As you know, Tomcat is an open-source and free software, developed and supported by volunteers, who apart from their Tomcat involvement, all have a paying job which they do on the side.. This user's list is the same. Tomcat 6.0.24 is at least 5 years old. The current Tomcat version is 8.0.23. Between these two, there are 5 years and probably close to 100 versions. Some of these versions correct real bugs or security issues which could leave any lower version vulnerable to hacking. The Tomcat developers, having a limited amount of time to dedicate to it, rather understandably prefer to spend this time working on and supporting the latest version, rather than very old ones. All of this to say that unless there is a very strong incentive for someone to go and dig through the documentation and the code, your chances of getting real help on this apparently minor and peripheral issue, affecting an old version of Tomcat but not more recent ones, are really slim. If your sysadmin does not understand the benefits of upgrading to a more recent version, rather than this very old one, then the problem is with him, not with you and not with the Tomcat developers. Maybe you should just take the change logs, starting with 6.0.44 and working back to 6.0.24, append them to one another, and send this to him as a token of what he is missing in terms of bug corrections and security fixes, by /not/ upgrading. And if he still does not understand the issue, or cannot give you a better reason to want to stay with 6.0.24, send the list to his boss. There's another issue when comparing vendor-packaged versus Apache-distributed Tomcat versions. Vendors often backport various fixes from later Apache-distributed versions to vendor-packaged versions. For example, you may see the following in RedHat (I'm running Fedora 22 or CentOS 6) distributions: CentOS 6 Name: tomcat6 Arch: x86_64 Version : 6.0.24 Release : 83.el6_6 Size: 92 k Repo: updates First of all, you have to select Tomcat 6 as opposed to Tomcat on CentOS 6.6. I understand that the Tomcat 7 version is only available in the EPEL repository. Here's the information for tomcat.noarch from the EPEL repository. Name: tomcat Arch: noarch Version : 7.0.33 Release : 4.el6 Size: 86 k Repo: epel The key thing to look at in both of these listings is the Release tag. RedHat (and I suppose other vendors) release updates to their packages that include backports for certain issues. In general, RedHat addresses security issues, but avoids backporting API changes between releases of their Linux platform. It is very difficult to compare RedHat's version of 6.0.24 or 7.0.33 with the Apache release. You would have to compare both sets of change logs to find out how RedHat's release compared to Apache's release. Then, since it doesn't appear that this particular problem was uniquely identified in the Apache Tomcat changelogs, you would have to determine what change (and when) fixed the issue. Finally, you would then have to lobby RedHat to include the appropriate change into their repackaging of Tomcat. Lots of work . . . This is one of the reasons why most people on the list advocate using Apache-distributed packages. In the end, it's easier for everyone (mailing list members, Apache Tomcat users, and system administrators). As André pointed out above, this is a system administrator issue, not a Tomcat issue. If there are policies in place that preclude third party packaged applications running in production, then there are also corporate policy issues. In short, there are few reasons to stay with a vendor-distributed packaging of Tomcat, and quite a few good reasons to move to the Apache-distributed packages. . . . happily running
Re: useServerCipherSuitesOrder in 7.0.62
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 6/15/15 10:08 AM, George Stanchev wrote: Is there any chance for the OpenSSL-style ciphers to be backported to the 7 release line? I'm not sure. The biggest problem with the OpenSSL-style ciphers is maintaining the mapping, which might change with every release of Java and/or OpenSSL. Maintaining it in Tomcat's trunk and 8 is already double the work... adding Tomcat 7 is even more work. I think what might make sense is to wrap a command-line program around the trunk/8.0.x utility that does the mapping to build something like OpenSSL's ciphers command, but that dumps-out JSSE-style cipher suites . Then that could be used independently of any version of Tomcat for those versions that don't directly-support the openssl-style cipher suites configuration. What do you think? Another possibility would be to maintain the mapping somewhere other than code (where it currently is), and then share that mapping between the various versions, perhaps using svn external links. Then the maping gets updated in a single place and all supporting versions of Tomcat can pick it up. I'll defer to markt who mostly wrote the OpenSSL-JSSE bridge code to decide if that might work. - -chris -Original Message- From: George Stanchev [mailto:gstanc...@serena.com] Sent: Saturday, June 13, 2015 11:41 AM To: Tomcat Users List Subject: RE: useServerCipherSuitesOrder in 7.0.62 Thanks Konstantin, I apologize for the shortsightness. I guess I must have had a space in the search dialog. Thanks for the answers! Cheers, George -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Saturday, June 13, 2015 7:26 AM To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 7.0.62 2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com: Hi, I was looking at [1] and it looks the new attribute is available in 7.0.61 onwards as per Violeta's comment. However I cannot find this new attribute in the HTTP connector documentation [2] nor the changelog [3]. Can someone confirm or deny the availability of this attribute (useServerCipherSuitesOrder) in Tomcat 7.0.62. #55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60). useServerCipherSuitesOrder is mentioned in [2] (in SSL Support - BIO and NIO section). Note that this feature requires running with Java 8. As a follow up question, I seem to remember that 8.0.latest supports OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 also support this or it wasn't backported? It was not backported. Relevant classes are in package org.apache.tomcat.util.net.jsse.openssl: OpenSSLCipherConfigurationParser etc. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html Best regards, Konstantin Kolinko - 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: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVisCdAAoJEBzwKT+lPKRYDlAP/iKygYxuv7ie4h2HG16FUu3H 3EJ/f3mAVfsG/Z+Kwd3nGuC44vFTyLENWoRp0fBM6+0Awooe1uryFbKnFKy4ooJ/ ciLEo7cobKZmpbaeRbOIqxOrdXw66Z2uSeGoZ5pDXvAR23AObiW22ccereFcK3KF n027QdKzpn9TWn4rK4DLxD3gjv5NzZzZFxVdX+tMp36VxJIii+r8q8QiQzB8nssW F3yYjPHFFo+hP038hK9Pbc5M5CQvvSiU76HrxLOhEIM0YLKvsuf6PKffYCgF63ip Vqg+ctY8JotBkCpsBZ7s+lVxP0MTnzDoP8bVJdUU2/xJO5p3dOz2jUd3LaCVPNoy K/rMqGO3PiXw0ip3fkSXxxQX1q/iR1N3sosjMqcq0kyiJKvjzu7wwNktF4asIeMj Xagj6oepH0yaHTuVBz8NLaynBOoKmxQmpL8CuBBLtxkzSxDisWroTcdlDrwE4zo5 gKPKofW6T7j21cTB2xWC/DrPWmE/7L7HvglLEPy7+mcSQtG1cGwG9VKRlb0kTrv9 Y95a7AbjWFbYSD6I9Ur7mom8ZQv1B1L1su05pMQYRqWKyOmKWjYhUS73c0AQsGKi ZEYH2aQ3v6/e7jUrEmmUxM8dBRvTjjOtTIKdX8uRSYSRWQkSGTfP4sJFRuARX476 asRVs+Uiyz2o9npMbaLj =D15s -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: persistance cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kaouthar, On 6/24/15 3:49 AM, Kaouthar Ghorbel wrote: hello, I think it is a cache problem , because when I restart tomcat the resulting list is correct, the problem lies only for this method. Tomcat doesn't handle anything with persistence, other than (if configured) providing a DataSource that can be used with it. No caching, no nothing. You might want to ask on a forum that is familiar with your persistence mechanism. i use tomcat 8.0.2 You need to upgrade. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVir8oAAoJEBzwKT+lPKRYXcMP/36cHP2Pt/1wzd3O43MK5adY khSdWU7j6ePQQBWlav1QxOZuqFHe6R+6J7RdmCbT0WCHdXIi7TG+6IdMhblZBXy8 9duFBSJ2rWYg8LB2tf/HWaM6j4SetJrTcH9KZ8tFBH9EYiqJDq0XTypbDkhZNlvN nMVcnE9h1YAibh6kZld64g+Lj4j08GeIFbLpvvdeZZacKN+4BbmFmzMc/DV2PIj2 nPxs9o/AMi0G+VFU6KkUQEmxq4tUwLQAn/+5sfwJOqDDA8EQgpEW5sp37qICdXVr d/xIXZdMwp3J2YUZ0zJuPKz9VD0ZbarhSM83dv+2CO2ONfpHCEUWI0D4SXMi0b3c QR7QrRwefsNvh1Ae2Q9WOzAWxRRx5HulbWdioo9QqIAuChGoxBiXiwqzw/JWEb+u FCLQdRm6Fzl/7BaUrmjBNiXD7w+JplVV3mF+fcrizTY1rN2vEvprUzqyA1bpG8Wh m5iFGEAI9UukfF1kn14bfGPKOiSGB20WVDRKYkJ7Y5nm7gElwMKbAG1hDI/17wP4 ScyhFg3IyCI4cO1kszz6WAuhkunMuVafAxwIOoF3THFeX0fdMulRBRLYE/SyWM7/ oqcS6UBJdRyQULinU6XmF2jAQoxFmhUEZ+yMc7+JlOlFh53gCW6EsFM4Ahgnisd+ LZNe6pfpRHcgJBZM9iQE =+wGF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Can i use Tomcat 7 catalina-ws.jar in Tomcat 8???
Hi all, A rapid question: colud i place the tomcat 7 catalina-ws.jar inside a new tomcat 8 installation ? Is it compatibile? I' ve not found any topic about it. If this qestion was already made, give me the link and sorry for my bad search. Thanks a lot, Agharta - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Settings when SSL terminates on the front-end
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeff, On 6/24/15 11:39 AM, Jeffrey Janner wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, June 23, 2015 3:18 PM To: Tomcat Users List Subject: Re: Settings when SSL terminates on the front-end On 17/06/2015 19:08, Jeffrey Janner wrote: I've been deploying letting Tomcat do it all when it came to connectors and SSL, with the app forcing everything to SSL in the security-constraints section. Now I'm setting up a haproxy front- end that will both terminate the SSL and take care of the redirect from HTTP to HTTPS for me and tomcat only running a standard HTTP port on 8080. So my question is, Is it still important for the app to know that it operating secure, and if so, what settings are a must? Yes it is extremely important. You need secure=true for everything received over HTTPS and secure=false for everything received over HTTP. It is simpler in your case since Tomcat only ever sees traffic that has been received over HTTPS. There are several ways to ensure secure=true In your case, setting on the connector is the simplest and best option. If proxying over AJP, the AJP connector takes care of it. The RemoteIP[Valve|Filter] or the SSLValve can handle this if proxying over HTTP. There are several reasons it is important (the first reason is the big one): 1. cookies created over secure connections will have the secure flag set which will ensure that browsers never send the cookie over HTTP. I once watched a customer go very white while I was explaining this when they realised that their banking app was sending authentication cookies over HTTP connections. 2. The user data constraint in web.xml will only be satisfied if secure=true HTH, Mark Thanks for the confirmation Mark. That is what I thought I'd gleaned from previous posts. I will be sure to mark the http connection secure=true in my Tomcat instances. I gather from #2 above, that having the secure setting on the http port, it won't really matter if the security-constraints exists in the web.xml or not, because Tomcat will assume it is already secure. Ergo, I don't have to get the developers to remove it. Tomcat will assume that it is secure, but you should definitely leave it in web.xml in case the deployment changes. You always want the application to protect itself. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVitHpAAoJEBzwKT+lPKRYgZYQAJwGeIWkxjzEFlKeTV4WjF8i eujTfhQv4z2YPvchW8w/evykk/7jb2NGfGvJEHQ1EGm/FcSEs3wEX1/BT5CCjQ1U bVWoBrL9VcDZ4TnYVH+NvYvEa+r4oOB7gO57FjooS9vtbIQkt/0F7F1cfyZwBwmB UMMPy4K1l3+sFQvjo19xND16hx5Y21I5ANYCgNmIygMi5O0hit9qE/hlwUUlQxXq 1LMjcNkC3Ls7SvIg5mUIEIMMTovNUJpaWT86nPrcO1AX5IkXhUXWvlhyqncti1M5 dSg3CzleMRM1PYx4jGsMt3bri8MVMYknc99WpMFCTVDletusdJQvAqyaB4WKIrdi /vX1SldamSVhwBtqT6xooEIagwOotG5GjUokd4UTOmHa56BPmER+L1VZGNjB4HzV pA5cyp5Ez7LQ381I94klklo2B99o/c4Gadu56YviS2xNcBpZA+s+GshwQeaKuQOJ LbeyZWpXnb2Bvq2whr7cXNUVEr2j5eKvYo0eLMLz2LdJmkxfjWg808NqOZ1FpxW9 7ysh7ryuhydhO83MPNJkz29ObbueQ53UUbPLPo6Gx2ou4v2M4KVV9KNOltdHbVyG gaFXKxyBExMDRdYNOG2+v+9S5dCBhUBQr6sQtSFGLdIHfTb8ni68wRWhtvuLX2ep 0W8YmmsZvn62TkVz6F14 =yD+Y -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Settings when SSL terminates on the front-end
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, June 23, 2015 3:18 PM To: Tomcat Users List Subject: Re: Settings when SSL terminates on the front-end On 17/06/2015 19:08, Jeffrey Janner wrote: I've been deploying letting Tomcat do it all when it came to connectors and SSL, with the app forcing everything to SSL in the security-constraints section. Now I'm setting up a haproxy front- end that will both terminate the SSL and take care of the redirect from HTTP to HTTPS for me and tomcat only running a standard HTTP port on 8080. So my question is, Is it still important for the app to know that it operating secure, and if so, what settings are a must? Yes it is extremely important. You need secure=true for everything received over HTTPS and secure=false for everything received over HTTP. It is simpler in your case since Tomcat only ever sees traffic that has been received over HTTPS. There are several ways to ensure secure=true In your case, setting on the connector is the simplest and best option. If proxying over AJP, the AJP connector takes care of it. The RemoteIP[Valve|Filter] or the SSLValve can handle this if proxying over HTTP. There are several reasons it is important (the first reason is the big one): 1. cookies created over secure connections will have the secure flag set which will ensure that browsers never send the cookie over HTTP. I once watched a customer go very white while I was explaining this when they realised that their banking app was sending authentication cookies over HTTP connections. 2. The user data constraint in web.xml will only be satisfied if secure=true HTH, Mark Thanks for the confirmation Mark. That is what I thought I'd gleaned from previous posts. I will be sure to mark the http connection secure=true in my Tomcat instances. I gather from #2 above, that having the secure setting on the http port, it won't really matter if the security-constraints exists in the web.xml or not, because Tomcat will assume it is already secure. Ergo, I don't have to get the developers to remove it. That is fine with me. Thanks again. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: the session tracking of tomcat 6 and tomcat 7 behaves strangely
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tim, On 6/24/15 7:15 AM, Tim Watts wrote: On Wed, 2015-06-24 at 11:55 +0200, André Warnier wrote: Hi. Hi. The recommendation on this forum is to not use top posting, but to keep the flow of conversation natural, and respond below the question to which your question refers. See http://tomcat.apache.org/lists.html, Important, 6) I have modified you latest post accordingly below. chedana jayasinghe wrote: On Tue, Jun 23, 2015 at 2:46 PM, André Warnier a...@ice-sa.com wrote: chedana jayasinghe wrote: In my web application, in a jsp there is a javascript which sends request to a servlet every twenty seconds, so it kills my applications user idle time tracking by resetting the lastAccessed time in session. the funny thing is lastAccessed time doesn't get updated in tomcat 6 and my applications idle time tracking works fine in it, but in 7 it gets updated and kills that functionality of the application . so I'm little bit confused about the changes in the session tracking of tomcat 6 and tomcat 7. I don't know what happened in Tomcat 6 as compared to what happens in other versions. But from a purely logical point of view, I would tend to think that, from the server point of view, whether a request comes from the user pressing a button or from a javascript module in a page sending a request, does not make a difference : the application has been accessed, so the last accessed time should be updated. That is probably the point even, of many such javascript snippets out there in the wild. So again from a purely logical point of view, if Tomcat 6 then did not update the last access time, that would sound more like a bug, that was corrected later. Maybe the fact that it updates this or not, depends on whether the application that is called retrieves the session or not, and if so you may have control over it, by making sure that whatever your javascript calls, it does /not/ retrieve the session. Caveat : I do not really /know/ how it works, so there is a lot of speculation here. I just put a debug point an checked. In tomcat 6,the request comes to the servlet with a null session,but in tomcat 7 and later versions the valid session is there in the request Yes, but the /call/ that contains this jsession-id, comes from the javascript that is in the HTML page currently shown in the browser. So the question is : why does that /call/, now, contain this jsessionid parameter, when under Tomcat 6 it did not ? Or to put this another way : how does the local javascript in the browser *know* this jsession-id ? Or in yet another way : the javascript in the browser does not /know/ if it is talking to a Tomcat 6 or a Tomcat 7 or a Tomcat 8 server, right ? So how comes that in one case, it sends a request /without/ a jsessionid, and in the other cases /with/ a jsessionid ? Haven't been following this thread too closely, so ignore this if it's a total non sequitur, but perhaps TC6 does NOT mark the cookie as HttpOnly while later versions do? That might made sense if this was working as expected in Tomcat 7 but not Tomcat 6, but it's the other way around. I'm thinking something else is going on... it's tough to get responses from the OP, but they keep posting new threads just in case someone else wants to give it a try... - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVir+pAAoJEBzwKT+lPKRYAyEP/3GMWH86+pm1n9uSlSNdzTZ6 MkU4g5cyaIBrYiz2KAGJaaQgJZ0dOCYWjMF68MG40g4NmRK6OcJmAGYK2fl7Co0x 9INFrGk8sMhlcs5ssiijk5AF+d3B/9eZRYoX2YFTWzlSxL8Tttz/LDN6pjx3m1Am 6u9soq0zrIoOpsMLelfQtCBAUgjqtUOIlgG/8+3ufxbvJizhLq4QzQ49rzYzfizc HkoorxzeSbwFaIzl2Gqnm2NcBg/lHM85mxRL8aIcK2yHIoMoHYqu6J24U353uOzM YK0pZypZXDveOfvmWrK01NPYGMLK1IhTR/vB+TwjbZQeVtg25H/xFttXq4NsOBlR EZgEbrma4pNlHofXVLL8sC/y/SSl7H/7MmRvVmJNG96gHmqN1SnaOoNprwtB24lY IZN4flZ9Ur3tblW2PE/xVlWTn6bcirheTopne56lpQUbc8ff2s2tRajcBpCsjL+e GgDjRG6lpigfOGPZKZ3lILWEtzytQXz+VPfEdHjFoaH0pIFOXPYFoTocopnrFHwz zTZ0RK7Uda0FY56KHPEBljhmOHnn1CzcMY/VGISLC61FpGadL7hmvwppuFIoMIZQ I5Ouu3kq2/vrMmOlfLnttWl9T2jP/4PBE36H7oMrboDDA5CJrrV2qo01tD3m8ghR mN3TxA/TKKTVxqTp8lWT =u+vX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: useServerCipherSuitesOrder in 7.0.62
Hi Christopher, (Apologies for top posting, I cannot find a way to switch to quote for Outook) Having an utility is interesting idea but it will not address the regular expression rules that OpenSSL support. For example, I was porting Mozilla's Server Side TLS ciphers [1] to our 7.0.62 the other day and at the end you have: ...:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA So after mapping all the explicit ones before, I had to go and look for rest of AES suites, then exclude the export suites, ignore the RC4s, etc, etc.I did it, kinda but it was pain in the neck and it is really not the same rule list. Can you point me to the code where 8 and the trunk deal with this? It is not really that big of a deal to not have it since once you set your list you don't touch it until the next security scare, but since it is security related, I thought it would benefit people to be able to have more flexibility on the cipher definitions and might be worth backporting. Regards, George [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29 -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, June 24, 2015 8:37 AM To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 7.0.62 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 6/15/15 10:08 AM, George Stanchev wrote: Is there any chance for the OpenSSL-style ciphers to be backported to the 7 release line? I'm not sure. The biggest problem with the OpenSSL-style ciphers is maintaining the mapping, which might change with every release of Java and/or OpenSSL. Maintaining it in Tomcat's trunk and 8 is already double the work... adding Tomcat 7 is even more work. I think what might make sense is to wrap a command-line program around the trunk/8.0.x utility that does the mapping to build something like OpenSSL's ciphers command, but that dumps-out JSSE-style cipher suites . Then that could be used independently of any version of Tomcat for those versions that don't directly-support the openssl-style cipher suites configuration. What do you think? Another possibility would be to maintain the mapping somewhere other than code (where it currently is), and then share that mapping between the various versions, perhaps using svn external links. Then the maping gets updated in a single place and all supporting versions of Tomcat can pick it up. I'll defer to markt who mostly wrote the OpenSSL-JSSE bridge code to decide if that might work. - -chris -Original Message- From: George Stanchev [mailto:gstanc...@serena.com] Sent: Saturday, June 13, 2015 11:41 AM To: Tomcat Users List Subject: RE: useServerCipherSuitesOrder in 7.0.62 Thanks Konstantin, I apologize for the shortsightness. I guess I must have had a space in the search dialog. Thanks for the answers! Cheers, George -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Saturday, June 13, 2015 7:26 AM To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 7.0.62 2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com: Hi, I was looking at [1] and it looks the new attribute is available in 7.0.61 onwards as per Violeta's comment. However I cannot find this new attribute in the HTTP connector documentation [2] nor the changelog [3]. Can someone confirm or deny the availability of this attribute (useServerCipherSuitesOrder) in Tomcat 7.0.62. #55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60). useServerCipherSuitesOrder is mentioned in [2] (in SSL Support - BIO and NIO section). Note that this feature requires running with Java 8. As a follow up question, I seem to remember that 8.0.latest supports OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 also support this or it wasn't backported? It was not backported. Relevant classes are in package org.apache.tomcat.util.net.jsse.openssl: OpenSSLCipherConfigurationParser etc. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html Best regards, Konstantin Kolinko - 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: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVisCdAAoJEBzwKT+lPKRYDlAP/iKygYxuv7ie4h2HG16FUu3H
Re: useServerCipherSuitesOrder in 7.0.62
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 6/24/15 11:31 AM, George Stanchev wrote: (Apologies for top posting, I cannot find a way to switch to quote for Outook) No problem. Having an utility is interesting idea but it will not address the regular expression rules that OpenSSL support. For example, I was porting Mozilla's Server Side TLS ciphers [1] to our 7.0.62 the other day and at the end you have: ...:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:! aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA So after mapping all the explicit ones before, I had to go and look for rest of AES suites, then exclude the export suites, ignore the RC4s, etc, etc.I did it, kinda but it was pain in the neck and it is really not the same rule list. Can you point me to the code where 8 and the trunk deal with this? It is not really that big of a deal to not have it since once you set your list you don't touch it until the next security scare, but since it is security related, I thought it would benefit people to be able to have more flexibility on the cipher definitions and might be worth backporting. You are looking for org.apache.tomcat.util.net.jsse.openssl.OpenSSLCipherConfigurationParser There are some related files (like Cipher.java), but start in that class right there. I think a simple driver class could take an OpenSSL-style cipher string and dump-out the JSSE-compatible (expanded) cipher suites string. - -chris Regards, George [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compati bility_.28default.29 - -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, June 24, 2015 8:37 AM To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 7.0.62 George, On 6/15/15 10:08 AM, George Stanchev wrote: Is there any chance for the OpenSSL-style ciphers to be backported to the 7 release line? I'm not sure. The biggest problem with the OpenSSL-style ciphers is maintaining the mapping, which might change with every release of Java and/or OpenSSL. Maintaining it in Tomcat's trunk and 8 is already double the work... adding Tomcat 7 is even more work. I think what might make sense is to wrap a command-line program around the trunk/8.0.x utility that does the mapping to build something like OpenSSL's ciphers command, but that dumps-out JSSE-style cipher suites . Then that could be used independently of any version of Tomcat for those versions that don't directly-support the openssl-style cipher suites configuration. What do you think? Another possibility would be to maintain the mapping somewhere other than code (where it currently is), and then share that mapping between the various versions, perhaps using svn external links. Then the maping gets updated in a single place and all supporting versions of Tomcat can pick it up. I'll defer to markt who mostly wrote the OpenSSL-JSSE bridge code to decide if that might work. -chris -Original Message- From: George Stanchev [mailto:gstanc...@serena.com] Sent: Saturday, June 13, 2015 11:41 AM To: Tomcat Users List Subject: RE: useServerCipherSuitesOrder in 7.0.62 Thanks Konstantin, I apologize for the shortsightness. I guess I must have had a space in the search dialog. Thanks for the answers! Cheers, George -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Saturday, June 13, 2015 7:26 AM To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 7.0.62 2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com: Hi, I was looking at [1] and it looks the new attribute is available in 7.0.61 onwards as per Violeta's comment. However I cannot find this new attribute in the HTTP connector documentation [2] nor the changelog [3]. Can someone confirm or deny the availability of this attribute (useServerCipherSuitesOrder) in Tomcat 7.0.62. #55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60). useServerCipherSuitesOrder is mentioned in [2] (in SSL Support - BIO and NIO section). Note that this feature requires running with Java 8. As a follow up question, I seem to remember that 8.0.latest supports OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 also support this or it wasn't backported? It was not backported. Relevant classes are in package org.apache.tomcat.util.net.jsse.openssl: OpenSSLCipherConfigurationParser etc. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional
Disabling Naggle's algorithm / Setting tcpNoDelay programatically for web sockets
Hi, As per tomcat's performance tuning doc, 'tcpNoDelay' can be enabled/disabled at connector level. Is there a programmatic way to set 'tcpNoDelay' to true for web socket connections ? I am using tomcat's proprietary web socket APIs in my application. I have gone though the API documentation of tomcat's proprietary web socket implementation, I didn't see any API which allows application to override the 'tcpNoDelay' value. As per doc for writeTextMessage(CharBuffer msgCb) of 'WsOutbound', for each write, tomcat flushes the socket buffer and sends the new frame with the buffer passed. Does that mean, flushing of socket buffer gives the same effect of disabling naggle's algorithm ? Thanks, Ganesh
Re: useServerCipherSuitesOrder in 7.0.62
On 24/06/2015 16:55, Christopher Schultz wrote: There are some related files (like Cipher.java), but start in that class right there. I think a simple driver class could take an OpenSSL-style cipher string and dump-out the JSSE-compatible (expanded) cipher suites string. The key mapping information is held in the Cipher enumeration. There should be an entry for each known Cipher, excluding a few there aren't implemented (and are unlikely to be implemented) in OpenSSL or JSSE. The tricky part isn't porting the mapping but the unit tests since they depend on which ciphers are enabled in the JRE and the unit tests for older Tomcat versions run on older JREs with fewer ciphers. We could just skip porting the unit tests. Mark -chris Regards, George [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compati bility_.28default.29 -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, June 24, 2015 8:37 AM To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 7.0.62 George, On 6/15/15 10:08 AM, George Stanchev wrote: Is there any chance for the OpenSSL-style ciphers to be backported to the 7 release line? I'm not sure. The biggest problem with the OpenSSL-style ciphers is maintaining the mapping, which might change with every release of Java and/or OpenSSL. Maintaining it in Tomcat's trunk and 8 is already double the work... adding Tomcat 7 is even more work. I think what might make sense is to wrap a command-line program around the trunk/8.0.x utility that does the mapping to build something like OpenSSL's ciphers command, but that dumps-out JSSE-style cipher suites . Then that could be used independently of any version of Tomcat for those versions that don't directly-support the openssl-style cipher suites configuration. What do you think? Another possibility would be to maintain the mapping somewhere other than code (where it currently is), and then share that mapping between the various versions, perhaps using svn external links. Then the maping gets updated in a single place and all supporting versions of Tomcat can pick it up. I'll defer to markt who mostly wrote the OpenSSL-JSSE bridge code to decide if that might work. -chris -Original Message- From: George Stanchev [mailto:gstanc...@serena.com] Sent: Saturday, June 13, 2015 11:41 AM To: Tomcat Users List Subject: RE: useServerCipherSuitesOrder in 7.0.62 Thanks Konstantin, I apologize for the shortsightness. I guess I must have had a space in the search dialog. Thanks for the answers! Cheers, George -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Saturday, June 13, 2015 7:26 AM To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 7.0.62 2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com: Hi, I was looking at [1] and it looks the new attribute is available in 7.0.61 onwards as per Violeta's comment. However I cannot find this new attribute in the HTTP connector documentation [2] nor the changelog [3]. Can someone confirm or deny the availability of this attribute (useServerCipherSuitesOrder) in Tomcat 7.0.62. #55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60). useServerCipherSuitesOrder is mentioned in [2] (in SSL Support - BIO and NIO section). Note that this feature requires running with Java 8. As a follow up question, I seem to remember that 8.0.latest supports OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 also support this or it wasn't backported? It was not backported. Relevant classes are in package org.apache.tomcat.util.net.jsse.openssl: OpenSSLCipherConfigurationParser etc. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html Best regards, Konstantin Kolinko - 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 - To unsubscribe, e-mail:
Re: Can i use Tomcat 7 catalina-ws.jar in Tomcat 8???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Agharta, On 6/24/15 11:17 AM, agharta wrote: Hi all, A rapid question: colud i place the tomcat 7 catalina-ws.jar inside a new tomcat 8 installation ? Why would you want to do something like that? Is it compatibile? Probably not. I've not found any topic about it. Probably nobody ever thought about doing it. If this qestion was already made, give me the link and sorry for my bad search. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVitT9AAoJEBzwKT+lPKRYHrIP/ROx8an/64gWsexbfZk4nIVV e/7GFcLFNJYy1Lty0WujxkdPvRBie6a6PKRZN/trCPjK5GU7IVaORzh12jK6T+Mx GmFT+WRsLKI6y2DcApgb1SRyk6whQdxeuaUdVTgOW2vgZKUgj2tlKvGJWpffHFa9 sALVSTCfYexEpSY8Q6f9ZjeHP6ZIhZpoLz7Q0mNRi9POJlLobYe8l3Co7KRr0xqJ ky1aWZCtBxbehooHh6aFgv9lA53pp/o6sXm62jprpA299uSiEeVXrKhZmckRtaFs 0U+Yr9J4zCqwGlW0rfueQmh7hn4ws9U/s8v9Vn4zsF1+5HGAl+rEBzRx96dx4cvQ oHQXjEeBRukLvmoYAEUfY5/3DvLbdoerhLV/xBDaYis3+QrAGHwJxk3E8CMIDt2q 8szro10Z6hxAiNgJ98H1gen2oZxy+q00lIouMzlghMNcjSc0ryTmCDOQgxbjyUXv O96IiTilJ3ZcBsaexcXFQLjyjuv9VyCy7jcHHizazEnsJ2wvtqpbpNOVX5vTIVzY aQGl5fo4pANcc7axjShO+JAZPfqR73XJ9VOrt34XlcsCGq4GTh8f4a2lEPyxifIW RuZtqDrVERBv+k2opo3FQ+CDWqpcWoba/aD/FPrYL0NqZ7xbztNVFaMsQA6pN6ps 6wIB2+Ai+dum17X3CuRl =jFu1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: useServerCipherSuitesOrder in 7.0.62
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/24/15 12:45 PM, Mark Thomas wrote: On 24/06/2015 16:55, Christopher Schultz wrote: There are some related files (like Cipher.java), but start in that class right there. I think a simple driver class could take an OpenSSL-style cipher string and dump-out the JSSE-compatible (expanded) cipher suites string. The key mapping information is held in the Cipher enumeration. There should be an entry for each known Cipher, excluding a few there aren't implemented (and are unlikely to be implemented) in OpenSSL or JSSE. The tricky part isn't porting the mapping but the unit tests since they depend on which ciphers are enabled in the JRE and the unit tests for older Tomcat versions run on older JREs with fewer ciphers. We could just skip porting the unit tests. But the JRE will happily allow discovery of supported ciphers. Could we simply run the unit tests and white-list only those ciphers that are actually supported by the runtime JRE? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJViuF2AAoJEBzwKT+lPKRYY5AQAMeSk9PLPYUEl9P6K94+C5es xTAHH6/C1hXrQnngQMbAvKnyiVsoTYzAzkh9KqwJ6oXc7Pn97vbIWPcJjG1zNINr bGXASAch8G9kIkPQzOrXQBOu8UDgKqMUNx4ElnPZYQPW0RytS0yF1a8wbFZFhNO9 1EOlTOMxxxn3oxAplVR5xe0IE1x1IbNXPQIrljzz/t+pO5bL4gWYAJuwge+qIMDA Be33HtYG0BRgp9DjcuLUGnAVOTs7ss9Q/HyVEJOxxSm8n/gri0Z/9uB+OrtQ+uwY ACMWi+F/dPlo7lHcDiltvnPMMwHUF0njea7sWWxOKMT8xcwWRK/D7oyHP2Ph4GrD 0GFm04KpQsMiZm1+SxMZMIG+YJVN7Rk7ZfqbTug205MisKsEMMkwsvGIQWhDwm47 fK+lDYWKuW5BeG952hEZBiEb84Sqjh95ceWdpOEtEiv7pV02p3QJbGEbnPe3lZ/w UkMYUwcfuk0l2ABLpdEAfO49LAkRCYS6RUPSYd+0yCgM6OA1DOwqbn7xmpo9aR5R S4o4ivqjXughf5r2lTHHNtRjmNtZ21wlrdLyO70l3OFNKEhA4Q3r4hZobrsKQ6PT 0RyWeLPE9o2cPyRCKr5ZSfCs53yMuvBHuQUiNOXSHCw5kyjYlRIN9m7fxSYnxzog BWtc0hEUkoX8+/pZh4VQ =mtrZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: useServerCipherSuitesOrder in 7.0.62
On 24/06/2015 17:57, Christopher Schultz wrote: Mark, On 6/24/15 12:45 PM, Mark Thomas wrote: On 24/06/2015 16:55, Christopher Schultz wrote: There are some related files (like Cipher.java), but start in that class right there. I think a simple driver class could take an OpenSSL-style cipher string and dump-out the JSSE-compatible (expanded) cipher suites string. The key mapping information is held in the Cipher enumeration. There should be an entry for each known Cipher, excluding a few there aren't implemented (and are unlikely to be implemented) in OpenSSL or JSSE. The tricky part isn't porting the mapping but the unit tests since they depend on which ciphers are enabled in the JRE and the unit tests for older Tomcat versions run on older JREs with fewer ciphers. We could just skip porting the unit tests. But the JRE will happily allow discovery of supported ciphers. Could we simply run the unit tests and white-list only those ciphers that are actually supported by the runtime JRE? You could. It would make the unit tests more complicated. For bonus points you'd need to do the same with OpenSSL. Where it gets really tricky is the some of the OpenSSL filter strings are NO-OPs on older versions. Some have also subtlety changed meanings. By all means go for it, but prepared for there to be some non-trivial edge cases. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 : saerching for a bug fix between 6.0.24 and 6.0.44
Hello, I’m searching for the version that fixes a bug I’ve on a tomcat 6.0.24 (on redhat). As I do not reproduce it on my windows workstation with tomcat 6.0.44, I need elements to argue to upgrade to the sys admin. So the bug : with a REST resource service implemented with Jersey, if there’s no method corresponding to a URI (under the hierarchy that Jersey should handle), Jersey raises a 404 NOT_FOUND error. In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat propagates the 404 not found error. As the sysadmin want to stay on version delivered by redhead, I need elements to motivate an update. I’ve read the tomcat 6 changelog, but did not find when this was fixed. Regards, Pascal - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
