Re: Context.xml being deleted
Which version of Tomcat are you using? p On 12 April 2010 01:35, Sam Stephens samspad...@gmail.com wrote: Hi all. The tomcat documentation says the following: If the web application is packaged as a WAR then /META-INF/context.xml will be copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to match the application's context path. Once this file exists, it will not be replaced if a new WAR with a newer /META-INF/context.xml is placed in the host's appBase. However, each time I upload a new WAR the existing context.xml gets deleted and replaced with the one inside the WAR file (which is just a default). So I lose all my configuration details. I have googled and it seems this is a common problem. Any help ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- -- pidster.com
Re: Context.xml being deleted
If you're uploading directly to the webapps directory, try uploading the file renamed to yourapp.warTMP and renaming it in place when the upload is complete. Please let us know if this works/does not work. p On 12 April 2010 09:18, Pid * p...@pidster.com wrote: Which version of Tomcat are you using? p On 12 April 2010 01:35, Sam Stephens samspad...@gmail.com wrote: Hi all. The tomcat documentation says the following: If the web application is packaged as a WAR then /META-INF/context.xml will be copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to match the application's context path. Once this file exists, it will not be replaced if a new WAR with a newer /META-INF/context.xml is placed in the host's appBase. However, each time I upload a new WAR the existing context.xml gets deleted and replaced with the one inside the WAR file (which is just a default). So I lose all my configuration details. I have googled and it seems this is a common problem. Any help ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- -- pidster.com -- -- pidster.com
Re: Context.xml being deleted
I've tried that, it doesn't work. Updating a WAR file will trigger an undeploy and consequent removal of the context descriptor in a running Tomcat if the Host autoDeploy attribute is true. If autoDeploy is false, redeploy without updating the context.xml can occur using the manager. p On 12 April 2010 10:34, Pid * p...@pidster.com wrote: If you're uploading directly to the webapps directory, try uploading the file renamed to yourapp.warTMP and renaming it in place when the upload is complete. Please let us know if this works/does not work. p On 12 April 2010 09:18, Pid * p...@pidster.com wrote: Which version of Tomcat are you using? p On 12 April 2010 01:35, Sam Stephens samspad...@gmail.com wrote: Hi all. The tomcat documentation says the following: If the web application is packaged as a WAR then /META-INF/context.xml will be copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to match the application's context path. Once this file exists, it will not be replaced if a new WAR with a newer /META-INF/context.xml is placed in the host's appBase. However, each time I upload a new WAR the existing context.xml gets deleted and replaced with the one inside the WAR file (which is just a default). So I lose all my configuration details. I have googled and it seems this is a common problem. Any help ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- -- pidster.com -- -- pidster.com -- -- pidster.com
RE: Tomcat 6.0.24 requires me to log on twice
No, the logon page is very simple, without the navigation bar, so it doesn't link that page -Original Message- From: Pid * [mailto:p...@pidster.com] Sent: Friday, April 09, 2010 5:53 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.24 requires me to log on twice Terry, does your login page reference the same script URL as the secured pages, by any chance? p On 9 April 2010 17:39, Christopher Schultz ch...@christopherschultz.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/9/2010 12:14 PM, Terry Horner wrote: The problem seems to occur if there are any restricted resources within a page - it doesn't seems too outlandish for someone to restrict access to their images folder (say, it has client logos in it and they are required to be a bit paranoid about their client list). If you have a restricted images folder, why are you trying to serve images out of it onto a non-restricted page? I have a workaround that will work for some people in this situation - require all logons to go through index.jsp (or whatever) and have this be a page that just shows a 'loading...' animated image (or whatever) - but this doesn't work if you want to be able to bookmark pages within your site. If you bookmark a restricted page, you don't even see it until after successful authentication, so there's no problem there. The problem is with including restricted content in an unrestricted page. I agree that your webapp shouldn't be suffering the kind of fate it is currently is, but you'd save yourself a lot of trouble by not doing something which seems so illogical. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku/WDMACgkQ9CaO5/Lv0PCKagCffXehaOcXta2EFqGDPG19HnOK MkcAn2WlANst7s5vhMDk/A7Pj3WTnIe3 =b/EF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- -- pidster.com _ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk ___ The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the Dancerace network. Dancerace plc will not be liable for direct, special, indirect or consequential damages arising from the alteration of the contents of this message by a third party or as a result of any virus being passed on. Dancerace plc reserve the right to monitor and record e-mail messages sent to and from this address for the purpose of investigating or detecting any unauthorised use of its system and ensuring its effective operation. _ This message has been checked for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. For further information visit http://www.uk.uu.net/products/security/virus/ ** Message from InterScan VirusWall 6 ** ** No virus found in attached file noname.htm InterScan VirusWall 6 has scanned this message and found it to be free of known viruses. * End of message *** - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/9/2010 12:14 PM, Terry Horner wrote: The problem seems to occur if there are any restricted resources within a page - it doesn't seems too outlandish for someone to restrict access to their images folder (say, it has client logos in it and they are required to be a bit paranoid about their client list). If you have a restricted images folder, why are you trying to serve images out of it onto a non-restricted page? I have a workaround that will work for some people in this situation - require all logons to go through index.jsp (or whatever) and have this be a page that just shows a 'loading...' animated image (or whatever) - but this doesn't work if you want to be able to bookmark pages within your site. If you bookmark a restricted page, you don't even see it until after successful authentication, so there's no problem there. The problem is with including restricted content in an unrestricted page. I agree that your webapp shouldn't be suffering the kind of fate it is currently is, but you'd save yourself a lot of trouble by not doing something which seems so illogical. - -chris That would be illogical, but it's not what I'm doing - in our system (and in the hypothetical example) the restricted images are inside a restricted page. The bookmarks are to a restricted page, any unrestricted pages on our system only hold unrestricted resources. ___ The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the Dancerace network. Dancerace plc will not be liable for direct, special, indirect or consequential damages arising from the alteration of the contents of this message by a third party or as a result of any virus being passed on. Dancerace plc reserve the right to monitor and record e-mail messages sent to and from this address for the purpose of investigating or detecting any unauthorised use of its system and ensuring its effective operation. _ This message has been checked for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. For further information visit http://www.uk.uu.net/products/security/virus/ ** Message from InterScan VirusWall 6 ** ** No virus found in attached file noname.htm InterScan VirusWall 6 has scanned this message and found it to be free of known viruses. * End of message *** - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.24 requires me to log on twice
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, April 09, 2010 5:55 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.24 requires me to log on twice -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/9/2010 12:08 PM, Terry Horner wrote: There aren't any iframes or frames. The navbar does use document.write to add several divs to the page. Good. Presumably, all this content-generation is done on page load? It shouldn't really matter, since you're using cookies for everything. It's generated by the included (restricted) .js file, rather than being in a function that is explicitly called in onload. But I checked and the problem occurs even if the js file is empty - which makes sense, as the problem is with accessing the file rather than what is done with it. (1)user sees first logon page, with image (2) they logon, see the data page, but without the embedded navbar, the request for which is met with a logon page (not displayed because the browser expects a .js file) (3)user requests a different page, and are told to login again (4)they do, the system logs them on, gets the navbar request, logs them on again without the user doing anything (???), then from this point they have a normal user experience #Fields: c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status cs(Cookie) x-P(j_username) #Version: 2.0 #Software: Apache Tomcat/6.0.26 (1) localhost - 2010-04-09 15:32:14 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 - localhost - 2010-04-09 15:32:15 'HTTP/1.1' GET /frontend/images/image1.gif 200 '08E40C3900' (2) localhost - 2010-04-09 15:32:19 'HTTP/1.1' POST /j_security_check 302 '08E40C3900' Okay, that all looks normal. Note the 302 response which is directing the client to re-request the original URL: localhost 'user75' 2010-04-09 15:32:22 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 - Hmm... no cookie included with this request. I wonder why. Looking at old logfiles from slightly older tomcat 6.0 versions this seems to be normal - this request in the last step in the request data page-get sent to logon page-send username and password-get forwarded to data page process. The original request to dataservlet1 didn't have a cookie assigned, so this one doesn't either. localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/functions.js 200 '08E40C3900' localhost - 2010-04-09 15:32:24 'HTTP/1.1' GET /javascriptservlet?request=common.js 200 '08E40C3900' Old (stale) session id :( localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/logo.gif 200 'B5F7F32D85' (3) New session id. This request was made 30 seconds after the previous one. Is this the same client? Yes, this is on a test system, with only one user on at time. localhost - 2010-04-09 15:33:02 'HTTP/1.1' GET /dataservlet2?timestamp=1270827182637 200 'B5F7F32D85' localhost - 2010-04-09 15:33:02 'HTTP/1.1' GET /frontend/images/global/image1.gif 200 'B5F7F32D85' (4) localhost - 2010-04-09 15:33:06 'HTTP/1.1' POST /j_security_check 302 'B5F7F32D85' Another login interception (to /dataservlet2, probably) and redirect to original URL. localhost 'user75' 2010-04-09 15:33:06 'HTTP/1.1' GET /dataservlet2?timestamp=1270827182637 200 'B5F7F32D85' Authentication in this case doesn't appear to have switched the session id. The original request to dataservlet2 had a cookie assigned, so this one does too. (Is my interpretation. I'm far from sure) This may have something to do with why this logon works. The request for dataservlet1 above doesn't have a cookie, and doesn't stick, this request does have a cookie, and does stick (albeit with a different session ID) If you log on, go through this process, log off again, then log on again there isn't a problem - my theory is that this is because when you are logged off there is still a JSESSIONID cookie present (it points at an invalid session), and that somehow everything works if you send a JSESSIONID cookie, nomatter what its value. (By 'stick' I mean that from this point all resources are shown correctly and the user isn't shown the logon screen again) If I am right here I'm not entirely sure why. localhost 'user75' 2010-04-09 15:33:08 'HTTP/1.1' GET /javascriptservlet?request=common.js 200 'E892F3EB0B' and from here on all requests use the E892F3EB0B cookie ...which appears to be the re-assigned session id for the login associated with the B5F7F32D85 session id. That's all very weird. What's your session timeout? I'm wondering why at 2010-04-09 15:33:00 there was a bare request for an image, and then why there was no session id accompanying the request for /dataservlet1 at 2010-04-09 15:32:22. The session timeout is 30 minutes. I mentioned before that I had abridged the access log - my aim was to keep the clutter out of the way - the full log
Re: Installing certificate chain on Tomat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /U, On 4/10/2010 3:31 PM, /U wrote: Connector port=443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/users/me/.keystore keystorePass=changeit / Are you using APR (aka Tomcat native)? I have received the following keys/certs from CA: - file1: private key for myhost - file2: identity certificate for myhost signed by CA1 - file3: certificate for CA1 signed by entrust I installed private key (file1) and myhost cert (file2) into /users/me/.keystore using the ImportKey utility. I installed the CA1's certificated into /users/me/.keystore using keytool. My keytool lookslike this: $ keytool -list -keystore /users/me/.keystore ...password... Heh... you mean it's not changeit? :) Keystore type: JKS Keystore provider: SUN Your keystore contains 2 entries Shouldn't that be 3 entries? CA1, Apr 10, 2010, trustedCertEntry, Certificate fingerprint (MD5): 2F:B3:00:F2:FA:12:7B:BD:82:95:70:05:99:12:17:DB:BE tomcat, Apr 10, 2010, PrivateKeyEntry, Certificate fingerprint (MD5): CD:D9:06:11:30:CD:C2:60:33:33:68:A2:30:5C:01:50 What about the entrust one? I did not install any certificates into truststore (jre/lib/security/cacerts). When I connect browser to https://myhost, i get a cert error that myhost is signed by CA1and cannot be trusted. Browser show only one cert (for myhost) and not show the full cert chain (myhost - CA1 and CA1 - entrust). Why is the full cert chain not sent to browser. Because you haven't provided the whole certificate chain to Tomcat. Tomcat can only send what it already has. Since entrust CA cert is in browser CA list, if tomcat send full cert chain to browser, it would be trusted. Maybe, maybe not. It's possible that the real cert chain goes like this: myhost - CA1 - Entrust - Entrust Global If your browser only knows about the Entrust Global cert, then your chain is broken. Did you follow the instructions on Entrust's web site? http://www.entrust.net/knowledge-base/technote.cfm?tn=7559 (for chain certs) http://www.entrust.net/knowledge-base/technote.cfm?tn=7583 (for bare certs, I guess) Perhaps they are the ones to ask about this. You might want to ask why they don't support a version of Tomcat after 4.1. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDIPAACgkQ9CaO5/Lv0PDmAACfce9J55S5uIHkXTiku9l1YQKa FGkAnjPIXGcvn2B2CQlguGbaz0eTmwkU =G6eH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Installing certificate chain on Tomat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/U,
On 4/10/2010 4:13 PM, /U wrote:
i am confused about one thing: whil keystore is explicitly specified
in connector config, what about the truststore?
It can also be configured in the Connector. Have you not read any of
the documentation?
i assume truststore stores the trusted CA certs (as opposed to
private keys/identity cert). Is this correct?
http://lmgtfy.com/?q=java+keystore+versus+truststore
Why does not connector config not refer to truststore config ?
Because most people don't need it. It's getting more common to see
chained certificates, but I'm not entirely sure that the truststore is
required. Patches to the documentation are always welcome.
Or is that by default become ${JAVA_HOME}/jre/lib/security/cacerts?
Please read the HTTP Connector documentation: it really does tell you
what all thee defaults are.
What is the relation/differences (as far as tomcat is concerned) between
keystore, truststore and {JAVA_HOME}/jre/lib/security/cacerts?
http://lmg... oh, I can't even bring myself to finish that.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvDIeIACgkQ9CaO5/Lv0PC+OQCgtKM5wE/B8FTxLsIChrh3nmn+
WQ4Anjq85Qgqzs/NuM1tMDA3mR2WutvS
=p3cW
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 8:05 AM, Terry Horner wrote: That would be illogical, but it's not what I'm doing - in our system (and in the hypothetical example) the restricted images are inside a restricted page. The bookmarks are to a restricted page, any unrestricted pages on our system only hold unrestricted resources. I've never had anything like this happen except when I was doing things like multiple webapps deployed into the same URL space. You said this was an example: what is the context path of the real deployed webapp? Are there more than one webapp involved, here? If you have a working example, can you post a ZIP file to the list that exhibits this behavior? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDIskACgkQ9CaO5/Lv0PBG5gCfXTIvmG7546fFQz1oNfGHBvda aQAAoLqqaNj6RyTRLw177ANpUNPJphxM =YKsd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 9:23 AM, Terry Horner wrote: Looking at old logfiles from slightly older tomcat 6.0 versions this seems to be normal - this request in the last step in the request data page-get sent to logon page-send username and password-get forwarded to data page process. The original request to dataservlet1 didn't have a cookie assigned, so this one doesn't either. No, the difference between an authenticated user and an unauthenticated one is the presence of the cookie: otherwise, the server has no idea who the client is. Without the cookie, there is no identifying information. The absence of that cookie is concerning. How are you generating this log file? Using the AccessLogValve? At what level (server or Context)? And what is your log pattern string? The original request to dataservlet2 had a cookie assigned, so this one does too. (Is my interpretation. I'm far from sure) This may have something to do with why this logon works. The request for dataservlet1 above doesn't have a cookie, and doesn't stick, this request does have a cookie, and does stick (albeit with a different session ID) That's what I'm thinking, but it should all be the same code. Something about your app make this different somehow. If you log on, go through this process, log off again, then log on again there isn't a problem - my theory is that this is because when you are logged off there is still a JSESSIONID cookie present (it points at an invalid session), and that somehow everything works if you send a JSESSIONID cookie, nomatter what its value. No, the JSESSIONID cookie should be deleted from the client when you log out. Can you verify that this is true by looking at your web browser's cookie store during and after your session? I mentioned before that I had abridged the access log - my aim was to keep the clutter out of the way - the full log for around this point is more like[:] localhost 'user75' 2010-04-09 15:32:22 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 - - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/general.css 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/ie.css 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/functions.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/1.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/2.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:23 'HTTP/1.1' GET /frontend/includes/3.js 200 '08E40C3900' - Good: all the same cookie value ;) localhost - 2010-04-09 15:32:24 'HTTP/1.1' GET javascriptservlet?request=common.js 200 '08E40C3900' - There is no leading slash on that URL which looks funny to me. It's unlikely to be the problem, but it certainly doesn't look right. localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image1.jpg 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image2.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image3.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/logo.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image4.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image5.jpg 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image6.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image7.jpg 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image8.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:01 'HTTP/1.1' GET /frontend/images/global/image9.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:02 'HTTP/1.1' GET /dataservlet2?timestamp=1270827182637 200 'B5F7F32D85' - ... and now the cookie value has changed for no reason that I can see. Did you omit some of the log again? Say, an authentication attempt? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDJIEACgkQ9CaO5/Lv0PCj2wCfSO08ROQuugnz/TMATu9lAav3 z7cAnjXGz1Kj8glz8O7gYjKBMYLo3BGi =+/hi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Timeout - Filter Not Called
That works in that my filter is called when the session times out and the user is redirected to the login page. However, the Referer header makes no indication that the user is logging in. In Jetty, the Referer header would be /login.do. This would indicate that the user is logging in. If the request URI is not null, then I can redirect them to the requested URI if it has been determined that it is a safe area that does not need any session variables established. Is there a way to determine if the user's session has timed out and the user is logging in once again? --- rfha...@yahoo.com wrote: From: Bob Hall rfha...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Subject: Re: Session Timeout - Filter Not Called Date: Sun, 11 Apr 2010 22:52:37 -0700 (PDT) Paul, --- On Sun, 4/11/10, Paul Carroll pcarr...@nfmail.net wrote: I am using Tomcat 6.0 on Windows Server 2003. It seems that when my session expires I am redirected to the login page which I would expect. However, my filter is not called when I am redirected to the login page. When I used Jetty as my web server, the call was intercepted by the filter before the user was presented the login page. Does anyone know why this is the case? The following is the sections of my web.xml that contains the filter info. filter filter-nameSessionTimeoutFilter/filter-name filter-classcom.mycompany.ui.filters.SessionTimeoutFilter/filter-class init-param param-namehome/param-name param-value/home.do/param-value /init-param /filter filter-mapping filter-nameSessionTimeoutFilter/filter-name servlet-nameaction/servlet-name /filter-mapping servlet servlet-nameaction/servlet-name servlet-classcom.mycompany.ui.web.ActionServlet/servlet-class init-param param-nameconfig/param-name /init-param /servlet servlet-mapping servlet-nameaction/servlet-name url-pattern*.do/url-pattern /servlet-mapping My index.jsp contains 1 line which redirects to home.do. Your filter is mapped to servlet-name action which is mapped to url-pattern *.do Don't know about Jetty, but you will probably get the behavior you expect if you change the filter-mapping element to use: url-mapping/*/url-mapping (and remove servlet-name) - Bob - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Which native library?
That was my first thought, as I was copying from previously downloaded files, and I'd see the same symptoms in a known instance of mismatch. So I went to the Tomcat Archives and downloaded them again, making sure I was in the 32-bit tree. The posted catalina.log is the result of that latter download. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Thursday, April 08, 2010 7:50 PM To: Tomcat Users List Subject: Re: Which native library? On Apr 8, 2010, at 17:49, Christopher Schultz ch...@christopherschultz.net wrote: Sounds like it's not loading no matter what version you try. Maybe you don't have the java.library.path you think you do, or maybe you just haven't put the DLL in the right place. Or perhaps there's a 32/64-bit mismatch. The JVM will ignore DLLs that are not the same mode as the JVM. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Which native library?
*** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. ---BeginMessage--- Hi Chris - The only thing I was doing was replacing the existing file in the Tomcat\bin directory and restarting. I had 1.1.3 (which was downloaded by the installer) working. So I stopped Tomcat, replaced it with 1.1.20, started Tomcat and received those errors. Then I did the same steps replacing with 1.1.19, and finally 1.1.18, before getting one that worked. Nothing else was changed. I'm guessing there some Windows 2000 support that was dropped during the compile stage of 1.1.19 and up somewhere. Jeff -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, April 08, 2010 4:49 PM To: Tomcat Users List Subject: Re: Which native library? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, On 4/8/2010 4:35 PM, Jeffrey Janner wrote: Allow me to answer my own question: 1.1.18 I just started downloading from the archive until I found one that worked. Generally, the latest is always the best. Any clue what happened between 1.1.18 1.1.19? http://tomcat.apache.org/native-doc/miscellaneous/changelog.html !-- with 1.1.20 -- Apr 8, 2010 3:14:40 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files\Apache Software Foundation\Tomcat [...] This indicates that the DLL file wasn't found or could not be initialized for some other reason. Is tcnative.dll somewhere in the path listed? INFO: Initializing Coyote HTTP/1.1 on http-172.16.9.1-80 Apr 8, 2010 3:14:40 PM org.apache.coyote.http11.Http11BaseProtocol init SEVERE: Error initializing endpoint java.io.FileNotFoundException: C:\Documents and Settings\Administrator\.keystore (The system cannot find the file specified) Does this file exist? If you are trying to use APR, then presumably you have a different configuration for your SSL using certificate files, etc. instead of a keystore. If APR isn't initializing correctly, you'll get an error trying to configure the standard connector. Until you get your APR configured properly, you can ignore the complaints that the standard connector gives you. !-- with 1.1.19 -- Apr 8, 2010 3:16:06 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files\Apache Software Foundation\Tomcat [...] Sounds like it's not loading no matter what version you try. Maybe you don't have the java.library.path you think you do, or maybe you just haven't put the DLL in the right place. !-- with 1.1.18 -- Apr 8, 2010 3:16:54 PM org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-172.16.9.1-80 Apr 8, 2010 3:16:55 PM org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-172.16.9.1-443 The only thing I can think of is that you have the DLL in the wrong place, but it seems you've been able to get it working with 1.1.8. I have seen the unable to locate library errors in 5.5.28 installs with 1.1.19 1.1.20, but at least the OpenSSL still worked. Since the use of OpenSSL is predicated on the successful use of APR, I'm not sure how this could be true. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku+T2EACgkQ9CaO5/Lv0PDhWgCgvzHju8XQzsSCv26t3PzQT+pH ofkAoJ3uFqVslZL1PsNM1rfPeBUM/F9k =jWUB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org ---End Message--- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Which native library?
2010/4/12 Jeffrey Janner jeffrey.jan...@polydyne.com Subject: RE: Which native library? Hi Chris - The only thing I was doing was replacing the existing file in the Tomcat\bin directory and restarting. I had 1.1.3 (which was downloaded by the installer) working. So I stopped Tomcat, replaced it with 1.1.20, started Tomcat and received those errors. Then I did the same steps replacing with 1.1.19, and finally 1.1.18, before getting one that worked. Nothing else was changed. I'm guessing there some Windows 2000 support that was dropped during the compile stage of 1.1.19 and up somewhere. Jeff 1. I wonder why you are not observing https://issues.apache.org/bugzilla/show_bug.cgi?id=47712 2. Please try 5.5.29 - see voting thread on dev@ list. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6 and deprecated HTML attributes
The request object in the servlet spec as I understand it as used in the Tomcat 6 container for example makes use of the deprecated HTML attribute name in order to tie individual elements of a HTML form to server-side variables. This seem to imply that in order to produce working Servlets one has to make pages that are invalid according to the HTML 4.01 Strict spec as well as XHTML. Is there any acceptable ways around this problem? I tried using just the attribute id, but then my forms was not understood by Tomcat 6 (the version that comes with Netbeans 6.8). I imagine I could make my own request object, inherit and override name with id, but perhaps this have already been done somewhere? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 and deprecated HTML attributes
On Mon, Apr 12, 2010 at 8:00 AM, MB digital.disc...@gmail.com wrote: The request object in the servlet spec as I understand it as used in the Tomcat 6 container for example makes use of the deprecated HTML attribute name in order to tie individual elements of a HTML form to server-side variables. The name attribute is *not* deprecated for form elements. -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.24 requires me to log on twice
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, April 12, 2010 2:48 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.24 requires me to log on twice -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 9:23 AM, Terry Horner wrote: Looking at old logfiles from slightly older tomcat 6.0 versions this seems to be normal - this request in the last step in the request data page-get sent to logon page-send username and password-get forwarded to data page process. The original request to dataservlet1 didn't have a cookie assigned, so this one doesn't either. No, the difference between an authenticated user and an unauthenticated one is the presence of the cookie: otherwise, the server has no idea who the client is. Without the cookie, there is no identifying information. The absence of that cookie is concerning. How are you generating this log file? Using the AccessLogValve? At what level (server or Context)? And what is your log pattern string? org.apache.catalina.valves.ExtendedAccessLogValve the definition is within the host, not the context. The log pattern string is now c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status cs(Cookie) I have trimmed out the JSESSIONID= and any other cookies, because it used to be c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status x-H(requestedSessionId) cs(Referer) cs(User-Agent) time-taken cs(Cookie) and I trimmed off all of the extra stuff at the end. It seemed like changing format halfway through would be unhelpful The original request to dataservlet2 had a cookie assigned, so this one does too. (Is my interpretation. I'm far from sure) This may have something to do with why this logon works. The request for dataservlet1 above doesn't have a cookie, and doesn't stick, this request does have a cookie, and does stick (albeit with a different session ID) That's what I'm thinking, but it should all be the same code. Something about your app make this different somehow. If you log on, go through this process, log off again, then log on again there isn't a problem - my theory is that this is because when you are logged off there is still a JSESSIONID cookie present (it points at an invalid session), and that somehow everything works if you send a JSESSIONID cookie, nomatter what its value. No, the JSESSIONID cookie should be deleted from the client when you log out. Can you verify that this is true by looking at your web browser's cookie store during and after your session? If I am on the logout.html page and do a javascript:alert(document.cookie); it shows a JSESSIONID cookie and no others (this is also true on older versions of 6.0) - the cookie store shows the same cookie. It's a new cookie, unrelated to any of the requests before it. localhost '44-000' 2010-04-12 15:10:15 'HTTP/1.1' GET /frontend/images/global/image10.gif 200 '9394BACA2D' localhost '44-000' 2010-04-12 15:10:17 'HTTP/1.1' GET /logout.html?timestamp=1271085014943 200 '9394BACA2D' localhost - 2010-04-12 15:10:17 'HTTP/1.1' GET /includes/logout.css 200 '9F16E6DAF0' localhost - 2010-04-12 15:10:17 'HTTP/1.1' GET /frontend/images/global/logoutimg.jpg 200 '9F16E6DAF0' If I refresh the page the cookie changes, but there is still a cookie. I mentioned before that I had abridged the access log - my aim was to keep the clutter out of the way - the full log for around this point is more like[:] localhost 'user75' 2010-04-09 15:32:22 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 - - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/general.css 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/ie.css 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/functions.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/1.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/2.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:23 'HTTP/1.1' GET /frontend/includes/3.js 200 '08E40C3900' - Good: all the same cookie value ;) localhost - 2010-04-09 15:32:24 'HTTP/1.1' GET javascriptservlet?request=common.js 200 '08E40C3900' - There is no leading slash on that URL which looks funny to me. It's unlikely to be the problem, but it certainly doesn't look right. I checked the original, cut'n'paste error, sorry localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image1.jpg 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image2.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image3.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/logo.gif 200 'B5F7F32D85' - localhost -
RE: Tomcat 6.0.24 requires me to log on twice
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, April 12, 2010 2:40 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.24 requires me to log on twice -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 8:05 AM, Terry Horner wrote: That would be illogical, but it's not what I'm doing - in our system (and in the hypothetical example) the restricted images are inside a restricted page. The bookmarks are to a restricted page, any unrestricted pages on our system only hold unrestricted resources. I've never had anything like this happen except when I was doing things like multiple webapps deployed into the same URL space. You said this was an example: what is the context path of the real deployed webapp? Are there more than one webapp involved, here? If you have a working example, can you post a ZIP file to the list that exhibits this behavior? - -chris The webapp is one of two in a single sign-on environment, and listens on /. The other webapp is a simple one used to provide a client with a customised login page (they go to /clientname/intro.html, login through /clientname/login.jsp and, if successful are forwarded to /intro.html , which is on the main ap) However, if I remove the other application, and the SSO valve the same behaviour occours. before Context path= docBase=dabce debug=0 override=true crossContext=true reloadable=true Manager className=org.apache.catalina.session.StandardManager entropy=hiddenstuff maxActiveSessions=-1 maxInactiveInterval=1600 sessionIdLength=24 / Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context Context path=/clientname docBase=customlogon override=true crossContext=true reloadable=true Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context Valve className=org.apache.catalina.authenticator.SingleSignOn / after Context path= docBase=dabce debug=0 override=true reloadable=true Manager className=org.apache.catalina.session.StandardManager entropy=hiddenstuff maxActiveSessions=-1 maxInactiveInterval=1600 sessionIdLength=10 / Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context It's difficult to trim our application down to a simple test case. I will send one when I can. Terry ___ The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the Dancerace network. Dancerace plc will not be liable for direct, special, indirect or consequential damages arising from the alteration of the contents of this message by a third party or as a result of any virus being passed on. Dancerace plc reserve the right to monitor and record e-mail messages sent to and from this address for the purpose of investigating or detecting any unauthorised use of its system and ensuring its effective operation. _ This message has been checked for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. For further information visit http://www.uk.uu.net/products/security/virus/ ** Message from InterScan VirusWall 6 ** ** No virus found in attached file noname.htm InterScan VirusWall 6 has scanned this message and found it to be free of known viruses. * End of message *** - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Timeout - Filter Not Called
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul, On 4/11/2010 7:11 PM, Paul Carroll wrote: I am using Tomcat 6.0 on Windows Server 2003. It seems that when my session expires I am redirected to the login page which I would expect. However, my filter is not called when I am redirected to the login page. When I used Jetty as my web server, the call was intercepted by the filter before the user was presented the login page. Does anyone know why this is the case? The following is the sections of my web.xml that contains the filter info. Valves are called before filters, and Tomcat's authentication and authorization are implemented as Valves. I don't believe you can have your filter run before the auth Valve. If you need your filter to run first, you can use a filter-based implementation of authentication/authorization such as securityfilter (http://securityfilter.sourceforge.net). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDQb0ACgkQ9CaO5/Lv0PBilQCfad+n775Jion08oe0qpKfPxew vWIAn0CtKOSgmMpW0V3JbrF/MncD3Fqj =bPkC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session Timeout - Filter Not Called
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul, On 4/11/2010 7:11 PM, Paul Carroll wrote: I am using Tomcat 6.0 on Windows Server 2003. It seems that when my session expires I am redirected to the login page which I would expect. However, my filter is not called when I am redirected to the login page. When I used Jetty as my web server, the call was intercepted by the filter before the user was presented the login page. Does anyone know why this is the case? The following is the sections of my web.xml that contains the filter info. Valves are called before filters, and Tomcat's authentication and authorization are implemented as Valves. I don't believe you can have your filter run before the auth Valve. If you need your filter to run first, you can use a filter-based implementation of authentication/authorization such as securityfilter (http://securityfilter.sourceforge.net). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDQb0ACgkQ9CaO5/Lv0PBilQCfad+n775Jion08oe0qpKfPxew vWIAn0CtKOSgmMpW0V3JbrF/MncD3Fqj =bPkC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question about connector threads
I'm running Tomcat 5.5.17 as a service on Windows 2000 SP4 w/native-APR 1.1.18. I've got the following connector configured: Connector address=172.16.9.1 port=443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=5 maxSpareThreads=75 enableLookups=false acceptCount=100 connectionTimeout=2 disableUploadTimeout=true scheme=https secure=true clientAuth=false SSLEngine=on .REST OF SSL STUFF... When I look at the connector using the Tomcat Manager, I see the following info: http-172.16.9.1-443 Max threads: 150 Min spare threads: 0 Max spare threads: 0 Current thread count: 83 Current thread busy: 82 Keeped alive sockets count: 0 Max processing time: 36828 ms Processing time: 312.233 s Request count: 3028 Error count: 37 Bytes received: 0.07 MB Bytes sent: 30.01 MB Obviously, the max setting is working, but the spare settings are showing up as zeroes. Is that just a release bug? Or do I really have something wrong with the config? The other question I have: Should I be worried about those 82 busy threads? The session count for the app is zero, and no one has probably used it for hours. Jeff *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments.
Re: Question about connector threads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, On 4/12/2010 12:57 PM, Jeffrey Janner wrote: I'm running Tomcat 5.5.17 as a service on Windows 2000 SP4 w/native-APR 1.1.18. FYI tcnative is at 1.1.20, now, and TC 5.5 is at 5.5.28. Always good to be up-to-date if you can afford to upgrade. I've got the following connector configured: Connector address=172.16.9.1 port=443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=5 maxSpareThreads=75 enableLookups=false acceptCount=100 connectionTimeout=2 disableUploadTimeout=true scheme=https secure=true clientAuth=false SSLEngine=on .REST OF SSL STUFF... When I look at the connector using the Tomcat Manager, I see the following info: http-172.16.9.1-443 Max threads: 150 Min spare threads: 0 Max spare threads: 0 Current thread count: 83 Current thread busy: 82 Keeped alive sockets count: 0 Max processing time: 36828 ms Processing time: 312.233 s Request count: 3028 Error count: 37 Bytes received: 0.07 MB Bytes sent: 30.01 MB Obviously, the max setting is working, but the spare settings are showing up as zeroes. Is that just a release bug? Or do I really have something wrong with the config? That config looks okay to me. The other question I have: Should I be worried about those 82 busy threads? The session count for the app is zero, and no one has probably used it for hours. You should takea thread dump and see what they're doing. It's possible that threads used along with the APR connector always count as busy... or maybe they are still connected and waiting for followup keepalive requests. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDXacACgkQ9CaO5/Lv0PAzvACfY3uy9AFVxqqFRVMq6PIKh7Sf N+gAnjDaKNgdhTBkNy3F8J2j7uvKSU9W =PfVN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about connector threads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, On 4/12/2010 1:51 PM, Christopher Schultz wrote: Jeffrey, On 4/12/2010 12:57 PM, Jeffrey Janner wrote: I'm running Tomcat 5.5.17 as a service on Windows 2000 SP4 w/native-APR 1.1.18. FYI tcnative is at 1.1.20, now, and TC 5.5 is at 5.5.28. Always good to be up-to-date if you can afford to upgrade. Heh... I forgot you were the one with the problem with 1.1.19 and 1.1.20. Forget upgrading I guess ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDYo8ACgkQ9CaO5/Lv0PDByACgp20QTvqwHPez9IImA76y1G4+ ZbMAoLToafz/6jMq82Ihml8rJOb/oAnZ =CiSE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 11:38 AM, Terry Horner wrote: The webapp is one of two in a single sign-on environment, and listens on /. The other webapp is a simple one used to provide a client with a customised login page (they go to /clientname/intro.html, login through /clientname/login.jsp and, if successful are forwarded to /intro.html , which is on the main ap) Hmm, that could complicate things. However, if I remove the other application, and the SSO valve the same behaviour occours. That's good to know. Let's take a look. before Context path= docBase=dabce debug=0 override=true crossContext=true reloadable=true Manager className=org.apache.catalina.session.StandardManager entropy=hiddenstuff maxActiveSessions=-1 maxInactiveInterval=1600 sessionIdLength=24 / Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context Context path= is illegal. Where did you define your Context? Context path=/clientname docBase=customlogon override=true crossContext=true reloadable=true Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context Valve className=org.apache.catalina.authenticator.SingleSignOn / after Context path= docBase=dabce debug=0 override=true reloadable=true Manager className=org.apache.catalina.session.StandardManager entropy=hiddenstuff maxActiveSessions=-1 maxInactiveInterval=1600 sessionIdLength=10 / Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context It's difficult to trim our application down to a simple test case. I will send one when I can. I think that would be best, honestly. Reproducibility is the most important factor when fixing issues like these. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDY1cACgkQ9CaO5/Lv0PDAFwCdEq/kq9TuXTbn65bxlt/Ag2Gs rccAoLDIUljNSh2S3+nRUcAWnYDyYs+j =Tf8U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 11:23 AM, Terry Horner wrote: org.apache.catalina.valves.ExtendedAccessLogValve the definition is within the host, not the context. The log pattern string is now c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status cs(Cookie) I have trimmed out the JSESSIONID= and any other cookies, because it used to be c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status x-H(requestedSessionId) cs(Referer) cs(User-Agent) time-taken cs(Cookie) and I trimmed off all of the extra stuff at the end. It seemed like changing format halfway through would be unhelpful Okay. Check to see if these is a discrepancy between cs(Cookie), x-H(requestedSessionId), x-H(requestedSessionIdFromCookie), x-H(requestedSessionIdValid). Also, you might want to use Wireshark or something else to verify that there's only one JSESSIONID cookie being sent. If you have two cookies with different ids (which can happen if they have different paths), that'll screw things up. No, the JSESSIONID cookie should be deleted from the client when you log out. Can you verify that this is true by looking at your web browser's cookie store during and after your session? If I am on the logout.html page and do a javascript:alert(document.cookie); it shows a JSESSIONID cookie and no others (this is also true on older versions of 6.0) - the cookie store shows the same cookie. It's a new cookie, unrelated to any of the requests before it. localhost '44-000' 2010-04-12 15:10:15 'HTTP/1.1' GET /frontend/images/global/image10.gif 200 '9394BACA2D' localhost '44-000' 2010-04-12 15:10:17 'HTTP/1.1' GET /logout.html?timestamp=1271085014943 200 '9394BACA2D' localhost - 2010-04-12 15:10:17 'HTTP/1.1' GET /includes/logout.css 200 '9F16E6DAF0' localhost - 2010-04-12 15:10:17 'HTTP/1.1' GET /frontend/images/global/logoutimg.jpg 200 '9F16E6DAF0' If I refresh the page the cookie changes, but there is still a cookie. JSPs will create a session (and therefore a JSESSIONID cookie) unless they are declared with @page session=false @. Are you hitting any dynamic resources from your logout page? No, I wanted to make sure everything was there. I assumed it had changed as a result of the javascriptservlet request somehow - the javascript doesn't normally take 36 seconds to reach the browser. Heh, yeah, that's pretty unreasonable. I think it might be time to look at the HTTP conversation that's going on. That's the only way I found out that I had two cookies with different paths fighting each other. :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDZUIACgkQ9CaO5/Lv0PDSNgCfaCNNHumDZx8Zcbw+J5anqCqh ewAAn01t0XMHuDFgpmy1Cd3MgOj1pyNH =omST -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat and UTF-8
Hi, Recently we migrated from Weblogic to Tomcat 5.5.28. After the migration we had issues in viewing special characters in UI, we updated UTF-8 encoding settings to web.xml and in TOMCATINSTALLDIR/conf/server.xml added the URIEncoding parameter to the connector. Web.xml settings filter filter-nameCharacter Encoding/filter-name filter-classcom.matrixone.servlet.SetCharacterEncodingFilter/filter-c lass init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameCharacter Encoding/filter-name url-pattern/*/url-pattern /filter-mapping Even after adding these setting, we are not able to see the old data properly. We are seeing junk characters instead of seeing the actual characters. So my questions: 1) Will tomcat properly display the characters that were stored prior to the migration? New data is displaying properly. 2) Are some other settings required to view the old data without seeing some junk characters? Thanks in advance for the response. Regards, Jagan
Re: Tomcat 6 and deprecated HTML attributes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MB, On 4/12/2010 11:00 AM, MB wrote: The request object in the servlet spec as I understand it as used in the Tomcat 6 container for example makes use of the deprecated HTML attribute name... +1 to Hassan's comments: the HTML attribute name certainly has not been deprecated for form elements. The whole web would break if that were true. http://dev.w3.org/html5/spec/Overview.html#attr-fe-name Think about it: radio buttons would no longer work, since multiple input elements are required, all with the same name. It is illegal to have multiple elements with the same id, so you can't correctly implement radio buttons without the name attribute. Note that input elements are not mentioned here: http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10 It's just the form that should use id instead of name. I imagine I could make my own request object, inherit and override name with id, but perhaps this have already been done somewhere? No, you couldn't: removing the name attribute would require that you modify the user agent, not the server. I think some web browsers will use the id attribute in place of the name attribute for a form element if the latter is not present. This behavior is not specified and shouldn't be relied upon. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDakgACgkQ9CaO5/Lv0PAx4wCgkDVgmg9650g0dhcJoXWBimD0 60sAoLK6rPySUEcDAN61jFieh7yjDNhI =H0Ii -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat startup error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill, On 4/10/2010 5:33 PM, Bill Barker wrote: Another thing to note is that the Tomcat folks have made an unstable change, here, by changing a public API. It would have been better to create a method with a new signature and deprecated the old one, while leaving it there. The Tomcat developers have always considered this to be part of the internal API, not the public API. This is true of most of the classes under the org.apache.tomcat package. Apologies for the public vs. internal API confusion. On the other hand, it does seem reasonable that the classes and methods used for embedding Tomcat should remain stable. Is the use of IntrospectionUtils pretty standard when it comes to using Tomcat in an embedded environment? Or, is this a case of a user using a Tomcat internal class for their own convenience when it isn't really appropriate to do so? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDauUACgkQ9CaO5/Lv0PA8UQCfWgbjiMCh/r5RXC2ZZAp45KY9 Py8An2xcNULQ/z2WFrlZfAEYPNXFPDRb =vGBI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and UTF-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jagan, On 4/12/2010 2:45 PM, Ramachandiran, Jagan Mohan [OCDUS Non JJ] wrote: Recently we migrated from Weblogic to Tomcat 5.5.28. After the migration we had issues in viewing special characters in UI, we updated UTF-8 encoding settings to web.xml and in TOMCATINSTALLDIR/conf/server.xml added the URIEncoding parameter to the connector. Please be specific: what encoding settings did you change in web.xml and how have you configured your Connector? Web.xml settings filter filter-nameCharacter Encoding/filter-name filter-classcom.matrixone.servlet.SetCharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameCharacter Encoding/filter-name url-pattern/*/url-pattern /filter-mapping Note that this (probably) sets the default character encoding for incoming request bodies. Even after adding these setting, we are not able to see the old data properly. We are seeing junk characters instead of seeing the actual characters. The above filter does not change anything about the output of your webapp: it only changes the way request bodies are interpreted. So my questions: 1) Will tomcat properly display the characters that were stored prior to the migration? New data is displaying properly. Tomcat pretty much just moves bytes around. As long as your webapp does not cross-code any text, everything should be fine. Is your database configured to store data in UTF-8? Is your JDBC driver configured to speak UTF-8? How about your JSPs, etc.: are they configured to emit text in UTF-8 encoding? 2) Are some other settings required to view the old data without seeing some junk characters? You must have changed something else to make your old data look broken. You should read this: http://wiki.apache.org/tomcat/FAQ/CharacterEncoding - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDbCIACgkQ9CaO5/Lv0PATKACeMoa158cCfJtrcde7lCpZPhpc AfoAn1uvWXYfh0iIqKd4MAHseERz8gKx =ydNY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6 and deprecated HTML attributes
I stand corrected. It seems that the elements: a, button, form, img, input, map, meta, object, select, param and textarea can have the attribute name under HTML 4.01 Strict. In the case of map and param it is even mandatory. Sorry for top-posting. I must change my gmail settings 2010/4/12 Christopher Schultz ch...@christopherschultz.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MB, On 4/12/2010 11:00 AM, MB wrote: The request object in the servlet spec as I understand it as used in the Tomcat 6 container for example makes use of the deprecated HTML attribute name... +1 to Hassan's comments: the HTML attribute name certainly has not been deprecated for form elements. The whole web would break if that were true. http://dev.w3.org/html5/spec/Overview.html#attr-fe-name Think about it: radio buttons would no longer work, since multiple input elements are required, all with the same name. It is illegal to have multiple elements with the same id, so you can't correctly implement radio buttons without the name attribute. Note that input elements are not mentioned here: http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10 It's just the form that should use id instead of name. I imagine I could make my own request object, inherit and override name with id, but perhaps this have already been done somewhere? No, you couldn't: removing the name attribute would require that you modify the user agent, not the server. I think some web browsers will use the id attribute in place of the name attribute for a form element if the latter is not present. This behavior is not specified and shouldn't be relied upon. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDakgACgkQ9CaO5/Lv0PAx4wCgkDVgmg9650g0dhcJoXWBimD0 60sAoLK6rPySUEcDAN61jFieh7yjDNhI =H0Ii -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
security, web.xml: multiple security-constraint override wildcard web-resource-collection
i am combininig multiple security-constraint and wildcard pattern. The result is a bit confusing. only and single security-constraint def: === security-constraint web-resource-collection web-resource-nameHTMLManger and Manager command/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint === Above gives me access to all ressources. Now adding another constraint disallows the 'admin' to access ressource /foo: === security-constraint web-resource-collection web-resource-nameHTMLManger and Manager command/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameHTMLManger and Manager command/web-resource-name url-pattern/foo/url-pattern /web-resource-collection auth-constraint role-nameother/role-name /auth-constraint /security-constraint === This is counterintuitive, I would still expect 'admin' to access all ressources, because it has /* wildcard. After debugging tomcat confirms, adding constraints is side-effecting exististing constraints. When reading the servlet specification SRV.12.8.1 it mentions an union operation of multiple security-constraint. But to me above behaviour looks more like a difference operation (the 2nd security constraint is removing a right from the 1st one). Or maybe I am reading something wrong...? thanks. - manuel aldana aldana((at))gmx.de software-engineering blog: http://www.aldana-online.de -- View this message in context: http://old.nabble.com/security%2C-web.xml%3A-multiple-%3Csecurity-constraint%3E-override-wildcard-%3Cweb-resource-collection%3E-tp28219182p28219182.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Installing certificate chain on Tomat
in my case, i am testing with clients authenticating to tomcat with dod cac cards. (smartcards) i downloaded the dod root p7b cert files i checked/verified the root cert for the client cac card certs, matched the dod root certs (in the p7b files) i extracted ONLY the root cert's from each p7b file into x.509 base64_encoded .cer file's then i imported ONLY those dod x509 root certs into tomcat's truststorefile now when a client browses to tomcat, it tries to authenticate with the client-cert (from the cac card) because tomcat has the root for the client cert loaded into its truststore, and the matching client cert subject name (ie: user) loaded in its auth realm the client is therefore authenticated i have more to do but that much is working. From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Mon, April 12, 2010 9:32:32 AM Subject: Re: Installing certificate chain on Tomat -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /U, On 4/10/2010 3:31 PM, /U wrote: Connector port=443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=/users/me/.keystore keystorePass=changeit / Are you using APR (aka Tomcat native)? I have received the following keys/certs from CA: - file1: private key for myhost - file2: identity certificate for myhost signed by CA1 - file3: certificate for CA1 signed by entrust I installed private key (file1) and myhost cert (file2) into /users/me/.keystore using the ImportKey utility. I installed the CA1's certificated into /users/me/.keystore using keytool. My keytool lookslike this: $ keytool -list -keystore /users/me/.keystore ...password... Heh... you mean it's not changeit? :) Keystore type: JKS Keystore provider: SUN Your keystore contains 2 entries Shouldn't that be 3 entries? CA1, Apr 10, 2010, trustedCertEntry, Certificate fingerprint (MD5): 2F:B3:00:F2:FA:12:7B:BD:82:95:70:05:99:12:17:DB:BE tomcat, Apr 10, 2010, PrivateKeyEntry, Certificate fingerprint (MD5): CD:D9:06:11:30:CD:C2:60:33:33:68:A2:30:5C:01:50 What about the entrust one? I did not install any certificates into truststore (jre/lib/security/cacerts). When I connect browser to https://myhost, i get a cert error that myhost is signed by CA1and cannot be trusted. Browser show only one cert (for myhost) and not show the full cert chain (myhost - CA1 and CA1 - entrust). Why is the full cert chain not sent to browser. Because you haven't provided the whole certificate chain to Tomcat. Tomcat can only send what it already has. Since entrust CA cert is in browser CA list, if tomcat send full cert chain to browser, it would be trusted. Maybe, maybe not. It's possible that the real cert chain goes like this: myhost - CA1 - Entrust - Entrust Global If your browser only knows about the Entrust Global cert, then your chain is broken. Did you follow the instructions on Entrust's web site? http://www.entrust.net/knowledge-base/technote.cfm?tn=7559 (for chain certs) http://www.entrust.net/knowledge-base/technote.cfm?tn=7583 (for bare certs, I guess) Perhaps they are the ones to ask about this. You might want to ask why they don't support a version of Tomcat after 4.1. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDIPAACgkQ9CaO5/Lv0PDmAACfce9J55S5uIHkXTiku9l1YQKa FGkAnjPIXGcvn2B2CQlguGbaz0eTmwkU =G6eH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: security, web.xml: multiple security-constraint override wildcard web-resource-collection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manuel, On 4/12/2010 4:38 PM, aldana wrote: This is counterintuitive, I would still expect 'admin' to access all ressources, because it has /* wildcard. After debugging tomcat confirms, adding constraints is side-effecting exististing constraints. When reading the servlet specification SRV.12.8.1 it mentions an union operation of multiple security-constraint. But to me above behaviour looks more like a difference operation (the 2nd security constraint is removing a right from the 1st one). Re-read those sections: it says that constraints are combined when they have the same pattern and method. You have different patterns, so the will not be combined. There's a great example right there in the text that demonstrates this. What version of the spec are you reading? In mine (v2.5 MR6), the relevant section is 12.7.1, not 12.8.1. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDihMACgkQ9CaO5/Lv0PAqHACfSjs0H+q2x/Bu2a2BBegeOxc9 sIgAoILDz5M5H80k1ST5SHec8IhzpoQ2 =6Uys -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml being deleted
Thanks for the earlier replies. So after some more research it seems there is no way to tell tomcat that I don't want particular directories to be deleted on an application redeploy? Is this correct ? I have a forum application. When we update it we want to distribute a new war file (previously we updated all files individually). If we give out a new war file to our customers the images directory, the attachments directory and other directories that contain user uploaded data will be wiped out. Is there a solution to this dilemma? Sym links are are no - you'd have to remake them each time so still a lot of work. Any advice gratefully received. -- -Sam - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml being deleted
On Mon, Apr 12, 2010 at 6:08 PM, Sam Stephens samspad...@gmail.com wrote: I have a forum application. When we update it we want to distribute a new war file (previously we updated all files individually). If we give out a new war file to our customers the images directory, the attachments directory and other directories that contain user uploaded data will be wiped out. Is there a solution to this dilemma? Sym links are are no - you'd have to remake them each time so still a lot of work. Well, AFAIK it's either symlinks (which can be scripted in deployment processes pretty easily) or put all that stuff in a separate context that you never, ever, EVER undeploy :-) I've used both approaches, can't really say I have a preference. The latter might be a little less work, and definitely reduces the exposure to symlink oopsies... FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to reload webapp automaticly under tomcat 6.0.20
I set following statement in conf/server.xml, it can run well before tomcat6.0.20,when I modify class file,tomcat can reload automaticly. Context path=/Test docBase=Test reloadable=true crossContext=true/Context But when I use tomcat 6.0.2,I find it can't reload automaticly,why? Where is wrong? How to do it? Thanks
