Apache ProxyPass to separate VirtualHost on the same system - apache

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.

Related

Shibboleth Errors When Authenticating Through a Reverse Proxy on port 8000

Trying to get shibboleth working on a Docker container, using Apache as a reverse proxy. Problems occur because I am using port 80 for the public Apache instance and port 8000 for the internal instance, which confuses shibboleth:
2017-10-03 07:34:23 ERROR OpenSAML.MessageDecoder.SAML2POST [5]: POST targeted at (https://dashboard.hpc.unimelb.edu.au/Shibboleth.sso/SAML2/POST), but delivered to (https://dashboard.hpc.unimelb.edu.au:8000/Shibboleth.sso/SAML2/POST)
The first URL is the external URL which the end user sees. The second URL is what the docker container sees when it gets the proxied request (with the HTTP host name forwarded).
Note I used "ShibURLScheme https" on the internal apache instance to ensure it believes https is being used, as the reverse proxy ensures all requests are https.
Is there anyway I call tell Shibboleth that this is OK, the URLs really are the same? Maybe by rewriting the URL shibboleth sees or something?
Thanks
There are two things I would check:
Make sure the ServerName directive in your Apache conf file is set to
https://dashboard.hpc.unimelb.edu.au:80. Notice the :80. Omitting
the port number completely may work too. You want Apache and vis-a-vis, shibd to see the ServerName that the client is using. You should also make sure you have a UseCanonicalName On directive as part of this.
This is likely less of a problem, but make sure your sp-metadata given to the IdP is correct. You should add entries for the FQDN(s) that the client sees. Please note that most of that documentation page isn't applicable to your scenario, but adding the correct metadata entries is vital.
It looks like your ServerName in Apache isn't correct, so I'd start there.

Null Value for REQUEST_URI from Apache Web Server

My goal is to obtain the original request URL before proxying to another URL. I'm using Apache Http Server 2.4 in conjunction with Jetty. I'm creating a custom header called X-Forwarded-Uri in my httpd.conf file that provides me with the original request URI.
<VirtualHost *:80>
...
RequestHeader set X-Forwarded-Uri %{REQUEST_URI}e
ProxyPass /foo http://localhost:8080/foo
ProxyPassReverse /foo http://localhost:8080/foo
...
</VirtualHost>
However, when I make a request for http://localhost/foo and try to retrieve the value of X-Forwarded-Uri from my server side code, I consistently get back null. The request URI is supposed to be the path that comes after the host name and port number. Since I'm supplying /foo, I would expect to get back /foo.
Do I have a configuration error?
%{REQUEST_URI}e is not available to the internal var lookup stuff in mod_headers, since it is not always set, and when it is, it is set too late in request processing.
Use the expr="%{REQUEST_URI}" flavor of expressions instead. It knows how to answer that w/o the dependency on the environment variable by the same name.

Reverse proxy with request dispatch (to Rstudio server)

I have a multi-tier application of three layers lets say public, business and workspace (all running apache).
Client requests hits the public servers, requests are processed and dispatched on to business servers that does 'things' and response is returned back to public server which then processes the response and pass it on to the client.
I have a scenario wherein I want a request say /rstudio coming to the public server dispatched onto the business which intern reverse proxy to workspace server. There are two catch here:
the workspace server varies per request
application running on workspace server (Rstudio) uses GWT and references resources (static resources js, css etc and RPC coms) on the root url. All the in-application redirection also happens on the domain.
From the business server, I have setup reverse proxy to Rstudio server from my application server.
<Proxy *>
Allow from localhost
</Proxy>
ProxyPass /rstudio/ http://business_server/
ProxyPassReverse /rstudio/ http://business_server/
RedirectMatch permanent ^/rstudio$ /rstudio/
and this work fine (ref. https://support.rstudio.com/hc/en-us/articles/200552326-Running-with-a-Proxy). To handle dynamic workspace server, I could the following but ProxyPassReverse does not support expression in value and this no joy with this approach.
ProxyPassMatch ^/rstudio/(.*)$ http://$1
ProxyPassReverse ^/rstudio/(.*)$ http://$1
RedirectMatch permanent ^/rstudio$ /rstudio/
I have tried the same with mod_rewrite rule (following) but without ProxyPassReverse and due to domain redirection on the GWT Rstudio, this does not work. Adding ProxyPassReverse would fix the problem but I am caught up with no expression on value part to deal with dynamic workspace server issue.
RewriteRule "^/rstudio/(.*)" "http://$1" [P]
Following is the third approach to solve this problem using LocationMatch and mod_headers:
<LocationMatch ^/rstudio/(.+)>
ProxyPassMatch http://$1
Header edit Location ^http:// "http://%{SERVER_NAME}e/rstudio/"
</LocationMatch>
But this is no joy too because value on header directive is not evaluated against environment variable (and only back-references work here). Althought I can get the reverse proxy thing working if I had code the business_server, which is :
<LocationMatch ^/rstudio/(.+)>
ProxyPassMatch http://$1
Header edit Location ^http:// "http://private_server/rstudio/"
</LocationMatch>
Question 1: I was wondering if there are any better way to solve this problem without hardcoding the server DNS in apache conf?
Question 2: With the hard coded server DNS the reverse proxy works for me (patchy but works) but I am hit with GWT issue of resource references on root and the request dispatch is not fully working. I get to the signin page but resources are not found.
I was wondering if there is any better way to handle that?
Following is the example log from browser:
Navigated to https://public_server/rstudio
rworkspaces:43 GET https://public_server/rstudio.css
rworkspaces:108 GET https://public_server/js/encrypt.min.js
rworkspaces:167 GET https://public_server/images/rstudio.png 404 (Not Found)
rworkspaces:218 GET https://public_server/images/buttonLeft.png 404 (Not Found)
rworkspaces:218 GET https://public_server/images/buttonTile.png 404 (Not Found)
rworkspaces:218 GET https://public_server/images/buttonRight.png 404 (Not Found)

Sonatype Nexus: Proxy from SSL using Apache

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.

Retain original request URL on mod_proxy redirect

I am running a WebApplication on a Servlet Container (port 8080) in an environment that can be accessed from the internet (external) and from company inside (intenal), e.g.
http://external.foo.bar/MyApplication
http://internal.foo.bar/MyApplication
The incomming (external/internal) requests are redirected to the servlet container using an apache http server with mod_proxy. The configuration looks like this:
ProxyPass /MyApplication http://localhost:8080/MyApplication retry=1 acquire=3000 timeout=600 Keepalive=On
ProxyPassReverse /MyApplication http://localhost:8080/MyApplication
I am now facing the problem that some MyApplication responses depend on the original request URL. Concrete: a WSDL document will be provided with a element that has a schemaLocation="<RequestUrl>?xsd=MyApplication.xsd" element.
With my current configuration it always looks like
<xs:import namespace="..." schemaLocation="http://localhost:8080/MyApplication?xsd=MyApplication.xsd"/>
but it should be
External Request: <xs:import namespace="..." schemaLocation="http://external.foo.bar/MyApplication?xsd=MyApplication.xsd"/>
Internal Request: <xs:import namespace="..." schemaLocation="http://internal.foo.bar/MyApplication?xsd=MyApplication.xsd"/>
I suppose this is a common requirement. But as I am no expert in configuration of the apache http server and its modules I would be glad if someone could give some (detailed) help.
Thanks in advance!
If you're running Apache >= 2.0.31 then you might try to set the ProxyPreserveHost directive as described here.
This should pass the original Host header trough mod_proxy into your application, and normally the request URL will be rebuild there (in your Servlet container) using the Host header, so the schema location should be build using the host and path infos from "before" the proxy.
(Posted here too for the sake of completeness)
Here is another alternative if you would like to retain both the original host name and the proxied host name.
If you are using mod_proxy disable ProxyPreserveHost in the Apache configuration. For most proxy servers, including mod_proxy, read the X-Forwarded-Host header in your application. This identifies the original Host header provided by the HTTP request.
You can read about the headers mod_proxy (and possible other standard proxy servers) set here:
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
You should be able to do a mod_rewrite in apache to encode the full URL as a query parameter, or perhaps part of the fragment. How easy this might be depends on whether you might use one or the other as part of your incoming queries.
For example, http://external.foo.bar/MyApplication might get rewritten to http://external.foo.bar/MyApplication#rewritemagic=http://external.foo.bar/MyApplication which then gets passed into the ProxyPass and then stripped out.
A bit of a hack, yes, and perhaps a little tricky to get rewrite and proxy to work in the right order and not interfere with each other, but it seems like it should work.