If there a security hardened / production ready binary distribution?
Hi all. Sorry if this has already been answered, but I couldn't find it. I'm looking at using tomcat in a docker container and I was wondering why there isn't a binary distribution that has most / all of the steps already done from the security how to? https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html I understand that there wouldn't be a true one size fits all, but I rather than get everyone to try to follow the same basic steps I thought that they would be done upstream in the project. If there's a reason why, I'm curious to learn what it is. I've also opened a ticket with the official docker tomcat image project for a tomcat that has this done. https://github.com/docker-library/tomcat/issues/14 Thanks for your time. Jim
restriction/limit of keystorePass in server.xml for TC7
Hi everyone, I know this maybe more of Java than Tomcat but in case it's coded somewhere... Anyway, is there a limit to number of characters (30 - 50) and limit to certain characters, symbols included, for the keystorePass? I only thing I can find for keystorePass limit tomcat 7 are how to setup SSL and enable TLSes only. I know some of you are thinking why 30+ when the password is in plain text file... TIA, Tommy
Re: Tomcat, REMOTE_USER, getRemoteUser()
Sorry, I was reading the latest Tomcat 8.0.24 source to verify how it
worked (it hasn't changed in some time it seems).
The flag to which you refer is for AJP only, hence the inconsistency (as
AJP becomes less common and reverse proxying HTTP becomes the norm).
On Thu, Jul 23, 2015, at 08:05 PM, Violeta Georgieva wrote:
Hi,
2015-07-23 21:54 GMT+03:00 John Baker jba...@dryfish.org.uk:
Hello,
I note the HTTP connector does the following when
Request.getRemoteUser() is called:
public String getRemoteUser() {
if (userPrincipal == null) {
return null;
}
return userPrincipal.getName();
}
I understand what it's trying to do but it's not consistent with the AJP
adapter and doesn't make it helpful to interact with upstream reverse
proxies setting the username as a header (ie REMOTE_USER). Would it be
possible to change the implementation to this:
public String getRemoteUser() {
String user = userPrincipal.getName();
if (userPrincipal == null)
user= getHeader(REMOTE_USER);
return user;
}
Or even better, allow the REMOTE_USER header name to be set via a
configuration value? This seems much more consistent with the AJP
adapter that does pick up REMOTE_USER (sent by the ajp module) and
avoids users having to retrieve a header from the request.
You didn't specify any Tomcat version.
Check this feature [1] - tomcatAuthentication/tomcatAuthorization
Regards,
Violeta
[1]
http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html#Standard_Implementations
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
TOMCAT 7 , Native CORS FILTER and Spring Security
Hi, I am using TOMCAT 7, and I have enable the CORS FILTER as per the explanation on the official website: https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter I use the actual configuration: filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-value*/param-value /init-param init-param param-namecors.allowed.methods/param-name param-valueGET,POST,HEAD,OPTIONS,PUT/param-value /init-param init-param param-namecors.allowed.headers/param-name param-valueContent-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers/param-value /init-param init-param param-namecors.exposed.headers/param-name param-valueAccess-Control-Allow-Origin,Access-Control-Allow-Credentials/param-value /init-param init-param param-namecors.support.credentials/param-name param-valuetrue/param-value /init-param init-param param-namecors.preflight.maxage/param-name param-value10/param-value /init-param /filter filter-mapping filter-nameCorsFilter/filter-name url-pattern/*/url-pattern /filter-mapping I do it in my Web.xml that is in the conf folder. However the app that i am trying to access have a spring security filter. I show below the application configuration in question. I have no control over that application. In fact this is a vendor application. I can only modify the configuration file to enable the CORS FILTER. !-- Spring Security START -- filter filter-namespringSecurityFilterChain/filter-name filter-classorg.springframework.web.filter.DelegatingFilterProxy/filter-class /filter filter-mapping filter-namespringSecurityFilterChain/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namespringSecurityFilterChain/filter-name url-pattern//url-pattern /filter-mapping !-- Spring Security END -- or a larger view filter filter-nameMessageFilter/filter-name filter-classat.punkt.PoolParty.Management.MessageFilter/filter-class /filter filter-mapping filter-nameMessageFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter filter-nameTransactionFilter/filter-name filter-classbiz.poolparty.thesaurus.web.support.TransactionFilter/filter-class /filter filter-mapping filter-nameTransactionFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter filter-nameSpringLocaleFilter/filter-name filter-classbiz.poolparty.thesaurus.web.support.SpringLocaleFilter/filter-class /filter filter-mapping filter-nameSpringLocaleFilter/filter-name url-pattern/*/url-pattern /filter-mapping !-- Spring Security START -- filter filter-namespringSecurityFilterChain/filter-name filter-classorg.springframework.web.filter.DelegatingFilterProxy/filter-class /filter filter-mapping filter-namespringSecurityFilterChain/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namespringSecurityFilterChain/filter-name url-pattern//url-pattern /filter-mapping !-- Spring Security END -- listener descriptionServletContextListener/description listener-classat.punkt.PoolParty.Management.PoolPartyListener/listener-class /listener !-- Location of the XML file that defines the root application context -- context-param param-namecontextConfigLocation/param-name param-valueclasspath:/applicationContext.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener !-- Include spring dispatcher servlet -- servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class load-on-startup2/load-on-startup async-supportedtrue/async-supported /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern/!/*/url-pattern /servlet-mapping servlet-mapping servlet-namedispatcher/servlet-name url-pattern/api/*/url-pattern /servlet-mapping I wonder if there is an issue between the Spring Security Filter and the Native Cors Filter coming with tomcat ? What are the work around ? If not how can I know what is exactly stop the CORS FILTER FROM WORKING RIGHT ? -- Maatari Daniel Okouya Sent with Airmail
Fw: TOMCAT 7 , Native CORS FILTER and Spring Security
-- Maatari Daniel Okouya Sent with Airmail On July 23, 2015 at 10:49:19 AM, Maatari Daniel Okouya (okouy...@yahoo.fr) wrote: Hi, I am using TOMCAT 7, and I have enable the CORS FILTER as per the explanation on the official website: https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter I use the actual configuration: filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-value*/param-value /init-param init-param param-namecors.allowed.methods/param-name param-valueGET,POST,HEAD,OPTIONS,PUT/param-value /init-param init-param param-namecors.allowed.headers/param-name param-valueContent-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers/param-value /init-param init-param param-namecors.exposed.headers/param-name param-valueAccess-Control-Allow-Origin,Access-Control-Allow-Credentials/param-value /init-param init-param param-namecors.support.credentials/param-name param-valuetrue/param-value /init-param init-param param-namecors.preflight.maxage/param-name param-value10/param-value /init-param /filter filter-mapping filter-nameCorsFilter/filter-name url-pattern/*/url-pattern /filter-mapping I do it in my Web.xml that is in the conf folder. However the app that i am trying to access have a spring security filter. I show below the application configuration in question. I have no control over that application. In fact this is a vendor application. I can only modify the configuration file to enable the CORS FILTER. !-- Spring Security START -- filter filter-namespringSecurityFilterChain/filter-name filter-classorg.springframework.web.filter.DelegatingFilterProxy/filter-class /filter filter-mapping filter-namespringSecurityFilterChain/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namespringSecurityFilterChain/filter-name url-pattern//url-pattern /filter-mapping !-- Spring Security END -- or a larger view filter filter-nameMessageFilter/filter-name filter-classat.punkt.PoolParty.Management.MessageFilter/filter-class /filter filter-mapping filter-nameMessageFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter filter-nameTransactionFilter/filter-name filter-classbiz.poolparty.thesaurus.web.support.TransactionFilter/filter-class /filter filter-mapping filter-nameTransactionFilter/filter-name url-pattern/*/url-pattern /filter-mapping filter filter-nameSpringLocaleFilter/filter-name filter-classbiz.poolparty.thesaurus.web.support.SpringLocaleFilter/filter-class /filter filter-mapping filter-nameSpringLocaleFilter/filter-name url-pattern/*/url-pattern /filter-mapping !-- Spring Security START -- filter filter-namespringSecurityFilterChain/filter-name filter-classorg.springframework.web.filter.DelegatingFilterProxy/filter-class /filter filter-mapping filter-namespringSecurityFilterChain/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namespringSecurityFilterChain/filter-name url-pattern//url-pattern /filter-mapping !-- Spring Security END -- listener descriptionServletContextListener/description listener-classat.punkt.PoolParty.Management.PoolPartyListener/listener-class /listener !-- Location of the XML file that defines the root application context -- context-param param-namecontextConfigLocation/param-name param-valueclasspath:/applicationContext.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener !-- Include spring dispatcher servlet -- servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class load-on-startup2/load-on-startup async-supportedtrue/async-supported /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern/!/*/url-pattern /servlet-mapping servlet-mapping servlet-namedispatcher/servlet-name url-pattern/api/*/url-pattern /servlet-mapping I wonder if there is an issue between the Spring Security Filter and the Native Cors Filter coming with tomcat ? What are the work around ? If not how can I know what is exactly stop the CORS FILTER FROM WORKING RIGHT ? -- Maatari Daniel Okouya Sent with Airmail
Re: If there a security hardened / production ready binary distribution?
On 23 July 2015 15:07:01 CEST, Jim Sellers jim.sell...@gmail.com wrote: Hi all. Sorry if this has already been answered, but I couldn't find it. I'm looking at using tomcat in a docker container and I was wondering why there isn't a binary distribution that has most / all of the steps already done from the security how to? https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html I understand that there wouldn't be a true one size fits all, but I rather than get everyone to try to follow the same basic steps I thought that they would be done upstream in the project. If there's a reason why, I'm curious to learn what it is. I've also opened a ticket with the official docker tomcat image project for a tomcat that has this done. https://github.com/docker-library/tomcat/issues/14 Thanks for your time. Jim Which default settings do you expect to be changed? Mark
Re: If there a security hardened / production ready binary distribution?
On Thu, Jul 23, 2015 at 10:50 AM, Mark Thomas ma...@apache.org wrote: On 23 July 2015 15:07:01 CEST, Jim Sellers jim.sell...@gmail.com wrote: Hi all. Sorry if this has already been answered, but I couldn't find it. I'm looking at using tomcat in a docker container and I was wondering why there isn't a binary distribution that has most / all of the steps already done from the security how to? https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html I understand that there wouldn't be a true one size fits all, but I rather than get everyone to try to follow the same basic steps I thought that they would be done upstream in the project. If there's a reason why, I'm curious to learn what it is. I've also opened a ticket with the official docker tomcat image project for a tomcat that has this done. https://github.com/docker-library/tomcat/issues/14 Thanks for your time. Jim Which default settings do you expect to be changed? Mark I was thinking the parts from that document that say should be or not intended for production. e.g. deleting the default apps, disabling the version number, etc. I'm somewhat new to TC and was looking for distribution that was closer to the recommended TC production setup than the default one. I was assuming that both would be available for download. Jim
Re: Tomcat-7.0.61 and SFlow_Valve.jar issue
I see that in SFlow_Valve Source code it’s already “long”: long bytes_read = (request.getCoyoteRequest()).getBytesRead(); Then what’s wrong and how can I fix this issue? Thanks! Sergey On Jul 23, 2015, at 11:52 AM, Violeta Georgieva miles...@gmail.com wrote: Hi, 2015-07-23 21:36 GMT+03:00 Sergey svin...@apple.com mailto:svin...@apple.com: We updated Tomcat from 7.0.10 to 7.0.61. In previous version we collected Tomcat metrics using Sflow_Valve.jar module. Now it looks like Coyote Connector can't call Request.getBytesRead() method. Here is the Catalina log error: org.apache.coyote.http11.AbstractHttp11Processor process SEVERE: Error processing request java.lang.NoSuchMethodError: org.apache.coyote.Request.getBytesRead()I at com.sflow.catalina.SFlowValve.xdrFlowSample(SFlowValve.java:341) at com.sflow.catalina.SFlowValve.sampleRequest(SFlowValve.java:438) at com.sflow.catalina.SFlowValve.invoke(SFlowValve.java:320) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:620) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Unknown Source) Did anybody have this issue? Check the change log [1]. The signature of the method was changed as part of the fix for bug 57581 Regards, Violeta [1] http://tomcat.apache.org/tomcat-7.0-doc/changelog.html#Tomcat http://tomcat.apache.org/tomcat-7.0-doc/changelog.html#Tomcat 7.0.60 (violetagg) Thanks! Sergey - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org mailto:users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org mailto:users-h...@tomcat.apache.org
Re: Tomcat, REMOTE_USER, getRemoteUser()
Hi,
2015-07-23 21:54 GMT+03:00 John Baker jba...@dryfish.org.uk:
Hello,
I note the HTTP connector does the following when
Request.getRemoteUser() is called:
public String getRemoteUser() {
if (userPrincipal == null) {
return null;
}
return userPrincipal.getName();
}
I understand what it's trying to do but it's not consistent with the AJP
adapter and doesn't make it helpful to interact with upstream reverse
proxies setting the username as a header (ie REMOTE_USER). Would it be
possible to change the implementation to this:
public String getRemoteUser() {
String user = userPrincipal.getName();
if (userPrincipal == null)
user= getHeader(REMOTE_USER);
return user;
}
Or even better, allow the REMOTE_USER header name to be set via a
configuration value? This seems much more consistent with the AJP
adapter that does pick up REMOTE_USER (sent by the ajp module) and
avoids users having to retrieve a header from the request.
You didn't specify any Tomcat version.
Check this feature [1] - tomcatAuthentication/tomcatAuthorization
Regards,
Violeta
[1]
http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html#Standard_Implementations
Thanks
John
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 (7.0.54) Login URL is Passing with JSESSION ID. | why there is different behaviour in Tomcat 6 and Tomcat 7
2015-07-23 11:32 GMT+03:00 Rahul Kumar Singh rahul.si...@nectechnologies.in:
Dear Christopher,
On further debugging, I found out the difference is seen between 6.0.32 (same
behavior as in 6.0.28 reported earlier) and 6.0.33 (same as in 7.0.54
reported earlier ) I could not figure out which change ( as mentioned in link
https://tomcat.apache.org/tomcat-6.0-doc/changelog.html ) has caused this
difference.
Step to reproduce it?
1. Untar tomcat versions(Tomcat V6.0.32 and Tomcat V6.0.33)
2. Enable access log by uncommenting 'AccessLogValve' in conf/server.xml
as shown below
Valve className=org.apache.catalina.valves.AccessLogValve
directory=${catalina.base}/logs
prefix=localhost_access_log. suffix=.txt pattern=common
resolveHosts=false/
3. Deploy a simple web application (login.jsp) in Tomcat.
// login.jsp in tomcat
html
body
%
String str = request.getRequestURI();
System.out.println(str);
out.println(str);
%
/body
/html
4. Start tomcat
5. Run client wget to execute the login.jsp
6. View access log file entry
Thank you for version numbers.
This is expected behaviour. I added comments on the history of this change here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=51833
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat-7.0.61 and SFlow_Valve.jar issue
We updated Tomcat from 7.0.10 to 7.0.61. In previous version we collected Tomcat metrics using Sflow_Valve.jar module. Now it looks like Coyote Connector can't call Request.getBytesRead() method. Here is the Catalina log error: org.apache.coyote.http11.AbstractHttp11Processor process SEVERE: Error processing request java.lang.NoSuchMethodError: org.apache.coyote.Request.getBytesRead()I at com.sflow.catalina.SFlowValve.xdrFlowSample(SFlowValve.java:341) at com.sflow.catalina.SFlowValve.sampleRequest(SFlowValve.java:438) at com.sflow.catalina.SFlowValve.invoke(SFlowValve.java:320) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:620) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Unknown Source) Did anybody have this issue? Thanks! Sergey - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: confirm subscribe to users@tomcat.apache.org
On Thu, Jul 23, 2015, at 07:46 PM, users-h...@tomcat.apache.org wrote: Hi! This is the ezmlm program. I'm managing the users@tomcat.apache.org mailing list. I'm working for my owner, who can be reached at users-ow...@tomcat.apache.org. To confirm that you would like jba...@dryfish.org.uk added to the users mailing list, please send a short reply to this address: users-sc.1437677217.pbmijkobpknfhhclmoia-jbaker=dryfish.org...@tomcat.apache.org Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:users-sc.1437677217.pbmijkobpknfhhclmoia-jbaker=dryfish.org...@tomcat.apache.org This confirmation serves two purposes. First, it verifies that I am able to get mail through to you. Second, it protects you in case someone forges a subscription request in your name. Please note that ALL Apache dev- and user- mailing lists are publicly archived. Do familiarize yourself with Apache's public archive policy at http://www.apache.org/foundation/public-archives.html prior to subscribing and posting messages to users@tomcat.apache.org. If you're not sure whether or not the policy applies to this mailing list, assume it does unless the list name contains the word private in it. Some mail programs are broken and cannot handle long addresses. If you cannot reply to this request, instead send a message to users-requ...@tomcat.apache.org and put the entire address listed above into the Subject: line. --- Administrative commands for the users list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: To subscribe to the list, send a message to: users-subscr...@tomcat.apache.org To remove your address from the list, send a message to: users-unsubscr...@tomcat.apache.org Send mail to the following for info and FAQ for this list: users-i...@tomcat.apache.org users-...@tomcat.apache.org Similar addresses exist for the digest list: users-digest-subscr...@tomcat.apache.org users-digest-unsubscr...@tomcat.apache.org To get messages 123 through 145 (a maximum of 100 per request), mail: users-get.123_...@tomcat.apache.org To get an index with subject and author for messages 123-456 , mail: users-index.123_...@tomcat.apache.org They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send a short message to: users-thread.12...@tomcat.apache.org The messages should contain one line or word of text to avoid being treated as sp@m, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example john@host.domain, just add a hyphen and your address (with '=' instead of '@') after the command word: users-subscribe-john=host.dom...@tomcat.apache.org To stop subscription for this address, mail: users-unsubscribe-john=host.dom...@tomcat.apache.org In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at users-ow...@tomcat.apache.org. Please be patient, my owner is a lot slower than I am ;-) --- Enclosed is a copy of the request I received. Return-Path: jba...@dryfish.org.uk Received: (qmail 77547 invoked by uid 99); 23 Jul 2015 18:46:57 - Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Jul 2015 18:46:57 + Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 15D99D71B7 for users-subscr...@tomcat.apache.org; Thu, 23 Jul 2015 18:46:57 + (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.091 X-Spam-Level: X-Spam-Status: No, score=4.091 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, EMPTY_MESSAGE=2.344, MISSING_SUBJECT=1.767, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 5RuLeIsCralB for users-subscr...@tomcat.apache.org; Thu, 23 Jul 2015 18:46:53 + (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by
Re: Tomcat-7.0.61 and SFlow_Valve.jar issue
Hi, 2015-07-23 21:36 GMT+03:00 Sergey svin...@apple.com: We updated Tomcat from 7.0.10 to 7.0.61. In previous version we collected Tomcat metrics using Sflow_Valve.jar module. Now it looks like Coyote Connector can't call Request.getBytesRead() method. Here is the Catalina log error: org.apache.coyote.http11.AbstractHttp11Processor process SEVERE: Error processing request java.lang.NoSuchMethodError: org.apache.coyote.Request.getBytesRead()I at com.sflow.catalina.SFlowValve.xdrFlowSample(SFlowValve.java:341) at com.sflow.catalina.SFlowValve.sampleRequest(SFlowValve.java:438) at com.sflow.catalina.SFlowValve.invoke(SFlowValve.java:320) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:620) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Unknown Source) Did anybody have this issue? Check the change log [1]. The signature of the method was changed as part of the fix for bug 57581 Regards, Violeta [1] http://tomcat.apache.org/tomcat-7.0-doc/changelog.html#Tomcat 7.0.60 (violetagg) Thanks! Sergey - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat, REMOTE_USER, getRemoteUser()
Hello,
I note the HTTP connector does the following when
Request.getRemoteUser() is called:
public String getRemoteUser() {
if (userPrincipal == null) {
return null;
}
return userPrincipal.getName();
}
I understand what it's trying to do but it's not consistent with the AJP
adapter and doesn't make it helpful to interact with upstream reverse
proxies setting the username as a header (ie REMOTE_USER). Would it be
possible to change the implementation to this:
public String getRemoteUser() {
String user = userPrincipal.getName();
if (userPrincipal == null)
user= getHeader(REMOTE_USER);
return user;
}
Or even better, allow the REMOTE_USER header name to be set via a
configuration value? This seems much more consistent with the AJP
adapter that does pick up REMOTE_USER (sent by the ajp module) and
avoids users having to retrieve a header from the request.
Thanks
John
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: iis isapi redirect problem
Hi,
-Original Message-
From: Andrew Geery [mailto:andrew.ge...@gmail.com]
Sent: Saturday, July 18, 2015 3:16 PM
To: users@tomcat.apache.org
Subject: iis isapi redirect problem
I have successfully gotten Tomcat 8 to work with IIS 8.5 using these
directions: https://tomcat.apache.org/connectors-doc/reference/iis.html
IIS correctly forwards requests to Tomcat to handle and Tomcat correctly
hands the response back to IIS to return to the client. This works over
http and over https.
Now there is a requirement that all traffic should go over ssl, so in IIS I
added the following redirect to C:\inetpub\httproot:
?xml version=1.0 encoding=UTF-8?
configuration
system.webServer
httpRedirect enabled=true destination=https location of the
site exactDestination=false httpResponseStatus=Found /
/system.webServer
/configuration
The effect of this is that when a client requests a page over http, the
server sends a redirect (302) to the same page over https. This works for
other, non-Tomcat related pages on the site. However, it does not work for
pages that use the ISAPI redirector. When a Tomcat page is requested, the
URL that is returned is
https://website/jakarta/isapi_redirect.dll
That is, what seems to be happening is that rather having the ISAPI handler
render the page, the extension_uri value from the registry entry is being
returned to the client.
My questions are:
1) is there a better way to force http - https in IIS? or
2) if not, is there a way to get IIS/ISAPI to work with a redirect (301 or
302)?
I don't have much knowledge about ISAPI but I think this URL is returned
because the Tomcat ISAPI Redirector DLL first acts as a ISAPI Filter to rewrite
the URL to itself, so that in the next step it can act as a ISAPI Extension to
actually forward the request to Tomcat.
I don't know about the httpRedirect element in IIS, but with IIS you can also
use a HttpModule that redirect non-HTTPS requests. Note that when redirecting
HTTP to HTTPS, you normally would use HSTS (HTTP Strict Transport Security) [1]
so that the client knows that every request to this host should go over HTTPS.
Without HSTS a MITM attacker could simply strip out the redirect and SSL/TLS
when the user wants to visit the page, because when the user enters
www.example.com the browser usually would make a request to
http://www.example.com/; instead of https://www.example.com;.
With HSTS, only the first request is vulnerable (as long as you don't add the
website to the HSTS preload list [2]), but for subsequent requests the browser
automatically replaces http://... with https://... for that host, so without
HSTS the users would not really be protected.
To implement a permanent (301) redirect and add a HSTS header, you could use a
HTTP module like the following in IIS 7+:
[[[
using System;
using System.Web;
namespace Webapp.Code.Utils {
/// summary
/// A module that redirects HTTP requests to HTTPS ones, adding a HSTS
header.
/// /summary
public class SslAndHstsModule : IHttpModule {
public void Init(HttpApplication context) {
context.BeginRequest += context_BeginRequest;
}
private void context_BeginRequest(object sender, EventArgs e) {
HttpApplication app = (HttpApplication)sender;
HttpRequest request = app.Request;
HttpResponse response = app.Response;
if (request.IsSecureConnection) {
// Add a HSTS header
response.AppendHeader(Strict-Transport-Security,
max-age=63072000);
} else {
// Permanently redirect a HTTP request to HTTPS
string path = https://; +
request.ServerVariables[SERVER_NAME] +
request.ServerVariables[UNENCODED_URL];
response.RedirectPermanent(path, false);
app.CompleteRequest();
}
}
public void Dispose() {
// Do nothing
}
}
}
]]]
To use it, you can put the code into a text file with the extension .cs and
place it into the App_Code directory in your IIS web application directory.
Then you can enable the module by adding it to the web.config file in the
configuration/system.webServer/modules section:
configuration
system.webServer
modules
!-- Redirect HTTP requests to HTTPS and add a HSTS header --
add name=SslAndHstsModule type=Webapp.Code.Utils.SslAndHstsModule/
/modules
/system.webServer
/configuration
Regards,
Konstantin Preißer
[1] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
[2] https://hstspreload.appspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat initialize SelectorContext twice when lookup for JNDI defined in web application (META-INF/context.xml)
Hi all
On Tue, Jul 21, 2015 at 7:27 PM, Niranjan Karunanandham
niranjan.k...@gmail.com wrote:
Hi Tomcat Team,
On Tue, Jul 21, 2015 at 4:21 PM, Konstantin Kolinko
knst.koli...@gmail.com wrote:
2015-07-21 8:35 GMT+03:00 Niranjan Karunanandham niranjan.k...@gmail.com
:
[sending to users list]
On Thu, Jul 16, 2015 at 10:23 AM, Niranjan Karunanandham
niranjan.k...@gmail.com wrote:
Hi,
On debugging Tomcat (7.0.59), I noticed that the SelectorContext is
initialized twice when a lookup is performed for JNDI defined in web
application (META-INF/context.xml).
When the lookup is performed, the Servlet first calls the init method
of
InitailContext and this returns new SelectorContext(env, true). Then
it
calls the lookup method of InitialContext which again initializes the
SelectorContext but now it returns new SelectorContext(env) [where
the
SelectorContextor.initialContext is set to *false*] and then the lookup
is performed.
1. javax.naming.InitialContext class is not ours. It is part of JDK.
2. SelectorContext object is immutable. The first one has
initialContext == true, the second one has false. Those are two
different objects.
Why are there two different SelectorContext object being created. I
noticed that when we do a JNDI lookup from webapp, it requires the
Context.xml to be only read-only (please correct me if am wrong) for which
the initialContext is false for the SelectorContext. So when is the first
SelectorContext (where the initialContext is set to true) use?
On further debugging, I noticed that when JNDI lookup is performed as
mentioned in my sample, it was creating a new SelectorContext which the
initialContext as false. On trying to connect to a queue (apacheMQ), it
does not create new SelectorContext. Why is this so or am I missing
something?
This is the code (in NamingManager) which does this:
*private static Object getURLObject(String scheme, Object urlInfo,
Name name, Context nameCtx,
Hashtable environment)throws
NamingException {// e.g. ftpURLContextFactoryObjectFactory
factory = (ObjectFactory)ResourceManager.getFactory(
Context.URL_PKG_PREFIXES, environment, nameCtx,. + scheme +
. + scheme + URLContextFactory, defaultPkgPrefix);if (factory
== null) return null;// Found object factorytry {
return factory.getObjectInstance(urlInfo, name, nameCtx, environment);
} catch (NamingException e) {throw e;} catch (Exception
e) {NamingException ne = new NamingException();
ne.setRootCause(e);throw ne;}}*
3. It is usually better to lookup the DataSource once (at startup time
/first access time) and cache the reference locally.
Why is tomcat initializing the SelectorContext twice here?
My Java Webapp Code which does the lookup:
*initCtx = new InitialContext();*
*Context envContext = (Context) initCtx.lookup(java:comp/env);*
*DataSource dataSource = (DataSource)
envContext.lookup(*jdbc/contextDB
*);*
Resource defined in META-INF/context.xml in webapp:
Resource name=jdbc/contextDB auth=Container type
=javax.sql.DataSource
maxActive=100 maxIdle=30 maxWait=1
username=user password=user123
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/WebAppTestDB/
Regards,
Nira
RE: Tomcat 7 (7.0.54) java.lang.ClassFormatError: Truncated class file
Dear Konstantin, Sorry for the inconvenience caused due to the below!! We will take care this in future post. -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Thursday, July 23, 2015 2:09 PM To: Tomcat Users List Subject: Re: Tomcat 7 (7.0.54) java.lang.ClassFormatError: Truncated class file 2015-07-23 8:49 GMT+03:00 Rahul Kumar Singh rahul.si...@nectechnologies.in: Dear Christopher, The solution is fine, but first thing we need to identify the root cause. If it is the problem of loading a JSP-based class file. Why it is happened in production environment? Any solid reason ? Who knows? It is your environment and your file. It is up to you to perform the diagnostics. (Or hire some 3rd party and to provide them access to your system). For starters, we do not know what file is broken. Also you stacktrace does not show the root cause. Where this class loading error was detected? There shall be stacktrace from java.lang.ClassFormatError that was wrapped by ServletException. You only provided 3 lines of stacktrace of ServletException. It may be compiler's fault -- current version is 7.0.63 and it has a newer version of compiler, or you are hitting some size limit -- quotas, disk partition size, 2Gb limit, etc., or you have broken file / faulty HDD -- Maybe not the class file for a JSP page is broken, but some other class file on your system http://tomcat.apache.org/lists.html#tomcat-users Rules: - 6. no top-posting - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NEC or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NEC or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . --- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 (7.0.54) Login URL is Passing with JSESSION ID. | why there is different behaviour in Tomcat 6 and Tomcat 7
Dear Christopher,
On further debugging, I found out the difference is seen between 6.0.32 (same
behavior as in 6.0.28 reported earlier) and 6.0.33 (same as in 7.0.54 reported
earlier ) I could not figure out which change ( as mentioned in link
https://tomcat.apache.org/tomcat-6.0-doc/changelog.html ) has caused this
difference.
Step to reproduce it?
1. Untar tomcat versions(Tomcat V6.0.32 and Tomcat V6.0.33)
2. Enable access log by uncommenting 'AccessLogValve' in conf/server.xml
as shown below
Valve className=org.apache.catalina.valves.AccessLogValve
directory=${catalina.base}/logs
prefix=localhost_access_log. suffix=.txt pattern=common
resolveHosts=false/
3. Deploy a simple web application (login.jsp) in Tomcat.
// login.jsp in tomcat
html
body
%
String str = request.getRequestURI();
System.out.println(str);
out.println(str);
%
/body
/html
4. Start tomcat
5. Run client wget to execute the login.jsp
6. View access log file entry
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, July 21, 2015 8:47 PM
To: Tomcat Users List
Subject: Re: Tomcat 7 (7.0.54) Login URL is Passing with JSESSION ID. | why
there is different behaviour in Tomcat 6 and Tomcat 7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rahul,
On 7/21/15 6:38 AM, Rahul Kumar Singh wrote:
“;jsessionid=C1A67FB90E1300DF14EE027A3634A34B” passed in URL
localhost:8080/login.jsp;jsessionid=C1A67FB90E1300DF14EE027A3634A34B
is not received in tomcat 6(V6.0.28). It is received in tomcat
7(V7.0.54). What is reason for the different behavior?
I'm not sure why the change in behavior, but when a client requests a protected
resource, the container has to redirect that client to the login page.
Before the redirect, a session is created to hold the saved-request to the
originally-requested protected resource. This session id needs to be preserved.
If the container can't tell if the client supports cookie-based session
tracking, it must encode the session id in the login URL just in case. You'll
find that, if you use a browser with cookies enabled, after the login page
there will be no jsessionid path parameters in your URLs.
Is the presence of the jsessionid path parameter a problem for you?
(And at this point, it's really a good idea to start planning your upgrade path
to Tomcat 8, which is quite reliable and stable. Tomcat 6 will EOL 2016-12-31:
http://tomcat.apache.org/tomcat-60-eol.html)
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVrmJmAAoJEBzwKT+lPKRYhZ4P/0CcVBy4y8S4uXbgc/0ClZ3Z
nD5IBoCei2B3Nek1ioK9gTKpvC+ft0XmQ8ZSoqLKKaz8yuBR8S4Ghts6XzTKogSL
LKLm/WBoNlVw9WcD22HyiVx614irOWow1Z/kuWOHywxC1D+D9YGgN+I85xdc0ubo
gV/7831REdUZdBM0m9D58p/LBZn57cBC79/MPFNOY+jgh2vRuvTjQ2wugH1F4GMi
ll3Oj7DivwusVH5NBzR1kdr+8doM8IRTqpPJIXhptTlyZwCvo9BcdgQgapbAG0Ds
mn3DKBSfiAbxXt64syerLyZWsU0kHWu9nMFaglprFSN+enGXZIDOsi1VxhUbms+A
9n3mFJn4oXNnQ4dIy6V2ZKmRNiMYspSqeVh0qNb34qZYqfQHTjV2e7MYU+cwBk44
qy77vB2FAiwrAu73bF/E0U+aw6PrvjX/S2/6hfN6rePh7+nwX2cYrEGMHd57rUQA
OZWaJZ5YQAuguglkKQy7Kz6i7zpUy8IA0oKd7fEYweMBb8TxpxO9sck1UgRRu/Xl
SvUGShSVgOSGqR22mHzIawmCiPacDQBg/c3IdqkegRhMnOuLnkM8s08/oeNRazSC
ZLi8Ano7Yy97Mc064yKFn5pwFWSLCYN3p4brHkNrv49rulp5CUSU3jRZTdVCBueh
MG41DNmnywwNsl4yaJBG
=Ieud
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NEC or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of NEC or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
---
Re: Tomcat 7 (7.0.54) java.lang.ClassFormatError: Truncated class file
2015-07-23 8:49 GMT+03:00 Rahul Kumar Singh rahul.si...@nectechnologies.in: Dear Christopher, The solution is fine, but first thing we need to identify the root cause. If it is the problem of loading a JSP-based class file. Why it is happened in production environment? Any solid reason ? Who knows? It is your environment and your file. It is up to you to perform the diagnostics. (Or hire some 3rd party and to provide them access to your system). For starters, we do not know what file is broken. Also you stacktrace does not show the root cause. Where this class loading error was detected? There shall be stacktrace from java.lang.ClassFormatError that was wrapped by ServletException. You only provided 3 lines of stacktrace of ServletException. It may be compiler's fault -- current version is 7.0.63 and it has a newer version of compiler, or you are hitting some size limit -- quotas, disk partition size, 2Gb limit, etc., or you have broken file / faulty HDD -- Maybe not the class file for a JSP page is broken, but some other class file on your system http://tomcat.apache.org/lists.html#tomcat-users Rules: - 6. no top-posting - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 (7.0.54) Login URL is Passing with JSESSION ID. | why there is different behaviour in Tomcat 6 and Tomcat 7
Dear Konstantin,
On further debugging, I found out the difference is seen between 6.0.32 (same
behavior as in 6.0.28 reported earlier) and 6.0.33 (same as in 7.0.54 reported
earlier ) I could not figure out which change ( as mentioned in link
https://tomcat.apache.org/tomcat-6.0-doc/changelog.html ) has caused this
difference.
Step to reproduce it?
1. Untar tomcat versions(Tomcat V6.0.32 and Tomcat V6.0.33)
2. Enable access log by uncommenting 'AccessLogValve' in conf/server.xml
as shown below
Valve className=org.apache.catalina.valves.AccessLogValve
directory=${catalina.base}/logs
prefix=localhost_access_log. suffix=.txt pattern=common
resolveHosts=false/
3. Deploy a simple web application (login.jsp) in Tomcat.
// login.jsp in tomcat
html
body
%
String str = request.getRequestURI();
System.out.println(str);
out.println(str);
%
/body
/html
4. Start tomcat
5. Run client wget to execute the login.jsp
6. View access log file entry
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Tuesday, July 21, 2015 5:32 PM
To: Tomcat Users List
Subject: Re: Tomcat 7 (7.0.54) Login URL is Passing with JSESSION ID. | why
there is different behaviour in Tomcat 6 and Tomcat 7
2015-07-21 14:38 GMT+03:00 Rahul Kumar Singh rahul.si...@nectechnologies.in:
Hello Tomcat Team,
“;jsessionid=C1A67FB90E1300DF14EE027A3634A34B” passed in URL
localhost:8080/login. jsp;jsessionid=C1A67FB90E1300DF14EE027A3634A34B
is not received in tomcat 6(V6.0.28) . It is received in tomcat 7(V7.0.54) .
What is reason for the different behavior?
I used WGET command to send same request to both version of tomcats. Access
logs (logs/localhost_access_log.txt ) of both tomcat versions show the
difference
WGET REQUEST:
wget localhost:8080/login. jsp;jsessionid=C1A67FB90E1300DF14EE027A3634A34B
.
Observations:
TOMCAT 7.0.54 ACCESS LOGS:
127.0.0.1 - - [21/Jul/2015:08:30:13 +] GET
/login.jsp;jsessionid=C1A67FB90E1300DF14EE027A3634A34B HTTP/1.0 200 1063
-Original Message-
From: Rahul Kumar Singh
Sent: Tuesday, June 23, 2015 6:17 PM
To: 'Tomcat Users List'
Subject: Tomcat 7 (7.0.54) Login URL is Passing with JSESSION ID.
Hello Tomcat team,
In Tomcat7.0.54 We have observe that Login URL is Appended with JSESSIONID
parameter in our Web Application
Example:
/framework/login.action;jsessionid=098D3C84B56FF2A2A25E88E4F059A20B
System Configuration (WINDOW7+IE-8)
Due to this session authentication get failed.
1. Step by step recipe to reproduce your issue = ?
2. 6.0.28 is old. The current one is 6.0.44
3. http://tomcat.apache.org/security-6.html
CVE-2013-2067 ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NEC or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of NEC or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
---
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
