Intermittent failure while deploying war file on Tomcat 8.0.24
Tomcat version: 8.0.24 OS RHEL 6.6 Just one war file (ascws.war) is deployed under it. We are seeing intermittent failure while deploying war file, tomcat logs indicates (zip file is empty) exception is mentioned below. We have verified file is correct (non zero), and only way to recover from error is manually delete ascws folder (from webapp folder) and restart tomcat. FYI.. ascws.war is a symbolic link to other location. ascws is a spring boot based application. We are not able to figure out what is wrong, any help is much appreciated. == 10-Sep-2015 09:47:32.488 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive /opt/apache-tomcat/webapps/ascws.war 10-Sep-2015 09:47:32.628 SEVERE [localhost-startStop-1] org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ascws]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1768) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.catalina.LifecycleException: Failed to start component [org.apache.catalina.webresources.StandardRoot@1690212] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4845) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4975) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) ... 10 more Caused by: org.apache.catalina.LifecycleException: Failed to initialize component [org.apache.catalina.webresources.JarResourceSet@5dd3221b] at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) at org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:699) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) ... 13 more Caused by: java.lang.IllegalArgumentException: java.util.zip.ZipException: zip file is empty at org.apache.catalina.webresources.JarResourceSet.initInternal(JarResourceSet.java:96) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) ... 16 more Caused by: java.util.zip.ZipException: zip file is empty at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(Unknown Source) at java.util.zip.ZipFile.(Unknown Source) at java.util.jar.JarFile.(Unknown Source) at java.util.jar.JarFile.(Unknown Source) at org.apache.catalina.webresources.JarResourceSet.initInternal(JarResourceSet.java:88) ... 17 more 10-Sep-2015 09:47:32.630 SEVERE [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Error deploying web application archive /opt/apache-tomcat/webapps/ascws.war java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ascws]] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:729) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1768) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) 10-Sep-2015 09:47:32.631 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /opt/apache-tomcat/webapps/ascws.war has finished in 142 ms == Regards, Prashant
Re: [somewhat OT] Undefined behaviour with Credential Handler
Hi. I have been following this thread loosely, and I have nothing about Tomcat authentication per se, but maybe now may be the moment to suggest another approach : why not use an Apache httpd as a front-end to Apache Tomcat, do the user authentication/authorization at the Apache httpd level (in almost whatever flavor known to man, and generally dictated by the customer circumstances more than by anything else), and pass to Tomcat requests which are already authenticated/authorized ? Apache httpd having been on the market a bit longer than Tomcat, and having a comparatively higher "market share" in terms of number of webserver installations, it has already acquired over time a very wide range of user authentication mechanisms, which Tomcat doesn't match yet, and will probably never match unless a lot of developer time is spent at just that aspect (never mind the developer time that has already been spent at it). Developer time which could probably be fruitfully spent at other more Tomcat- and Java-servlet-centric issues, rather than at duplicating what is already solved and heavily tested elsewhere. Installing and configuring Apache httpd as a front-end to Tomcat is fairly easy, fairly efficient in operation, and fairly frequent for real-world Tomcat sites, even if not always for authentication purposes per se. Adding user authentication/authorization to such a setup is almost trivial from an httpd point of view, and totally trivial from the Tomcat point of view (well, at least with AJP). And, it would stay in the big Apache free and open-source family. Re: https://en.wikipedia.org/wiki/Law_of_the_instrument and https://en.wikipedia.org/wiki/Overengineering I mean, from a human point of view, I understand the temptation for a Java developer, and for a Tomcat Java developer, to do everything in Java and in Tomcat rather than somewhere/somehow else. And I do recognise that in some use cases, one can not do otherwise. But at some point, the more bells and whistles you add to something, the heavier it becomes and the more resources are needed to develop, debug, document and maintain all that stuff. Isn't it so ? On 10.09.2015 21:49, Sreyan Chakravarty wrote: "Feel free to do that. You'll have to implement a lot of plumbing code yourself to use Apache Shiro. (It seems like Tomcat ought to support Shiro, eh? Maybe we should get together with them to build an out-of-the-box configurable component in Tomcat)." Well I don't know that but you people could try making Tomcat Container managed security easier to use. On Thu, Sep 10, 2015 at 9:16 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sreyan, On 9/10/15 8:10 AM, Sreyan Chakravarty wrote: Yes but that requires implementing your own credential handler. Sorry, I thought you had implemented your own credential handler. But the default one will still have the bug. Oh, I was just suggesting that fix as something temporary until an updated version of Tomcat is released where this bug is fixed. The fix is trivial, so I have no doubt it will be in the next release. Right now I am thinking of using an authentication framework like Apache Shiro. Feel free to do that. You'll have to implement a lot of plumbing code yourself to use Apache Shiro. (It seems like Tomcat ought to support Shiro, eh? Maybe we should get together with them to build an out-of-the-box configurable component in Tomcat). - -chris On 9/9/15 12:50 PM, Sreyan Chakravarty wrote: Well I guess now its confirmed that it is a bug. Do you still need the code ? No, I don't think I will. However, since you wrote your own CredentialHandler, you could merely patch it to check in the matches() method for null. Something like this: @Override public boolean matches(String inputCredentials, String storedCredentials) { if(null == storedCredentials) return false; return matchesSaltIterationsEncoded(inputCredentials, storedCredentials); } Then you can resume your testing. -chris On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: Sreyan, On 9/8/15 6:31 AM, Sreyan Chakravarty wrote: Okay is if I have stored my password in my DB with SHA256 encryption, can the credential handler declared in the realm work if the it is declared with SHA512 ? No. SHA256 and SHA512 produce hashes of different sizes, so with the same input, they will always produce different outputs. https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions As far as I know it must be same algorithm, salt and iterations for the hash to be matched perfectly. Correct. Now take my case-: Okay this my credential handler that I am using. In my DB the password is stored using PBEWITHHMACSHA384ANDAES_256. A completely different algorithm that the one specified before. So how come when I put in my user-id and password on my form-login page I am not getting an authentication er
How to Upgrade Java JDK 7 to JDK8 with Keystore SSL Certificate in Tomcat 7
I have Tomcat 7.0.42 on a Windows 2008R2 server. I’m pretty new to Tomcat. It uses Java JDK and is configured with a standard JSSE SSL certificate. How do I upgrade Java on an existing Tomcat server? All the documentation is for configuring new installations. I can repeat the whole installation routine and install JDK in a new directory and go through the whole thing….create keystore, request new certificate etc. but that then I would have two certificates for the same machine? Keytool has an export command, is that what this is for? If anyone has experience in this and can guide me on the best pseudo code method to upgrade Java using keystore SSL on an existing Tomcat 7 server, that would be great. The same issue goes for upgrading from Tomcat 7.0.42 to Tomcat 7.0.64. Do I do a complete de-install and re-install of the new Tomcat version and repeat all the configurations or can you upgrade Tomcat in place from the same series version to another one? Thank you. Ignacio Barragan SDSU Research Foundation Computing Services (619) 594-3290
Re: seeking help with stabilizing the persistence of a JSESSIONID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hardy, On 9/10/15 5:08 PM, Pottinger, Hardy J. wrote: > I can see in our log files that we log the session ID as part of > the authentication process so it's probable that our > authentication code needs a bit more work to accommodate the > changing session ID. I'll see if I can figure it out. If you store the session id somewhere instead of always going-back to the actual session object to grab its id, you may have a problem. I believe there is a (non-spec-standard) listener you can attach that will be notified when sessions change ids. - -chris > From: Christopher Schultz > [ch...@christopherschultz.net] Sent: Thursday, September 10, 2015 > 2:57 PM To: Tomcat Users List Subject: Re: seeking help with > stabilizing the persistence of a JSESSIONID > > Hardy, > > On 9/10/15 3:36 PM, Pottinger, Hardy J. wrote: >>> putting Serializable objects in the session is surely a good >>> idea in general. > >> I agree, especially, as you mention, if we intend to distribute >> sessions among various containers. > >>> Tomcat's session-fixation-prevention amounts to changing the >>> session identifier while keeping the session in-tact. So >>> unless you are using distributable sessions, this is unlikely >>> to be the problem. > >> You're absolutely right. I now have a serialized attribute, >> which is still lost upon the creation of the new session. Is >> there anything similar I can try, to ensure that the session >> attributes from the previous session are faithfully copied to the >> new session, after session-fixation-prevention does its thing? > > It's simpler than you think. Tomcat really does nothing other than > this after successful authentication: > > session.setSessionId(randomNewSessionId); > > The "new" session is in fact the same as the old session -- it > just has a new identifier. The client will get a Set-Cookie > response changing the JSESSIONID cookie value, and any URLs encoded > with HttpServletResponse.encodeURL or > HttpServletResponse.encodeRedirectURL will include the updated > session identifier (if appropriate). > > So the "loss" of your session attribute is puzzling. You could > write a noisy HttpSessionAttributeListener that logs every > session-attribute event (with a stack trace) to see if that > attribute is being removed elsewhere. > > -chris > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8fLsAAoJEBzwKT+lPKRYWDAP/jjiOE3HurXXYMKfy02+kONx ao4Bz7ne/zQX7lXBgBuI+lF4MS78oXWx2rp5nF3H/VPXAZ2JesgfwU+U+VbagU8m 7PjCBQaY4QyceyJg7PkSdAT130xif/9sdlmml+qDBSRogBb8cO7TLxxPQZeL808I +1FL5KnAb5JK3jIwYkYY0/IH/r2zaMYeawHofyP+uDLvGQmz3fCJfTq5T0IZYAcy P2tiId0dVxmlF70mcP71SVeHNowBKkNucNCnubM1rNPxCc84zgbvc6mYw6jf2Daq 5MlRyCLrjFaTlEHkLkIjlbLHav5CXFkom7jvBlg1jv852Wzjf3RKmzCzzPOSAsvd GCxi54wU9j0LDFwxBvyro14j56eBlaPcT//7VrZDrL8/HHv37PvivYZ0Iw8dTTls kNKPzFHg0FVYj3kq8DDof3H1YJ+LV8LalRYS/qqv/LAxzq9lSe5qObovd8MoVuPz /IePfZLkNV9cLVZo/iIuvfrpKY41gdGD1hrlY9+F6BPhPHoNpCj5n1r7UK9F38gr qXP5IdrpN7uSnMGpzvbXYSwrRswBTyQVShqsdCVJQWS++GLjLDWxdv/fxbYXc9ac oMyeEoCpinzJ+MmTMIc9dAJecGUDayJP+KMQvabPUkd4Ee33R+27P9/zoQI12Sds 4uCO7ksTV7qLWpjybm3o =n+Ja -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: seeking help with stabilizing the persistence of a JSESSIONID
I can see in our log files that we log the session ID as part of the authentication process so it's probable that our authentication code needs a bit more work to accommodate the changing session ID. I'll see if I can figure it out. From: Christopher Schultz [ch...@christopherschultz.net] Sent: Thursday, September 10, 2015 2:57 PM To: Tomcat Users List Subject: Re: seeking help with stabilizing the persistence of a JSESSIONID -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hardy, On 9/10/15 3:36 PM, Pottinger, Hardy J. wrote: >> putting Serializable objects in the session is surely a good >> idea in general. > > I agree, especially, as you mention, if we intend to distribute > sessions among various containers. > >> Tomcat's session-fixation-prevention amounts to changing the >> session identifier while keeping the session in-tact. So unless >> you are using distributable sessions, this is unlikely to be the >> problem. > > You're absolutely right. I now have a serialized attribute, which > is still lost upon the creation of the new session. Is there > anything similar I can try, to ensure that the session attributes > from the previous session are faithfully copied to the new session, > after session-fixation-prevention does its thing? It's simpler than you think. Tomcat really does nothing other than this after successful authentication: session.setSessionId(randomNewSessionId); The "new" session is in fact the same as the old session -- it just has a new identifier. The client will get a Set-Cookie response changing the JSESSIONID cookie value, and any URLs encoded with HttpServletResponse.encodeURL or HttpServletResponse.encodeRedirectURL will include the updated session identifier (if appropriate). So the "loss" of your session attribute is puzzling. You could write a noisy HttpSessionAttributeListener that logs every session-attribute event (with a stack trace) to see if that attribute is being removed elsewhere. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8eCiAAoJEBzwKT+lPKRYYoAP/3oMiZPb3Dwe8Ty74DEtvg5D FD4aWQv4hkyhKDCpFAfpVkZYy/Y6sokF2SJteX5INALZ0Uq+w7NKR8z1LdtSAklF 867e/UKYryJnCSlYj2qbitmc9uZ5ivjfWa1lnl/umYsS4lo5RfYOhEJsCahWtOuo O2DyGcIICqdLQ7W/3kw4Yk+ykypAmGSbmrbUHACVvEAm4318q/W+2oEPwEkmxw3f qyW/RGtHaLndpruU+p+4uxGh+b/N3RE/R8ZTWvjLtTfIe/XgZyqb+2C3MmV/BbBC D9IEAqRPchXbnOKBry6j9CYrtWtl9fj2HjbLaXg/ZgNQkDf39gtFB/bdIZVvbcex CqsCZ9Gm56Cv84O0fWZghXj+kVA0U7vimzeaig8//d3O7OuyzcKOyqvn7/QyQmh5 VVLVVeoVitrio4nlcbrIvAxDf3XUUztDq0YXow0v569emuHnbFikoYNjHcfKaj52 jCEwHrPVPHId0mh22+7lFAIjMjxb6a/vJUwfD0pU+JKlqklMtZmaW2lpyH72J4n5 8VbbLQvrZbi85UfkHhoYmU5/0RdWIlMSuMNXW7EMPZ+EYVaJWMhndyVN0dON3/fV PojLz02Ye1EQn4kdyiaD288NGtoCyXfc9+tcMgm3e3sBZuMbCy9NwdjVrx9ChVcO QS8LMEVu0FMhri8oNk/p =lKTi -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: seeking help with stabilizing the persistence of a JSESSIONID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hardy, On 9/10/15 3:36 PM, Pottinger, Hardy J. wrote: >> putting Serializable objects in the session is surely a good >> idea in general. > > I agree, especially, as you mention, if we intend to distribute > sessions among various containers. > >> Tomcat's session-fixation-prevention amounts to changing the >> session identifier while keeping the session in-tact. So unless >> you are using distributable sessions, this is unlikely to be the >> problem. > > You're absolutely right. I now have a serialized attribute, which > is still lost upon the creation of the new session. Is there > anything similar I can try, to ensure that the session attributes > from the previous session are faithfully copied to the new session, > after session-fixation-prevention does its thing? It's simpler than you think. Tomcat really does nothing other than this after successful authentication: session.setSessionId(randomNewSessionId); The "new" session is in fact the same as the old session -- it just has a new identifier. The client will get a Set-Cookie response changing the JSESSIONID cookie value, and any URLs encoded with HttpServletResponse.encodeURL or HttpServletResponse.encodeRedirectURL will include the updated session identifier (if appropriate). So the "loss" of your session attribute is puzzling. You could write a noisy HttpSessionAttributeListener that logs every session-attribute event (with a stack trace) to see if that attribute is being removed elsewhere. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8eCiAAoJEBzwKT+lPKRYYoAP/3oMiZPb3Dwe8Ty74DEtvg5D FD4aWQv4hkyhKDCpFAfpVkZYy/Y6sokF2SJteX5INALZ0Uq+w7NKR8z1LdtSAklF 867e/UKYryJnCSlYj2qbitmc9uZ5ivjfWa1lnl/umYsS4lo5RfYOhEJsCahWtOuo O2DyGcIICqdLQ7W/3kw4Yk+ykypAmGSbmrbUHACVvEAm4318q/W+2oEPwEkmxw3f qyW/RGtHaLndpruU+p+4uxGh+b/N3RE/R8ZTWvjLtTfIe/XgZyqb+2C3MmV/BbBC D9IEAqRPchXbnOKBry6j9CYrtWtl9fj2HjbLaXg/ZgNQkDf39gtFB/bdIZVvbcex CqsCZ9Gm56Cv84O0fWZghXj+kVA0U7vimzeaig8//d3O7OuyzcKOyqvn7/QyQmh5 VVLVVeoVitrio4nlcbrIvAxDf3XUUztDq0YXow0v569emuHnbFikoYNjHcfKaj52 jCEwHrPVPHId0mh22+7lFAIjMjxb6a/vJUwfD0pU+JKlqklMtZmaW2lpyH72J4n5 8VbbLQvrZbi85UfkHhoYmU5/0RdWIlMSuMNXW7EMPZ+EYVaJWMhndyVN0dON3/fV PojLz02Ye1EQn4kdyiaD288NGtoCyXfc9+tcMgm3e3sBZuMbCy9NwdjVrx9ChVcO QS8LMEVu0FMhri8oNk/p =lKTi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Undefined behaviour with Credential Handler
"Feel free to do that. You'll have to implement a lot of plumbing code yourself to use Apache Shiro. (It seems like Tomcat ought to support Shiro, eh? Maybe we should get together with them to build an out-of-the-box configurable component in Tomcat)." Well I don't know that but you people could try making Tomcat Container managed security easier to use. On Thu, Sep 10, 2015 at 9:16 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Sreyan, > > On 9/10/15 8:10 AM, Sreyan Chakravarty wrote: > > Yes but that requires implementing your own credential handler. > > Sorry, I thought you had implemented your own credential handler. > > > But the default one will still have the bug. > > Oh, I was just suggesting that fix as something temporary until an > updated version of Tomcat is released where this bug is fixed. The fix > is trivial, so I have no doubt it will be in the next release. > > > Right now I am thinking of using an authentication framework like > > Apache Shiro. > > Feel free to do that. You'll have to implement a lot of plumbing code > yourself to use Apache Shiro. (It seems like Tomcat ought to support > Shiro, eh? Maybe we should get together with them to build an > out-of-the-box configurable component in Tomcat). > > - -chris > > > On 9/9/15 12:50 PM, Sreyan Chakravarty wrote: > Well I guess now its confirmed that it is a bug. Do you still > need the code ? > > > > No, I don't think I will. > > > > However, since you wrote your own CredentialHandler, you could > > merely patch it to check in the matches() method for null. > > Something like this: > > > > @Override public boolean matches(String inputCredentials, String > > storedCredentials) { if(null == storedCredentials) return false; > > > > return matchesSaltIterationsEncoded(inputCredentials, > > storedCredentials); } > > > > Then you can resume your testing. > > > > -chris > > > On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Sreyan, > > On 9/8/15 6:31 AM, Sreyan Chakravarty wrote: > >>> Okay is if I have stored my password in my DB with > >>> SHA256 encryption, can the credential handler declared > >>> in the realm work if the it is declared with SHA512 ? > > No. SHA256 and SHA512 produce hashes of different sizes, so > with the same input, they will always produce different > outputs. > > https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions > > >>> > > As far as I know it must be same algorithm, salt and > >>> iterations for the hash to be matched perfectly. > > Correct. > > >>> Now take my case-: > >>> > >>> >>> "org.apache.catalina.realm.SecretKeyCredentialHandler" > >>> algorithm = "PBEWITHMD5ANDTRIPLEDES" /> > >>> > >>> Okay this my credential handler that I am using. In my > >>> DB the password is stored using > >>> PBEWITHHMACSHA384ANDAES_256. A completely different > >>> algorithm that the one specified before. So how come > >>> when I put in my user-id and password on my form-login > >>> page I am not getting an authentication error instead I > >>> am being forwarded to the protected resource. > > Perhaps PBEWITHMD5ANDTRIPLEDES and > PBEWITHHMACSHA384ANDAES_256 are somehow aliases of each > other? Also, it's possible that your implementation of the > algorithm is flawed. > > Try running the "mutate" method from a command-line driver on > some sample input to see what falls out. > > >>> It should use the algorithm in the CredentialHandler > >>> to mutate the password. Now don't tell me that two > >>> different algorithms offer the same hash. > >>> > >>> What is going on here ? > > My guess is a bug in the CredentialHandler itself. Can you > post some cod e? > > -chris > > > > -- > - --- > > > > > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: > > users-h...@tomcat.apache.org > > > > > > >> > >> - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJV8aXyAAoJEBzwKT+lPKRYav4P/jogPWNaIJLqlX8tFLMvE4th > 78dDP553/snHIZ+/g27ZyD2P3yIAcD1MURgO1B8k0GDJrbxQdLrtvW8jNt1J8UN8 > M0Wa68PrWxyy8uFecOhvHDwBd749teNl5Z/EimlzooC4FY5cFWCUgsY4qRAfd3/r > aApCpSkNKOGGcJJ1RQuUYRski72H6OezzhSZthbgr+9YYtDtpxpkeJ2UikWfzeFc > 1sl5B1wbjAl/Da8YU1tM5SNgCHLR5MAA2WDJlTyHHQrG42lhp8aE5FHVs62xT/VD > 1v4tJP1mFNc709tKpd+hnvCczjMd4BaPP2rKmaEozhuGPyfNpPcGP1xQAmBIvWR9 > 0RaEk1
RE: seeking help with stabilizing the persistence of a JSESSIONID
>putting Serializable objects in the session is surely a good idea >in general. I agree, especially, as you mention, if we intend to distribute sessions among various containers. >Tomcat's session-fixation-prevention amounts to changing the session >identifier while keeping the session in-tact. So unless you are using >distributable sessions, this is unlikely to be the problem. You're absolutely right. I now have a serialized attribute, which is still lost upon the creation of the new session. Is there anything similar I can try, to ensure that the session attributes from the previous session are faithfully copied to the new session, after session-fixation-prevention does its thing? --Hardy From: Christopher Schultz [ch...@christopherschultz.net] Sent: Thursday, September 10, 2015 2:25 PM To: Tomcat Users List Subject: Re: seeking help with stabilizing the persistence of a JSESSIONID -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hardy, On 9/10/15 1:00 PM, Pottinger, Hardy J. wrote: > The session attribute we are creating to hold the flag to indicate > the session is "interrupted"... is not serializable... which I > think means that, when the new session is created as part of > session fixation protection, the "interrupted" flag won't transfer > to the new session. Tomcat's session-fixation-prevention amounts to changing the session identifier while keeping the session in-tact. So unless you are using distributable sessions, this is unlikely to be the problem. > So... I *think* what I might need to do is set a maker for our > request class that it implements Serializable. > http://stackoverflow.com/questions/763/how-do-i-make-the-session-d ata-serializable Only > putting Serializable objects in the session is surely a good idea in general. > I'll let you know if this works out. I'm interested to hear about your experience. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8dlAAAoJEBzwKT+lPKRYXtsQAJtR7dF79KCPRNjGt2jGtGwM 3r+SAmfTkNkQtxghd2VI+G8+BHUNZUzR6aNdpZcXf8N3Gwtbvpc+LRLgu7TH0d6E A1KSSMp6V7jTW+TfLlHOa4y2T0uAzgbLwvNN6jGgRTwUNbG2eyJ/zUotQWiYWOhi T02nNNSt2gz838Z/WSWpx/8IFS3T1i6ny4QRdFwsItFyiNJ4fV8AULVzjDp1fIdd cuBLCFEqoMcNoWymc5IFEULtLc87Mzec52+J6robJFh1Z+2TkDSbtFWSBD2CqoPI wIR405EUX/gaBkivnvk81J4TeOqRcEN1nc+YWPYpFbW65u0WXnG85zf58HSIaV59 Z+5FIh6/yecTJh/hRugPg/PgSIjFxo6Q2l9t2QaWqsqwNS7KyZfRqpeZWOUBJYH4 13cPBcv08LOrUUmh1tIlOpw6+3e0CqSokTtppf0Aqt8FK7ng2t7TjVrgt6GYEZGu wMMVMboERXPFeKD618lxcn4mp89BH3iKlR3d0LDA+ZIn/68ZatDZFAUl+vhO49xn tKKbQY6dAYx3VU8NqiXuWVup8RYRxRJlymuseUaf95GOo7JW+hvw6PbPNRYWTpMk E6xmCdyD0hMMZXx5cnqRHBuVaXEkhbNK5o2j5WB1/sitDli/G8NUN/yN+KLrNbMC 9VRK0C/SkcNLXAosN6NP =Wr84 -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: seeking help with stabilizing the persistence of a JSESSIONID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hardy, On 9/10/15 1:00 PM, Pottinger, Hardy J. wrote: > The session attribute we are creating to hold the flag to indicate > the session is "interrupted"... is not serializable... which I > think means that, when the new session is created as part of > session fixation protection, the "interrupted" flag won't transfer > to the new session. Tomcat's session-fixation-prevention amounts to changing the session identifier while keeping the session in-tact. So unless you are using distributable sessions, this is unlikely to be the problem. > So... I *think* what I might need to do is set a maker for our > request class that it implements Serializable. > http://stackoverflow.com/questions/763/how-do-i-make-the-session-d ata-serializable Only > putting Serializable objects in the session is surely a good idea in general. > I'll let you know if this works out. I'm interested to hear about your experience. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8dlAAAoJEBzwKT+lPKRYXtsQAJtR7dF79KCPRNjGt2jGtGwM 3r+SAmfTkNkQtxghd2VI+G8+BHUNZUzR6aNdpZcXf8N3Gwtbvpc+LRLgu7TH0d6E A1KSSMp6V7jTW+TfLlHOa4y2T0uAzgbLwvNN6jGgRTwUNbG2eyJ/zUotQWiYWOhi T02nNNSt2gz838Z/WSWpx/8IFS3T1i6ny4QRdFwsItFyiNJ4fV8AULVzjDp1fIdd cuBLCFEqoMcNoWymc5IFEULtLc87Mzec52+J6robJFh1Z+2TkDSbtFWSBD2CqoPI wIR405EUX/gaBkivnvk81J4TeOqRcEN1nc+YWPYpFbW65u0WXnG85zf58HSIaV59 Z+5FIh6/yecTJh/hRugPg/PgSIjFxo6Q2l9t2QaWqsqwNS7KyZfRqpeZWOUBJYH4 13cPBcv08LOrUUmh1tIlOpw6+3e0CqSokTtppf0Aqt8FK7ng2t7TjVrgt6GYEZGu wMMVMboERXPFeKD618lxcn4mp89BH3iKlR3d0LDA+ZIn/68ZatDZFAUl+vhO49xn tKKbQY6dAYx3VU8NqiXuWVup8RYRxRJlymuseUaf95GOo7JW+hvw6PbPNRYWTpMk E6xmCdyD0hMMZXx5cnqRHBuVaXEkhbNK5o2j5WB1/sitDli/G8NUN/yN+KLrNbMC 9VRK0C/SkcNLXAosN6NP =Wr84 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple JSESSIONID cookies being presented.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 9/10/15 12:26 PM, Jeffrey Janner wrote: > Thanks for all the help guys. I think I've sussed out what is > going on here. Now just have to get the Dev guys to address it. > > After spending a good bit of time clearing and watching cookies > and access logs, both with and without a favicon.ico file, I found > that the doubling was happening only if the file was missing. I > checked the error.jsp file and it does have session=true set, and > if the icon file is missing, the error.jsp is definitely being > sent. > > So it looks like the possible solutions are: 1) provide a > favicon.ico file. This fixes the symptom, not the problem. You'll get the same problem with clients who request /apple-touch-icon.png, /robots.txt, or just about any other file that ends up resulting in a 404. This could be something from within the application itself, and will (apparently) cause mass confusion. > 2) remove the session=true setting from the error page. This is the right answer. Do you really need the session in error.jsp? > 3) somehow not send the error.jsp when a sub-link (image, script, > etc.) results in a 404. > > 4) Have the login page of APP2 provide it's own icon > directive (it doesn't currently have one.) > Any other options? If you absolutely need access to the session in your error.jsp file, you can do this: <% HttpSession session = request.getSession(false); ... %> This will prevent sessions from being created when there isn't already a session. You'll have to check the code for error.jsp to make sure that no code uses the session before checking it for null -- because session="true" guarantees that the "session" reference will be non-null. That will allow you to use session information in error.jsp if a session already exists, but not create a superfluous session when one does not (yet) exist. Back to Tomcat's session management: Tomcat *can* handle this situation properly: it will try all JSESSIONID cookies it gets to find a valid one in the current web application. So, multiple JSESSIONID cookies won't confuse Tomcat. Some other component must be mis-understanding the session identifier in some way. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8di9AAoJEBzwKT+lPKRY9FUP/0m2SNIG3nW9dsIRCr1q/SWG 5O/s5VrDs7Rvk1hWfbGTlhfuL0zkeCaL/GQE4wa3KQo4qHPhtzYlIgZstEeaAQqk kLwU4JHzJcTfKMKog6/O0kFwysYzl4y/EX+UoBcY3h3N5xkQ0RGNOYEF7fSr+6NA Uuxo6WVxQoP3Ce/64EZ1P+uxglLJF+pML6OViEHEK4qgL3SY1UY0tOFpcBa43Gqt Y/Z7I1SvQhRt2VGQzyatHRypAMxynJfHjvV/gyF3k1/XFEeWDDpET4guaazD1uqW fE5Lgt3Lxr1WyeEXxeJz4jOlLBty0bm9m16YFdxCsNjVy7v7Uy7M1Hd0iIfoktCV Vp8nzuj+qxVMpzua2N/J7e9slYnIZOePOFFrTQbWx1S10QCvgRuprN3lyZEU29oP PywXQU/F9u/xFPk6Z5+xdMrSEvL+ykuwoyV8Ef2CObZ0Ibsjx9WoBAz/hRLpeeji TngPwFvDrU7jMR36SQ+vCR8PQSjQo5P2P+KZE735uIgG/iz3F6gQ+8R9E0p1iutL iLoF2alPkSaoWnBTrlDhV+EvKtjKl2FWuRrs5sHGWG6FowS+lKnaAfhkq3ArGLdS j4JFculpE80Ys9saoetvTlQ35dTi1KdmL+gzixI/EjUVkS2azsW6kYxkwliig4gN UVa6wuFsD/I9JcMCKeIp =1OQG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: seeking help with stabilizing the persistence of a JSESSIONID
Hi, in helping a colleague diagnose another problem for another servlet, I was using PsiProbe, and I noticed that it has session diagnostics. Doh! I promptly fired up PsiProbe on my Tomcat server, returning to this JSESSIONID issue, and watched the session get created as part of a password challenge page, and one thing jumped out at me: The session attribute we are creating to hold the flag to indicate the session is "interrupted"... is not serializable... which I think means that, when the new session is created as part of session fixation protection, the "interrupted" flag won't transfer to the new session. So... I *think* what I might need to do is set a maker for our request class that it implements Serializable. http://stackoverflow.com/questions/763/how-do-i-make-the-session-data-serializable I'll let you know if this works out. --Hardy From: Christopher Schultz [ch...@christopherschultz.net] Sent: Thursday, September 10, 2015 10:39 AM To: Tomcat Users List Subject: Re: seeking help with stabilizing the persistence of a JSESSIONID -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/9/15 9:43 PM, Pottinger, Hardy J. wrote: > It doesn't matter which Authenticator is installed, they all behave > the same way. The user name from httpd is used to populate the > remote user name and the user principal and the user principal > being set is what bypasses most of the authentication code. > > All of the authenticators will cache the Principal in the session > if one exists but none of them (apart from FORM) should ever create > one. > > The authenticator you will get will depend on whatever is in > web.xml. So, it looks like there is no auth-type specified in web.xml, so what does the app get? It looks like *something* is in there, given the stack trace provided. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8aQbAAoJEBzwKT+lPKRY5oIQAIoGHHBsxESORGC/Nsaa5O5O 8I2SL6iHcmjw8d8SE8pVGuY6B4W0w49LMy2px3bar5Z8NMwrWGDwj9s01H0+lN6b f7ZtmZsfLTFGmlpOqkpcHqhSsedO8NqEIO3/e84nwKKtbOQFdragJ48qkJ/oYk4w /PMjAosH2kE/egwXHg2dGzy5WCox91CI2f/4JZjXlsrZikEErMdqS9zoYAUt7tlD JFUrcSey9T0V0JfoqSv0CTV2kRtI/B2LcOuh5eQqyUks2mQvb08BKPoGp1PM4DjK 1sX7IpTUurc8eGsDSBSd/wciUU47bhPmK1YmyN3EwqxIGsN82C2EVe+t/N3gFhoe PiUtofF3nwOCfSHPUiiNnTpHYIetgNUpCkdbmnwgV1dEvWTyWCCMWvIoPAztozkO zIz2Qr6K5Lyy2no5+zPpOdipeMlZ5rXvEXBDFGpmtmlAKwphcz1/SxNV+YDgqmnT KHcorZ/oltH/qyAPWZeu8/Hu6tQgb9Ua8kAayE0sK38grXI7kJHNlQyPldxYZjKB TG2IGQd46XyJKSt6nA53hmbMPFhIwPl2MvgLzQ5j7lrlO64TCaCRtQwi9pCjRGHL d/BWRVPXEABRdIKoxG/beFRaob/h4TkIvcOChqUe+lHJ+/3NGjQLmhVSFYseCFbK eyK7kji4cGdJF5iH3Ayn =J6nA -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: Multiple JSESSIONID cookies being presented.
> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > Subject: RE: Multiple JSESSIONID cookies being presented. > I checked the error.jsp file and it does have session=true set, and if the > icon file > is missing, the error.jsp is definitely being sent. > So it looks like the possible solutions are: > 1) provide a favicon.ico file. > 2) remove the session=true setting from the error page. > 3) somehow not send the error.jsp when a sub-link (image, script, etc.) > results in a 404. > 4) Have the login page of APP2 provide it's own icon directive (it > doesn't currently > have one.) Why would you ever want your error.jsp to create a session? Sounds like an easy DoS attack to me. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cluster isn't deploying apps to all members
On 10-09-15 17:43, Christopher Schultz wrote: > Martijn, > > On 9/10/15 7:39 AM, Martijn Bos wrote: >> I think I "solved" it myself. > >> My problem was that when I deployed a webaap on one of the >> cluster-members it didn't get deployed on the other member. I did >> this with the manager web-application. > >> However when I drop a war-file in the watchDir of the >> farmWarDeployer it gets deployed to the other member. (Apperantly >> by memory or so. Since I do not see the war file appearing on in >> the tmpDir, deployDir or watchDir on the other cluster member) > >> Can somone confirm that deploying through the manager-webapp will >> not deploy to all the cluster members? Otherwise there is still >> something wrong with my setup. > > Yes, the manager web application has no knowledge of the existence of > the cluster. You need to use FarmWebDeployer if you want to push the > WAR file to multiple cluster members. > Ah great. Then I'm not going insane afterall:-) >> btw. I see that the farmWarDeployer is not completely stable. A >> few times I noticed that the app is not deployed on the other >> member, trying one more time, and it does succeed. > > I believe the FWD doesn't get a huge amount of use in the wild. If > you're willing to instrument the FWD and make suggestions for > improvement, I'm sure we can get any bugs worked-out. > That is actually very tempting. However my JAVA skills are moderate at best, so I'm not to sure whether I should proceed in that direction. On the other hand it doesn't hurt to have a look at the code, and see what I can do. Best Regards, Martijn > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > signature.asc Description: OpenPGP digital signature
RE: Multiple JSESSIONID cookies being presented.
> -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, September 09, 2015 1:50 PM > To: Tomcat Users List > Subject: Re: Multiple JSESSIONID cookies being presented. > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Jeffrey, > > On 9/9/15 12:08 PM, Jeffrey Janner wrote: > >> -Original Message- From: Caldarale, Charles R > >> [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, September 08, > >> 2015 4:58 PM To: Tomcat Users List > >> Subject: RE: Multiple JSESSIONID cookies being presented. > >> > >>> From: Jose María Zaragoza [mailto:demablo...@gmail.com] > >>> Subject: Re: Multiple JSESSIONID cookies being presented. > >> > Thanks for the clarification of what's supposed to happen on > >> receipt, Jose. > However, I am describing what happens on first contact from > the > >> client to the server. > The browser sends https://hostname/APP2, and Tomcat returns: > JSESSIONID=, path=/and JSESSIONID=, > path=/APP2/ > >> > >>> Indeed, it doesn't make sense for me to return different id ( > >>> , ) if you are accesing to only one context (/APP2) > >> > >>> Are you sure that your webapp deployed in /APP2 is not accesing > >>> to resources ( session-aware resources as JSP, servlet, .. .I > >>> mean) stored in ROOT context ? > >> > >> As I think someone previously mentioned, the client (browser) may > >> well be sending an unsolicited request to the default webapp, > >> such as when trying to retrieve favicon.ico. You might want to > >> run Fiddler or Wireshark on the client to see exactly what's > >> being sent to the server. > >> > > > > And there's no way to keep a browser from asking for the > > favicon.ico file from the root. We don't have one, so I would > > expect a 404 is sent, which looking at the access log file is what > > happens. However, is this the issue? I tested this doing a manual > > https://hostname/favicon.ico and see that we also return our root > > app's error page. We also seem to be doing that for the > > auto-generated request, judging by the bytes returned value, even > > though it won't get displayed. And I bet that the error page is > > setting the session cookie for some reason. Does that sound > > reasonable? Is my solution just providing a favicon.ico file? > > Can you make sure that all cookies have been cleared from the test > client and then explain exactly when Tomcat sends the Set-Cookie headers > ? > > When we had this problem, it was usually because the client had old > funky session ids in its cookie jar and the solution was to blow them > all away and start-over fresh. (Then fix our software so it wouldn't > happen anymore.) > > - -chris Thanks for all the help guys. I think I've sussed out what is going on here. Now just have to get the Dev guys to address it. After spending a good bit of time clearing and watching cookies and access logs, both with and without a favicon.ico file, I found that the doubling was happening only if the file was missing. I checked the error.jsp file and it does have session=true set, and if the icon file is missing, the error.jsp is definitely being sent. So it looks like the possible solutions are: 1) provide a favicon.ico file. 2) remove the session=true setting from the error page. 3) somehow not send the error.jsp when a sub-link (image, script, etc.) results in a 404. 4) Have the login page of APP2 provide it's own icon directive (it doesn't currently have one.) Any other options? Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Undefined behaviour with Credential Handler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sreyan, On 9/10/15 8:10 AM, Sreyan Chakravarty wrote: > Yes but that requires implementing your own credential handler. Sorry, I thought you had implemented your own credential handler. > But the default one will still have the bug. Oh, I was just suggesting that fix as something temporary until an updated version of Tomcat is released where this bug is fixed. The fix is trivial, so I have no doubt it will be in the next release. > Right now I am thinking of using an authentication framework like > Apache Shiro. Feel free to do that. You'll have to implement a lot of plumbing code yourself to use Apache Shiro. (It seems like Tomcat ought to support Shiro, eh? Maybe we should get together with them to build an out-of-the-box configurable component in Tomcat). - -chris > On 9/9/15 12:50 PM, Sreyan Chakravarty wrote: Well I guess now its confirmed that it is a bug. Do you still need the code ? > > No, I don't think I will. > > However, since you wrote your own CredentialHandler, you could > merely patch it to check in the matches() method for null. > Something like this: > > @Override public boolean matches(String inputCredentials, String > storedCredentials) { if(null == storedCredentials) return false; > > return matchesSaltIterationsEncoded(inputCredentials, > storedCredentials); } > > Then you can resume your testing. > > -chris > On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: Sreyan, On 9/8/15 6:31 AM, Sreyan Chakravarty wrote: >>> Okay is if I have stored my password in my DB with >>> SHA256 encryption, can the credential handler declared >>> in the realm work if the it is declared with SHA512 ? No. SHA256 and SHA512 produce hashes of different sizes, so with the same input, they will always produce different outputs. https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions >>> As far as I know it must be same algorithm, salt and >>> iterations for the hash to be matched perfectly. Correct. >>> Now take my case-: >>> >>> >> "org.apache.catalina.realm.SecretKeyCredentialHandler" >>> algorithm = "PBEWITHMD5ANDTRIPLEDES" /> >>> >>> Okay this my credential handler that I am using. In my >>> DB the password is stored using >>> PBEWITHHMACSHA384ANDAES_256. A completely different >>> algorithm that the one specified before. So how come >>> when I put in my user-id and password on my form-login >>> page I am not getting an authentication error instead I >>> am being forwarded to the protected resource. Perhaps PBEWITHMD5ANDTRIPLEDES and PBEWITHHMACSHA384ANDAES_256 are somehow aliases of each other? Also, it's possible that your implementation of the algorithm is flawed. Try running the "mutate" method from a command-line driver on some sample input to see what falls out. >>> It should use the algorithm in the CredentialHandler >>> to mutate the password. Now don't tell me that two >>> different algorithms offer the same hash. >>> >>> What is going on here ? My guess is a bug in the CredentialHandler itself. Can you post some cod e? -chris > > -- - --- > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org > > >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8aXyAAoJEBzwKT+lPKRYav4P/jogPWNaIJLqlX8tFLMvE4th 78dDP553/snHIZ+/g27ZyD2P3yIAcD1MURgO1B8k0GDJrbxQdLrtvW8jNt1J8UN8 M0Wa68PrWxyy8uFecOhvHDwBd749teNl5Z/EimlzooC4FY5cFWCUgsY4qRAfd3/r aApCpSkNKOGGcJJ1RQuUYRski72H6OezzhSZthbgr+9YYtDtpxpkeJ2UikWfzeFc 1sl5B1wbjAl/Da8YU1tM5SNgCHLR5MAA2WDJlTyHHQrG42lhp8aE5FHVs62xT/VD 1v4tJP1mFNc709tKpd+hnvCczjMd4BaPP2rKmaEozhuGPyfNpPcGP1xQAmBIvWR9 0RaEk1UhpwQdaS1kxOqBHLYLmplhmt9BS4AFy7WUcWZfiEGqi9IvG3Oblt2OinRb 68b4fQbgiW4NBBccw1yFYQ8XAQCxtB340b8j7y8OiMWihgWtxtmpNrazW0AoHgV/ QcYlhQ8fldwa5ysbefvZC82eQJ0s0ivvsX7iclNCJHOUW48oud9nscHu9r+3pBm3 s3bbpnXGrFFNwZpSGmvlQ7im0Ozv+huuqe7vg3pGryWxte5+I54m8y7xkQs0mTZF tGjYDk20qn30j/Oke5AO99fVzpgJl9jlBVY+CrPTKKm3GzEj8cBl92jnN8flzjZP fwwURalFrQjt3tbqNUvW =JROa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cluster isn't deploying apps to all members
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martijn, On 9/10/15 7:39 AM, Martijn Bos wrote: > I think I "solved" it myself. > > My problem was that when I deployed a webaap on one of the > cluster-members it didn't get deployed on the other member. I did > this with the manager web-application. > > However when I drop a war-file in the watchDir of the > farmWarDeployer it gets deployed to the other member. (Apperantly > by memory or so. Since I do not see the war file appearing on in > the tmpDir, deployDir or watchDir on the other cluster member) > > Can somone confirm that deploying through the manager-webapp will > not deploy to all the cluster members? Otherwise there is still > something wrong with my setup. Yes, the manager web application has no knowledge of the existence of the cluster. You need to use FarmWebDeployer if you want to push the WAR file to multiple cluster members. > btw. I see that the farmWarDeployer is not completely stable. A > few times I noticed that the app is not deployed on the other > member, trying one more time, and it does succeed. I believe the FWD doesn't get a huge amount of use in the wild. If you're willing to instrument the FWD and make suggestions for improvement, I'm sure we can get any bugs worked-out. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8aUJAAoJEBzwKT+lPKRYUCgQAJmAdw8MzM0xm2JUq6u88Jba Nj4esd6KqFPkAHl5jAlQfUoGKVq3a4oYCdqocNtzPHpiTysgRUT0/wWDwnK7TJVN t2XgQnfKbMGzx7dUJBGk+fGJw72G10kynz4PNZ7KgHnz8oRMr82HRAkurZVfxQq/ h7wcfxZRIn0Juu39NBx8LHWTvDeym6l128VtoN0+C0OGEGcWKNmOtN1BZKXj/H4D 9mkF6XGbHWWZ2ZFVt1r+IPntWAE4dvE1R0m3RbVrW3qbjXqnEjqZn+21XuoCK/OP Lc7WMXfacGO7Ay8Qg6Dvfal9ngTuZ3bUcTlADatzbxl8sFpD7eLgz42skCYFWG6Y lWNB4XwzYArn4Lyjf/A3Ib5OFcL4bayPdPnLfJMcQXoxO+m5dmTfs6WDHdoGYyyc QarOcPiy9YecxKTyjqqPRjSEdg4Bj6UXrFUU4NNdulzFnA9y4EDM3eILFHdIbe55 QbgvTSa4BsF5L9kc1PWaXlj/VTQ+mYcj1bcTmcwV0APjVAPZbnUVSPNI5ewNAyBE 8idaO+/+pPtJVRYasOosIYU731uYrysFmGuEvFeRiBAS3APNBKv1knTrrdZqsvRM Ep/tzI7woPc6a9W3lO1nnGo0xe/XmxnJJUcO2crgARfPbJPLk2g3VCQotitVVGY8 tob8vwVzYwaisaTuIXxh =czB+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DNS is hijacked and some filty AD is added at the bottom of our webpage
On 9/9/2015 8:46 AM, shi wrote: Hi gurus, We have a website running at a tomcat. Its web pages looks good. Recently, we, however, find some of web pages contain the filthy AD at the bottom of the page. Here are the ways this could be happening: 1. Your server is compromised and it's your server that's inserting the ads. 2. Your client is compromised by a virus and it's inserting the ad. 3. Your internet service provider is evil and inserting ads. 4. You are suffering from hijacked DNS on your network. I've seen this where the router at the site had been hacked and was passing out DNS entries for a server in Russia. 5. Someone's actually compromised your DNS records at the registrar. The 1st step to figuring out what's going wrong is to get a known clean client on a known clean network and see what the page looks like. If it's good, then you eliminate 1,2,3, and 4. to test number 5 use any of the DNS lookup tools on the internet and check your domain. To check number 4, look at the IP addresses of the DNS servers being handed out by your DHCP server. We really could not understand why there are these filthy AD at the web page. We make sure the web page doesn't contain any ADs at tomcat. But when we access these webpage via internet, we find these filthy AD added.. We search related knowledge and find it looks like some DNS is hijacked. It causes when the client is accessing the website, the hijacked DNS will be used to translate the webname to its IP. During this process, the hijacked DNS adds the filthy AD at the web page. So my current question is: how to avoid/resolve this issue at java server side? Are there many good solutions to resolve it? Thanks, Shi -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: seeking help with stabilizing the persistence of a JSESSIONID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/9/15 9:43 PM, Pottinger, Hardy J. wrote: > It doesn't matter which Authenticator is installed, they all behave > the same way. The user name from httpd is used to populate the > remote user name and the user principal and the user principal > being set is what bypasses most of the authentication code. > > All of the authenticators will cache the Principal in the session > if one exists but none of them (apart from FORM) should ever create > one. > > The authenticator you will get will depend on whatever is in > web.xml. So, it looks like there is no auth-type specified in web.xml, so what does the app get? It looks like *something* is in there, given the stack trace provided. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8aQbAAoJEBzwKT+lPKRY5oIQAIoGHHBsxESORGC/Nsaa5O5O 8I2SL6iHcmjw8d8SE8pVGuY6B4W0w49LMy2px3bar5Z8NMwrWGDwj9s01H0+lN6b f7ZtmZsfLTFGmlpOqkpcHqhSsedO8NqEIO3/e84nwKKtbOQFdragJ48qkJ/oYk4w /PMjAosH2kE/egwXHg2dGzy5WCox91CI2f/4JZjXlsrZikEErMdqS9zoYAUt7tlD JFUrcSey9T0V0JfoqSv0CTV2kRtI/B2LcOuh5eQqyUks2mQvb08BKPoGp1PM4DjK 1sX7IpTUurc8eGsDSBSd/wciUU47bhPmK1YmyN3EwqxIGsN82C2EVe+t/N3gFhoe PiUtofF3nwOCfSHPUiiNnTpHYIetgNUpCkdbmnwgV1dEvWTyWCCMWvIoPAztozkO zIz2Qr6K5Lyy2no5+zPpOdipeMlZ5rXvEXBDFGpmtmlAKwphcz1/SxNV+YDgqmnT KHcorZ/oltH/qyAPWZeu8/Hu6tQgb9Ua8kAayE0sK38grXI7kJHNlQyPldxYZjKB TG2IGQd46XyJKSt6nA53hmbMPFhIwPl2MvgLzQ5j7lrlO64TCaCRtQwi9pCjRGHL d/BWRVPXEABRdIKoxG/beFRaob/h4TkIvcOChqUe+lHJ+/3NGjQLmhVSFYseCFbK eyK7kji4cGdJF5iH3Ayn =J6nA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Firefox SSL with APR - losing client certificate
Reported as Bug 58244 - two way SSL loses client certificate after a few requests https://bz.apache.org/bugzilla/show_bug.cgi?id=58244 David Balažic > -Original Message- > From: David Balažic > Sent: 7. August 2015 17:38 > To: users@tomcat.apache.org > Subject: Firefox SSL with APR - losing client certificate > Importance: Low > > Hi! > > I use tomcat 6.0.44 wit APR on Windows x64. > I set up SSLVerifyClient="optional" and since then encounter the following > problem with Firefox 39.0.03 (IE works OK): > > On first access Firefox shows the client certificate selection dialog. I > select a > certificate and continue. The web application "sees" the selected certificate > and show a proper response page. > But on next access (I click a link) the client certificate is not visible to > the > application any more. It gets null from the method call > HttpServletRequest.getAttribute("javax.servlet.request.X509Certificate") > > Goggole found https://bz.apache.org/bugzilla/show_bug.cgi?id=37869 > (similar) > And http://grokbase.com/t/tomcat/users/102pdv412y " [Tomcat-users] > Client certificate gone after 1 minute timeout (SSL, APR)" > (even more similar, except for me it fails on next access without a minute of > waiting) > As suggested in the second link, clearing cache and authentication in the > browser is a workaround that works. Kind of as one has to select the > certificate again and do it before every click on a link. > > Strange, just now it worked fine for a few minutes. > > Is this some known issue? > > Without APR, using JSSE, it works fine (and did so for years). > > This started after upgrading yesterday tomcat from 6.0.35_x64 (no APR) to > apache-tomcat-6.0.44-windows-x64.zip (with or without APR). > I start tomcat from Eclipse, using JRE 1.6.0_45 (each 64 bit version). > > Firefox version 39.0, today updated to 39.0.3 > > The Connector line from server.xml: > >SSLCertificateFile="C:/key_public.pem" > SSLCertificateKeyFile="C:/key_private.pem" > SSLEnabled="true" SSLPassword="changeit" > SSLProtocol="TLSv1+TLSv1.1+TLSv1.2" > SSLVerifyClient="optional" URIEncoding="UTF-8" maxThreads="150" > port="8443" > protocol="org.apache.coyote.http11.Http11AprProtocol" > scheme="https" > secure="true" /> > > > Regards, > David Balažic > > - > 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: Undefined behaviour with Credential Handler
Yes but that requires implementing your own credential handler. But the default one will still have the bug. Right now I am thinking of using an authentication framework like Apache Shiro. On Thu, Sep 10, 2015 at 1:48 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Sryan, > > On 9/9/15 12:50 PM, Sreyan Chakravarty wrote: > > Well I guess now its confirmed that it is a bug. Do you still need > > the code ? > > No, I don't think I will. > > However, since you wrote your own CredentialHandler, you could merely > patch it to check in the matches() method for null. Something like this: > > @Override > public boolean matches(String inputCredentials, >String storedCredentials) { > if(null == storedCredentials) > return false; > > return matchesSaltIterationsEncoded(inputCredentials, > storedCredentials); > } > > Then you can resume your testing. > > - -chris > > > On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Sreyan, > > > > On 9/8/15 6:31 AM, Sreyan Chakravarty wrote: > Okay is if I have stored my password in my DB with SHA256 > encryption, can the credential handler declared in the realm > work if the it is declared with SHA512 ? > > > > No. SHA256 and SHA512 produce hashes of different sizes, so with > > the same input, they will always produce different outputs. > > > > https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions > > > As far as I know it must be same algorithm, salt and > iterations for the hash to be matched perfectly. > > > > Correct. > > > Now take my case-: > > "org.apache.catalina.realm.SecretKeyCredentialHandler" > algorithm = "PBEWITHMD5ANDTRIPLEDES" /> > > Okay this my credential handler that I am using. In my DB > the password is stored using PBEWITHHMACSHA384ANDAES_256. A > completely different algorithm that the one specified before. > So how come when I put in my user-id and password on my > form-login page I am not getting an authentication error > instead I am being forwarded to the protected resource. > > > > Perhaps PBEWITHMD5ANDTRIPLEDES and PBEWITHHMACSHA384ANDAES_256 are > > somehow aliases of each other? Also, it's possible that your > > implementation of the algorithm is flawed. > > > > Try running the "mutate" method from a command-line driver on some > > sample input to see what falls out. > > > It should use the algorithm in the CredentialHandler to > mutate the password. Now don't tell me that two different > algorithms offer the same hash. > > What is going on here ? > > > > My guess is a bug in the CredentialHandler itself. Can you post > > some cod e? > > > > -chris > >> > >> - > >> > >> > 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 > > iQIcBAEBCAAGBQJV8JQpAAoJEBzwKT+lPKRYBlQP/2dedJFcZSsAGF+0uxRGIPfr > vW26AOOaT/qPS88eQiCucufYOpPx180ifdIdnNVtLRZbIYyeQMBQiFTezMZM1Psx > 2Ufuw1ZEPV0kZteptnDgGyipZKtDaxl/7hYY76O3yy8ki62Fa6TcRtR8UBPY0pJs > kVYw9ZWqVVq8smkDomYAA/wwtGUzXORB3RN5yKGtKPx7roV00cLAoKQTv4ZlxfM5 > LMuuorMx9jnWI9JXTlQdxi9ydQ1IlALrv9igbXE1/cYCnLrHtJVrE+bzvL4XPy+1 > C9H8UdWT8Mqdn4qSIi5Zp0JDkRffvjVj4WA7V3Yt2+7HqlcZjEFDdAtN//DJ9T4A > Zc/NJ73vXyEnFKt1S3mgqTIaGi7tr13VX8mXyFVSXzP/wvoQpCaOr0RYyIVvTdOc > r42X1j5gq3tKTV1Hxe73SoM9iJivFvq6VFq+zvzv3fdNyHt1TukwM3E7nxnd6cXr > euWj5IUc1+Z002xQBPKWjxAJFxsmd1cvM9A4zuhr70P2WcTsYSCbTn0ETB7Vtssb > Rr1ED6jf2MKE/JIU8G6YKU5yuLqAnSaJleHOyWz/N8X5fUN5q4sfeV174UluS1WU > +J017q60ZBrkEdzPB7bO/Jku1ThPHcFMbg5VfQQ+TTyN6AugQYfvasrvfBhu2wdL > 3CMQ6Hf+ShnIB8aWI8zj > =Sxyr > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
cluster isn't deploying apps to all members
Hi all, I think I "solved" it myself. My problem was that when I deployed a webaap on one of the cluster-members it didn't get deployed on the other member. I did this with the manager web-application. However when I drop a war-file in the watchDir of the farmWarDeployer it gets deployed to the other member. (Apperantly by memory or so. Since I do not see the war file appearing on in the tmpDir, deployDir or watchDir on the other cluster member) Can somone confirm that deploying through the manager-webapp will not deploy to all the cluster members? Otherwise there is still something wrong with my setup. btw. I see that the farmWarDeployer is not completely stable. A few times I noticed that the app is not deployed on the other member, trying one more time, and it does succeed. Anyway...thanks for listening, Best regards, Martijn On 08-09-15 13:28, Martijn Bos wrote: > Hi all, > > I tried to create a cluster two hosts. At which I did not succeeded > completely. > > OS(both systems): > SMP Debian 3.16.7 > > java (both systems): > martijn@bloemkool:~/apache-tomcat-8.0.26/conf$ java -version > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > Tomcat (both systems): > Apache Tomcat/8.0.26 > > I installed 2 tomcat's > One on host bloemkool.bos. > The server.xml: > - > > > > >SSLEngine="on" /> >className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> >className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> >className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> > > >type="org.apache.catalina.UserDatabase" > description="User database that can be updated and saved" > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > pathname="conf/tomcat-users.xml" /> > > > > redirectPort="8443" /> > jvmRoute="bloemkoolRoute"> > > resourceName="UserDatabase"/> > >autoDeploy="true"> >channelSendOptions="8"> > expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> >className="org.apache.catalina.tribes.group.GroupChannel"> > className="org.apache.catalina.tribes.membership.McastService" > address="228.0.0.4" > port="45564" > frequency="500" > dropTime="3000"/> > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > address="192.168.2.123" > port="4000" > autoBind="100" > selectorTimeout="5000" > maxThreads="6"/> > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> >className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> > > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> > className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/> > > >filter=""/> >className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> >className="org.apache.catalina.ha.deploy.FarmWarDeployer" > tempDir="/tmp/war-temp/" > deployDir="${catalina.base}/webapps" > watchDir="/tmp/war-listen/" > watchEnabled="true"/> >className="org.apache.catalina.ha.session.ClusterSessionListener"/> > > directory="logs" >prefix="localhost_access_log" suffix=".txt" >pattern="%h %l %u %t "%r" %s %b" /> > > > > > - > > And one on broccoli.bos. > The server.xml: > - > > > >SSLEngine="on" /> >className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> >className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> >className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> > > >type="org.apache.catalina.UserDatabase" > description="User database that can be updated and saved" > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > pathname="conf/tomcat-users.xml" /> > > > redirectPort="8443" /> > jvmRoute="broccoliRoute"> > > resourceName="UserDatabase"/> > >autoDeploy="true"> > channelSendOptions="8"> >className="org.apache.catalina.ha.session.DeltaManager" > expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> > className="org.apache.catalina.tribes.group