I am running a Wicket web application in Apache Tomcat on two separate servers. When the application runs on server #1, all of the images are delivered without errors or warnings on both http: and https:, so I don't think there is a problem with the html file. When I run the same application on server #2, all of the images are delivered over http:, but some of the images are giving 404 Not Found when delivered over https:.
For example:
/path/image1.png and is delivered successfully over http and https.
/path/some/sub/directory/image2.png is delivered over http, but not delivered over https.
More specifically, if I request https://domain/path/some/sub/directory/image2.png, I get a 404 error. But if I specify the port and request https://domain:8443/path/some/sub/directory/image2.png the image is delivered.
As the images both work on the first server, I suspect there is some problem with my Apache configuration on the second server. I can't find any directives specific to the functioning or malfunctioning directories in the apache2.conf, httpd.conf, or .htaccess files.
Where should I look to find the directive that allows image1 to be delivered successfully so that I can copy the rules for image 2?
:::EDIT:::
I found the following directives in extras/httpd-ssl.conf. We are using varnish to cache static content.
# Terminate SSL here and pass everything to Varnish
RequestHeader set X-Forwarded-Proto "https"
ProxyPreserveHost on
ProxyPass / http://128.138.128.89:80/
ProxyPassReverse / http://128.138.128.89:80/
This is running on Linux Mint on Oracle VirtualBox if that matters.
Related
I am trying to solve an issue with an internal ProxyPass setup on an apache http server, version 2.4. Everything works fine otherwise, it is just this ProxyPass issue that I fail to solve:
I operate several name based virtual hosts on a single system with example.org serving as the default host and all hosts using the https protocol on port 443 with valid (signed) certificates:
example.org
host1.example.org
host2.example.org
For one single type of request I want to setup an internal ProxyPass rule to example.org.
https://host1.example.org/_-_-_/bar => https://example.org/foo/bar
A ProxyPassReverse is not required, since no result is returned. (I also tried with, but that does not make any difference):
This is the rule set which is part of the configuration of host host1.example.org:
SSLProxyEngine On
ProxyRequests Off
ProxyVia Off
ProxyPass "/_-_-_/bar" "https://example.org/foo/bar"
The proxy does work, it proxies the request. But the issue is that it does not request the correct host! So not example.org but the originally requested host host1.example.org, so it requests itself. I can clearly see both requests in the same access log file whilst the access log of example.org stays untouched. Obviously that behavior results in a http status 404. That is also shown on the client side as an error message generated by host host1.example.org (fine) but showing the internal path /foo/bar (not fine)!So my question obviously is:
What to change so that the proxy request is internally processed by the desired virtual host?
Ok, as obviously also previously suspected by myself I had an issue with other configuration details interfering here. I post this answers as a hint for others who might stumble about a similar situation:
Another configuration file included by the host configuration set a global ProxyPreserveHost On directive. That obviously resulted in the internal proxy request to feature the same, preserved host header as the original request, which had to lead to the internal request getting processed by the same virtual host as the original request.
I solved the issue by moving (and duplicating) that directive into specific <Location> blocks, so that the global default to not preserve the host in proxy requests is not modified. Consequently the proxy requests described in the question work as expected, they are processed by the desired virtual host now.
I have Proxy Pass somewhat working. I am using it like so
ProxyPass /chorus/ http://localhost:7070/
ProxyPassReverse /chorus/ http://localhost:7070/
This chorus folder does not exist and I am accessing through apache port 80 in the browser. Then it redirects to my application running on port 7070 which provides its webpage. The functionality within the webpage does not work though because the javascript starts requesting images and other info as /images/image1.jpg for example or /jsonrpc on apache and isn't going through the proxy. But on port 80 there is no /images because it's part of the :7070 application. If I do like below it will work too, but there are too many folders, I need a way to set everything returned from 7070 to be processed by apache as http:// localhost:7070/image/...
ProxyPass /jsonrpc http://localhost:7070/jsonrpc
ProxyPass /image http://localhost:7070/image
Basically the page for the app loads but the content does not, the app is requesting /jsonrpc which looks something like this (proxied version)
Remote Address:192.168.1.150:80
Request URL:http://192.168.1.150/jsonrpc?tm=1419196786193
Request Method:POST
Status Code:404 Not Found
When in the app directly without proxy it looks like this
Remote Address:192.168.1.150:7070
Request URL:http://192.168.1.150:7070/jsonrpc?tm=1419196894248
Request Method:POST
Status Code:200 OK
it's not really something you can fix within the Proxy module, other than by spelling out all possible paths, which you want to avoid; your alternatives are:
a. change the application and make it proxy aware so that
a1. it produces paths by prefixing it with a configured path
a2. interprets something like a X-Forwarded-Path header
a3. uses the HTML base tag: http://www.w3schools.com/tags/tag_base.asp
b. change the proxy so that your app lives on it's own vhost e.g. chorus.example.org
I'm a bit out of my depth here and nothing I have found quite addresses my problem. Si any and all suggestions are most welcome.
I've got tomcat6 running on CentOS 6.5 hidden behind an apache server (v2.2.15) and I am using Apache's mod_proxy to expose the tomcat webapps, which are running on port 8080. The tomcat hosts one production application and several development applications. On the apache side, both a Drupal site and the aforementioned tomcat production application are on the same domain and, thanks to rewrite rules, all requests to this domain are changed to https. The development sites are reached via subdomains and do not get re-written as https requests.
For the most part, this arrangement works fine. But parts of the tomcat apps are AJAX (calling a Java Struts 1.2 backend). Most of those requests are handled OK. But a few AJAX requests result in redirects (i.e., forward.setRedirect(true)) and that redirect is http (I guess because the container itself is not secure). As a result, I run into cross site scripting issues. I imagine I can use CORS headers to avoid the problem. But that seems like a hack. Is there a relatively painless way I can use to have tomcat send redirects back as https without making tomcat handle ssl directly?
Cris
You could configure the RemoteIpValve in Tomcat:
Another feature of this valve is to replace the apparent scheme
(http/https) and server port with the scheme presented by a proxy or a
load balancer via a request header (e.g. "X-Forwarded-Proto").
To configure Apache to forward the original protocol in the X-Forwarded-Proto header, add a RequestHeader directive in your Apache config, e.g.:
<VirtualHost *:443>
RequestHeader set X-Forwarded-Proto "https"
...
Note that in Tomcat 7, there is also a RemoteIpFilter.
You don't need to do anything special. It already works. Make sure you set the "redirectPort" in server.xml to Apache's HTTPS port, usually 443, and add the following to your <security-constraint> sections for resources you want secured by HTTPS:
<user-data-constraint>
<description>HTTPS</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
Late to the game here but others may find this-- we had a similar setup and issue where everything worked fine until the application started using ajax posts which did redirects for the response. The fix was to use mod_header in apache to rewrite redirects using "Header edit Location"
http://httpd.apache.org/docs/current/mod/mod_headers.html
Header edit Location ^http://www.example.com/ https://www.example.com/
This went unnoticed prior to the ajax redirects because the browser has no problem doing page level redirects to http (which apache would then redirect back to https). But the ajax cross-site prevention halts at the initial http missing out on that would then be redirected to https by a subsequent request.
We're running Sonatype's Nexus to store all of our builds, cache our dependencies, etc. etc. However, I'd like to move away from the default install's port 8081 URL and instead host it over SSL via an Apache proxy. I've setup Apache's mod_proxy to proxy to it such that https://myserver.com/nexus brings up Nexus. I used the following configuration directives inside of my virtual host config:
# Configure mod_proxy to be used for proxying URLs on this site to other URLs/ports on this server.
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
<Proxy *>
AddDefaultCharset off
Order deny,allow
Allow from all
</Proxy>
# Proxy the Sonatype Nexus OSS web application running at http://localhost:8081/nexus
<Location /nexus>
ProxyPass http://localhost:8081/nexus
ProxyPassReverse http://localhost:8081/nexus
</Location>
This seems to match the instructions at Running Nexus Behind a Proxy. However, I was unable to clear the "Base URL" setting in Nexus: it wouldn't let me leave it blank.
And everything mostly works: I can access Nexus at the HTTPS URL, log in, and perform most GUI functions.
However, when logging in I get the following warning message:
WARNING: Base URL setting of http://myserver.com/nexus does not match your actual URL! If you're running Apache mod_proxy, here's more information on configuring Nexus with it.
And not everything in the GUI actually works. So far I've noticed the following:
System Feeds: Gives the following error:
Problem accessing /nexus/service/local/feeds. Reason:
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request
Nexus returned an error: ERROR 406: The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request
Deleting Hosted Repositories: I went through and deleted several empty & unneeded repositories. However, after confirming the deletions, only the first was removed. I had to login to the 8081 site to delete any of the others.
Per the documentation, it looks like a better solution may be to add a RequestHeader to the Apache configuration:
RequestHeader set X-Forwarded-Proto "https"
I tried the accepted answer, which appears to work, but once I added the RequestHeader, I was able to uncheck Force URL and the warning was cleared. I have not tested the other behavior the OP is describing, though.
You just need to adjust the baseUrl setting in the Administration->Server configuration screen. Set the url you are using and click the Force Base Url option.
My problem is, that I recently set up a Tomcat7 application container with Apache2.2 Frontend. As the project is still under development I am controlling access by an IP whitelist set up in .htaccess for the domain.
I set up mod_jk via AJP13 to Tomcat, it works absolutely fine, except the fact that .htaccess doesn't block the forward for Tomcat. In other words if you enter www.mydomain.com from a "black" IP, you get forwarded to the error page but if you enter www.mydomain.com/AppContext you slip through Apache into Tomcat
I started messing with urlrewritefilter with Tomcat, but for some reason it didn't work.
I am wondering if there is any way to set up .htaccess or apache instead to block requests forwarded to Tomcat similarly to request for Apache?
Also noticed a dramatic speed decrease when using it like that, us that common when using Apache as a frontend?
.htaccess files will work only when Apache is using a <Directory> based configuration (in httpd.conf). In case of mod_jk, matching requests (as specified by JkMount directive) will simply be forwarded to the AJP connector.
Use <Location> to control access instead:
<Location "/AppContext">
Order Deny,Allow
Deny from all
Allow from .myCompany.local
</Location>
See <Location> Directive> for details.
I faced the same problem and found a solution which may solve your case too.
Use a reverse proxy server like Nginx or Squid to redirect the traffic Apache Tomcat. Both of them can use htpassword for authentication and hence, will serve your need. If you want to use Apache as frontend then backend can be nginx which in turn will redirect to Tomcat after proper authentication. It may have a performance hit, though.
https://www.digitalocean.com/community/tutorials/how-to-set-up-http-authentication-with-nginx-on-ubuntu-12-10