We’re trying to setup a reverse proxy to an internal site through OnDemand. We want users to be able to go to ondemand.example.com/<path>/documentation and it proxies them to documentation.example.com. We have gotten this to work with an additional apache configuration ‘location’ block:
However there are a couple of issues. It seems that we have to define a new location block for each of the static folders that documentation.example.com has, such as documentation.example.com\javascript or documentation.example.com\styles.
This would be fine, but we’re concerned about collisions in the static folders if we proxy future content as well. For example, if we proxied tickets.example.com, and it is looking for a \styles folder, it would collide with the \styles folder for documentation.example.com as they are both being proxied to ondemand.example.com\styles.
We were looking for a solution that would allow us to proxy these sites through a less general URL, such as ondemand.example.com/rnode/documentation, which would include all of the forwarded server files such as ondemand.example.com/rnode/documentation/styles. This would hopefully prevent conflicts as tickets.example.com would be proxied through ondemand.example.com/rnode/tickets and the sub folders would follow suit.
We believe there’s a regex way to do some of this with a <LocationMatch> block, but we wanted to ask so we could set this up in a way that doesn’t interfere with OnDemand’s apache configuration and do this in the most secure way possible, ie behind authentication, ssl, etc.
We also noticed that some sites don’t like to proxy pass, so we were also wondering if there was an easy way to test if the other host was setup correctly to allow reverse proxy passes?
I think it’s better to use Rewrite rules instead of proxy. Neither solution will work with ood-portal-generator so either direction would require either not using ood-portal-generator or patches to ood-portal-generator we do plan to make to allow for more customization of the OnDemand Apache config.
Not sure what benefits exist using a proxy method over simple redirects. The rewrite rule above would go in LocationMatch block. If the goal is to have OnDemand VHost be the entry point, then you must modify OnDemand’s ood-portal.conf.
It could be possible to make this work with existing ood-portal-generator by putting that rewrite rule into ssl array since that array is injected as-is into Apache configs. However that SSL array goes above all the Locations so you’d have to enforce authentication on the sites you redirect to, and if you use SSO, users won’t have to re-authenticate, so things like Keycloak, if both VHosts use the same instance, could see authentication from one as valid for another vhost.
We appreciate the feedback. I’m not a web developer or apache person, so please excuse my amateurish questions
Looking into this some, using the RewriteRule, we can get it to work for the main page, but how do you handle the URLs on the page that we “proxied” to? Since the ondemand side is expecting all urls to begin with ^/documentation, but all the URLs on the “proxied” page do not. Can we use a RewriteBase or something else?
As for the virtual host, from my understanding we would need to have an additional hostname that is resolvable for that to work, which we do not. We need this to work via ondemand.example.com namespace.
Also, adding the working RewriteRule to a LocationMatch section seems to break it, which does not make any sense to me. I now have a new found appreciate for the complexities of apache.
Here is the rule we have that works if we modify the urls to always contain /documentation at the beginning:
Is if it’s part of ondemand.example.com, any URL beginning with /document/something on that host will redirect to example.com/something. That is not going to be proxying involved, it’s a redirect to new website. You don’t need to put this into a LocationMatch section for it to work. I’m not sure I follow how or why proxying would be needed, based on the original desired result, all you should need is a redirect.