My main domain is subdomain.domain.tld, and I want to rewrite all the traffic from subdomain1.domain.tld to the first one. Meaning if someone accesses subdomain1.domain.tld/whatever.php, he actually accesses subdomain.domain.tld/whatever.php, however, he's still shown subdomain1 in the browser's navigation bar.
I did some research, but I couldn't find something too promising.
You don't need rewriting for this, in fact internal rewriting is not possible between separate hosts...
Assuming that both "subdomains" (those are actually hostnames) are served by the same http server you can simply configure the same DocumentRoot for both hosts. That way they serve exactly the same file system which obviously means that the same scripts will be called.
Maybe you can get away even more simple if you just use the ServerAlias command for your virtual host. This obviously is only possible if you do not need separate configurations for both hosts.
Just take a look into the documentation of the apache http server. This is explained and good examples are offered:
https://httpd.apache.org/docs/2.4/vhosts/examples.html
In case those two hosts are not served by the same http server you could use an internal proxy setup: subdomain1.domain.tld acts as a front end proxy for subdomain.domain.tld, so it just relays all incoming requests and also the outgoing responses. That is easily done with a combination of the ProxyPass and the ProxyPassReverse rules offered by apaches proxy module: https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypassreverse
This setup can even be used if the two http servers operate on different IP addresses or even completely separate systems.
Related
I have the following question that I do not know how to solve it in the most efficient way.
I have two servers, one with Apache where I have a Wordpress instance responding for port 80, and on another server I have a Wildfly with another application listening on port 8080. The Wordpress that I have configured on the Apache server, responds to the URL http://www.somedomain.com What I'm not so clear about is how to do when a request arrives at http://www.somedomain.com/yyyy and redirects me to the Wildfly server where an application is responding to the URL : 8080 / app
How could I do it in the most effective way? Using the rewrite module in the .htaccess file or using the Apache proxy module and configuring it in the Apache virtual host? How would I have to do it?
Thank you very much in advance.
You're mixing a few things that are not related to each other. First of all, a redirect is something different than a proxy. Redirecting means asking the client (browser) to look at another URL. A proxy, on the other hand, retrieves the content of the other URL itself and passes it to the client. Using a proxy, the other URL remains invisible to the client.
Second, mod_rewrite is not limited to htaccess configuration. In fact it's better to configure mod_rewrite in the virtual host configuration, just as you suggested with the proxy configuration.
The htaccess is simply for users who are not allowed to mess with the server configuration itself. Configuration in the htaccess can be limited by the admin for security purposes at the cost of slowing down the server.
That said, if you are looking to map your wildfly server paths into your main server's paths, you might want to use something like this inside your main server's virtual host block:
<Location "/yyyy">
ProxyPass "http://wildfly:8080/app"
</Location>
See http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass for detailed explanations.
I have already installed an Apache HTTP server in my RedHat system, now I need to install a Bitnami application package which contains another Apache. So I am wondering how to make them not disturbing each other?
I guess I need to configure different ports for the two HTTP server. But what if one has 8080 and another has 9090, will we visit http://[ServerName]:8080/something.html and http://[ServerName]:9090/something.html? I think this way is quite inconvenient. Am I wrong or any better idea?
My advice would be to do something like this.
Have one Apache instance listen in port 80 and the other one in port 8080 for example. The Apache instance that listens in port 80 can act as a proxy to the other Apache (port 8080) using the ProxyPass and ProxyPassReverse directives.
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
You would need to define prefixes or virtual hosts and inside them add ProxyPass directives.
I don't know to what kind of user those applications are targeted to but the usual end-user is not used to enter ports when browsing the web.
If you like to use the ports, go for it, but I would recommend using Name-based Virtual Host
so you could use different domains or subdomains to each application.
In addition to the example provided by the docs (in where they just point to different folders) in this digitalocean page they document how to make redirects to different urls.
I completely agree with EndermanAPM that usual end-user is not used to enter ports when browsing the web. Therefore, I would only allow port 80 to be accessed by the end-users.
Additional to the current solutions I see another one:
avoid messing up the settings of the Apache servers in order to not end-up with some malfunctions of your websites
leave the Apache servers listen on their designated ports (8080 respectively 9090)
install a dedicated proxy in front of the Apache servers. The proxy would listen on port 80 and would define redirect rules that would parse the request and would redirect it to the proper Apache server. (see the attached picture)
I recommend you HA Proxy. It is a very fast and reliable http and tcp proxy. I've been using it in production for years, in front of application servers, web servers and even database servers. Once you get used with its syntax, it is pretty easy to use.
I am aware that introducing a new component into the equation might add another source of potential issues. But I think that the architecture is cleaner. Besides, the two Apache servers will not be disturbing each other as you requested. You can shut down any one of the two and the other one would properly work further.
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.
I have a server with several services running. One of them is accessible through the domain name like "https://www.foo.bar". Two other services are running on specific ports. So they are accessible through "https://www.foo.bar:1234".
Is it able to configure an apache2 server in a specific way, so it uses always the port 443 but with a different URL like "https://www.foo.bar/service1"?
Try ProxyPass, what you describe is a special case of a setup called Reverse Proxy: your httpd forwards requests to the other service and returns the answers to the client. (The other service happens to run on the same machine in your case, but it needn't. A simple kind of backend load-balancing can also be done this way.)
<Location /service1>
ProxyPass https://localhost:1234
ProxyPassReverse https://localhost:1234
</Location>
Be careful that your other service needs some rudimentary support for this kind of setup: if it returns HTML pages with links in it, it can't assume anymore that https://www.foo.bar:1234/foo/bar.html is the correct URL to tell the client. httpd will not look into the returned content and rewrite it for you.
I have a web app at domain1.com which needs to be able to make requests to many different sites, too many to add specific vhost information for each site, what I'd like to be able to do is make a request with the web app to its hosting apache server like this
/domain1.com/some/path
/domain2.com/some/path
and for it to be send to
https://domain1.com/some/path
https://domain2.com/some/path
I've tried different settings using apaches ProxyPass but with no success
How do I do this?
That should be able to work with these directives:
ProxyPass /domain1.com/ https://domain1.com/
ProxyPass /domain2.com/ https://domain2.com/
A request to https://yourproxy.com/domain1.com/some/path should then be forwarded on to https://domain1.com/some/path. It is also possible you may need to use some of the SSLProxy* directives from mod_ssl.
Edit Based on the comment, you might try this:
ProxyPass / http://
I just now tried that, and http://myproxy.com:port1/myserver.com:port2/some/path was sent on to (and returned from) http://myserver.com:port2/some/path.
However, this seems like a bad idea from a security standpoint. I suppose it does allow the proxy to sit on one side of a firewall and allow the backends to be behind the firewall. I am certainly no web expert, but it just feels a bit sketchy.