Re: Access denied (403) for external requests
Ouch. You're definitely right, I should have post my environment. While looking at it I detected Tomcat 9.0.10 ... quite old. So I did an update to 9.0.24. Finalizing the update I recognized that someone had modified the global context.xml and looking at the diff I found an additional Valve: So, no wonder we got only responses for requests from the intranet ... :-/ Am Mittwoch, 28. August 2019, 12:17:35 CEST schrieb André Warnier (tomcat): > Hi. > (While not saying yet that this is the problem in your case) > It would help a lot if you specified the version of Tomcat, the JVM, and the > platform on which you are running this. > (Such as maybe a bug in a past version of RemoteAddrValve which would > explain this). [snip] Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Access denied (403) for external requests
Hi, we've setup a Tomcat instance to answer on HTTP and port 8080 to requests from the intranet and HTTPS with port 8445 to external requests. When we use HTTPS and port 8445 from the intranet, our firewall will redirect the request, but without changing protocol or port. Tomcat answers to every request from the intranet using either HTTP/8080 or HTTPS/8445, but every external request is denied with 403 and we have no clue why. The server.xml is just modified by adding an additional connector for HTTPS and an a valve to restrict the access to 8445 for external addresses: ... ... We get the following 3 entries in our access log: %< 192.168.10.31:8080 sub.intranet.local:8080 - - [28/Aug/2019:10:54:11 +0200] "GET /app/ping HTTP/1.1" 200 1525 - 192.168.10.1:8445 sub.domain.demo:8445 - - [28/Aug/2019:10:53:57 +0200] "GET / app/ping HTTP/1.1" 200 1537 - 111.222.333.444:8445 sub.domain.demo:8445 - - [28/Aug/2019:10:53:26 +0200] "GET /app/ping HTTP/1.1" 403 983 - %< First two requests were from within the intranet: http://sub.intranet.local:8080/app/ping https://sub.domain.demo:8445/app/ping However, if we make the latter request from external, we're denied although the regex of the RemoteAddrValve matches. We searched now for hours in the Tomcat documentation, FAQ and Google, but we found neither an explanation for the behavior nor how we can enable further diagnostics for this denial. Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving 403 with Tomcat 9, works with Tomcat 8
Hi Mark Am Freitag, 8. Februar 2019, 09:30:32 CET schrieb Jörg Schaible: > Hi Mark, > > Am Mittwoch, 6. Februar 2019, 15:32:26 CET schrieb Mark Thomas: > > [snip] > > > You need to set cors.allowed.origin to an appropriate value. See: > > http://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter > > thanks for your pointers, but unfortunately even setting the value to '*' > has no effect, we still get the 403 for this request. Is there anything > else we can to to debug this? Some logger settings? Just as final remark. After correcting the parameter name, the filter works as expected. Sometimes the problem is in front of the keyboard... ;-) Thanks and cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving 403 with Tomcat 9, works with Tomcat 8
Hi Mark, Am Mittwoch, 6. Februar 2019, 15:32:26 CET schrieb Mark Thomas: [snip] > You need to set cors.allowed.origin to an appropriate value. See: > http://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter thanks for your pointers, but unfortunately even setting the value to '*' has no effect, we still get the 403 for this request. Is there anything else we can to to debug this? Some logger settings? Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving 403 with Tomcat 9, works with Tomcat 8
Hi Mark, Am Mittwoch, 6. Februar 2019, 11:45:46 CET schrieb Mark Thomas: > Exact Tomcat 8 version? > Exact Tomcat 9 version? > > How is CORS configured in your application? the VersionLoggerListener entries from the catalina.log files: this is the machine with Tomcat 8: == %< == - Server version:Apache Tomcat/8.0.41 - Server built: Jan 18 2017 22:19:39 UTC - Server number: 8.0.41.0 - OS Name: Windows Server 2012 R2 - OS Version:6.3 - Architecture: amd64 - Java Home: D:\Programme\Java - JVM Version: 1.8.0_121-b13 - JVM Vendor:Oracle Corporation - CATALINA_BASE: D:\Programme\Tomcat - CATALINA_HOME: D:\Programme\Tomcat - Command line argument: -Dcatalina.home=D:\Programme\Tomcat - Command line argument: -Dcatalina.base=D:\Programme\Tomcat - Command line argument: -Djava.endorsed.dirs=D:\Programme\Tomcat\endorsed - Command line argument: -Djava.io.tmpdir=D:\Programme\Tomcat\temp - Command line argument: - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager - Command line argument: -Djava.util.logging.config.file=D: \Programme\Tomcat\conf\logging.properties - Command line argument: exit - Command line argument: -Xms5120m - Command line argument: -Xmx30720m == %< == this is the machine with Tomcat 9: == %< == - Server Version:Apache Tomcat/9.0.14 - Server built: Dec 6 2018 21:13:53 UTC - Server version number: 9.0.14.0 - OS Name: Windows Server 2012 R2 - OS Version:6.3 - Architektur: amd64 - Java Home: D:\Programme\OpenJDK11 - JVM Version: 11.0.2+9 - JVM Hersteller:Oracle Corporation - CATALINA_BASE: D:\Programme\Tomcat - CATALINA_HOME: D:\Programme\Tomcat - Command line argument: -Dcatalina.home=D:\Programme\Tomcat - Command line argument: -Dcatalina.base=D:\Programme\Tomcat - Command line argument: -Djava.io.tmpdir=D:\Programme\Tomcat\temp - Command line argument: - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager - Command line argument: -Djava.util.logging.config.file=D: \Programme\Tomcat\conf\logging.properties - Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED - Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED - Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED - Command line argument: exit - Command line argument: abort - Command line argument: -Xms5120m - Command line argument: -Xmx30720m == %< == The CORS-Settings from the web.xml: == %< == CorsFilter org.apache.catalina.filters.CorsFilter cors.exposedHeaders Set-Cookie CorsFilter /* == %< == Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Receiving 403 with Tomcat 9, works with Tomcat 8
Hi, we have a strange symptom after an upgrade from Tomcat 8 to Tomcat 9, because we get a 403 for a call that works flawlessly with the previous version. Let's describe the scenario: We have a customer with a Wordpress application hosted on an Apache server. Some pages perform XMLHttpRequests to load and embed HTML snippets from other sources. One such source is our (load-balanced) web application running on Tomcat. These requests are using GET or POST, depending on the situation. However, after the switch from Tomcat 8 to Tomcat 9, the GET request is replied by Tomcat with 403. And the only trace is an entry in the access_log. However, if we use the request URL directly in the browser, the call succeeds. We are using a vanilla installation of Tomcat. The load-balancer will map the HTTPS calls on port 443 to HTTP on port 8080. The only modification to the configuration is in catalina.properties, where we skip the jar scanning: - tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* And we have some additional attributes at the connector in the server.xml: Originally we suspected the "allowHostHeaderMismatch" attribute, because it changed its default from true in Tomcat 8 to false in Tomcat 9, but it had no effect on the communication If we look at the network analysis in the browser, we have following request parameters (example): == %< GET https://tomcat.test-server.local/app/service?param=1 The HTTP request header contains: - Host: tomcat.test-server.local - Origin: https://www.test-server.local - Referrer: https://www.test-server.local/ - DNT: 1 The HTTP response header contains: - Access-Control-Allow-Credentials: true - Access-Control-Allow-Origin: https://www.test-server.local - Cache-Control: no-cache - Content-Type: text/xml;charset=UTF-8 - Server: Apache-Coyote/1.1 - Transfer-Encoding: chunked == %< We found the switched default for "allowHostHeaderMismatch" by chance. Are there other parameters in the Tomcat configuration that are new or have changed their default, which may influence this communication? What's the best way to analyze this on the Tomcat side? Are there any special logger settings to get more info about this 403? Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
