Avoid rewriting URL's to external applications with reverse proxy on IIS? - iis

Confluence IIS Reverse Proxy Setup
I have set up a reverse proxy on IIS 7.5 for Atlassian Confluence according to instructions found in the internet.
I wanted to redirect all traffic to "docs.unimaze.com" to "localhost:8090" on the same server.
This is how I did it:
Installed URL Rewrite 2.0
Installed Application Request Routing 3.0
Set up a reverse proxy rule:
Match URL: Matches the pattern (.*) using regular expressions (ignore case)
Conditions: (none)
Server variables: (none)
Action: Rewrite with http://localhost:8090/{R:1} (append to query string and stop processing of subsequent rules.
The only other thing I had to in order to make everything work (from https://serverfault.com/questions/76013/iis6-vs-iis7-and-iis7-5-handling-urls-with-plus-sign-in-base-not-querystr) was to run this command on the server so that URL's with "plus signs" in the URL's would be allowed.
%windir%\system32\inetsrv\appcmd set config "WebSiteName"
-section:system.webServer/security/requestFiltering -allowDoubleEscaping:true
Problem with external redirects
Confluence itself, seems to work perfectly BUT when attempting to edit a module from an external application (LucidChart Diagrams it fails), because a redirection to the external application also is rewritten, e.g. an attempt is made to redirect to this URL:
http://docs.unimaze.com/documents/edit/4b157fd9-8e28-4d70-8587-0fdd0839fbca?callback=...
when the redirect should actually be to the external application, so it should remain untouched by the rewriting rule:
https://www.lucidchart.com/documents/edit/4b157fd9-8e28-4d70-8587-0fdd0839fbca?callback=...
Is there an easy way to solve this?

This here helped: appcmd.exe set config -section:system.webServer/proxy /reverseRewriteHostInResponseHeaders:"False" -commit:apphost
In UI, the setting corresponding to this action on the Application Request Routing in IIS on the server node (select „Server Proxy Settings“) should be unchecked.
However, this had the effect that the page can not be loaded in Internet Explorer 11 L
The page is shown, but with empty space where the diagram is and it tries loading something forever.
In Firefox and Chrome it works fine.
I have no idea why it "freezes" in IE 11. Will check from other machines to see if this is always happening or not.

The easiest way to handle this is to take advantage of IIS host headers and make the proxied site believe it is responding as www.example.com:80 rather than localhost:8080. It turns out the AAR reverse proxy has an equivalent of Apache's ProxyPerserveHost setting it just isn't very well documented nor exposed in the UI.
To enable this setting you will need to open an elevated shell and run:
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy -preserveHostHeader:true
Then configure the target site to listen at 127.0.0.1:80 with the appropriate host header and then configure the proxy to proxy back to localhost with the request and it should line up.

Related

How to configure IIS ARR to do a ProxyPass?

Problem:
Need to proxy pass requests that ONLY matches the pattern: mywebsite.com/two-letter-country-code e.g mywebsite.com/es/ to mywebsite.vendor.com/es this second url is a Third-party vendor that will return content translated.
Work In progress:
IIS doesn't natively support ProxyPass so I installed "Application Request Routing (ARR)" to configure a forward proxy following the instructions in this article https://www.iis.net/learn/extensions/configuring-application-request-routing-arr/creating-a-forward-proxy-using-application-request-routing, in the step 14 while configuring the rewrite rule it says to add:
Rewrite URL: http://{C:1}/{R:0}
If my understand is correct in my case I will want to do something like
Rewrite URL: http://mywebsite.sl.vendor.com/{C:#}
Where {C:#} will return "es" or whatever the language the URL is going to.
My questions
1. Is my rewrite understanding correct?
2. Do I have to configure the Server Farms?
I noticed that by installing ARR, "Server Farm" is now available for configuration, but not sure if there is anything I need to do there.
1. Is my rewrite understanding correct?
No, since I wanted to match the two letter country codes the Patter should be:
^([a-z]{2}/(.*)|/[a-z]{2}$)
And the Rewrite URL under Action Properties should be:
https://mywebsite.sl.vendor.com/{R:0}
{R:0} will be the back-reference of specified pattern so an incoming request for mywebsite.com/es/ will be proxy passed as mywebsite.vendor.com/es were {R:0}=es/ as expected
2. Do I have to configure the Server Farms?
Is not require to do any special configuration in the server Farms to get the forward proxy working.
The third party service I was forwarding the request to, require to have the host header to be the server forwarding the request in this case mywebsite.com but in their end they were receiving mywebsite.vendor.com, to accomplish this you have to set the property preserveHostHeader to true, this can be found in the Configuration Editor

IIS Rewrite rule to rewrite to different web site

I have 2 web sites installed on the same IIS server. I need them both to listen on port 443 with HTTPS. I want them to use different application pools and be able to stop and start one without affecting the other. The clients of these websites are not able to configure the host header that they use in their HTTP requests.
Is there a solution? I have been trying to use IIS Rewrite rules. I have one website deployed on port 443 and the other on some unusual port. I tried setting up a URL rewrite on the first one that did a rewrite (not a redirect) to an absolute URL referencing the 2nd site on the unusual port. This always seems to produce an HTTP 404 response.
I can't do a redirect because the client gets redirected to the unusual port and the client is not allowed to make internet requests to non-standard ports.
I believe I am using IIS 6.2, that's what is says in the Help about in IIS MAnager
What options do I have?
It is not possible to rewrite to different applications in IIS, especially if they are in different application pools. Your only option is redirect if you want to do it simply using URL Rewrite.
Another alternative is to use ARR (Application Request Routing) and then proxy the call to the actual site depending on rules, this has also the advantage that sites could be in different machines or in the same one, and give you more flexibility. Obviously it does come with more complexity.

In Node.js, finding the original client URL when app is behind a reverse proxy

I'm working on a Node.js/Express application that, when deployed, sits behind a reverse proxy.
For example: http://myserver:3000/ is where the application actually sits, but users access it at https://proxy.mycompany.com/myapp.
I can get the original user agent request's host from a header passed through easily enough (if the reverse proxy is configured properly), but how do I get that extra bit of path and protocol information from the original URL accessed by the browser?
When my application has to generate redirects, it needs to know that the end user's browser expects the request to go to not only to proxy.mycompany.com over https, but also under a sub-path of myapp.
So far all I can get access to is proxy.mycompany.com, which isn't enough to create a valid redirect.
For dev purposes I'm using a reverse proxy setup in nginx, but my company is using Microsoft's ISA as well as HAProxy.
Generally this is done with x-forwarded-* headers which are inserted by the reverse proxy itself. For example:
x-forwarded-host: foo.com
x-forwarded-proto: https
Take a look here:
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/x-forwarded-headers.html
Probably you can configure nginx to insert whatever x- header you want, but the convention (standard?) seems to be the above.
If you're reverse proxying into a sub-path such as /myapp, that definitely complicates matters. Presumably that sub-path should be a configuration option available to both nginx and your app.

How to configure IIS Url Rewrite

I'm trying to achieve wildcard hostname mappings in IIS 8.5. As they don't exist, I'm trying to use URL Rewrite.
I have two formats of URL,
<anything>-foo.mydomain.com
<anything>-bar.mydomain.com
I want to map these to two different sites in IIS, for example
<anything>-foo.mydomain.com --> foo.mydomain.com/<anything>
<anything>-bar.mydomain.com --> bar.mydomain.com/<anything>
I'm trying to configure a URL Rewrite rule at the machine level, but I've got some problem.
If I set it to Redirect it works. If I set it to Rewrite I get an IIS 404.4.
Can anyone shed any light on this?
Here are my settings:
http://cl.ly/a6tK
You can only rewrite the URL to the same site and same application pool. For example:
http://foo.com/bar to http://foo.com/
You need to install Application Request Routing and enable Proxy. Then it will work with URL rewriting to remote servers (regardless where or what they are) since the routing will take care of that.
http://www.iis.net/downloads/microsoft/application-request-routing

How to run a website in Azure using same URL?

Our company has two sites
www.mysite.com -- Wordpress site
www.mysite.com/portal -- asp.net mvc site
We want to move the wordpress site (www.mysite.com) to Azure and the other site stays local. We need to url stay the same. How can we achieve this?
Since you state that you need the URL to stay the same, this can be achieved through a reverse proxy. You would set up a web server (typically nginx or IIS) answering on www.mysite.com.
This web server would have reverse proxy rules to forward requests for /portal to your on-premises server (in a given, non-public IP and port) and all other requests to another web server running WordPress (on the same server/cluster that runs the reverse proxy, or a separate one), also with a given IP and port.
All user requests, then, would reach the reverse proxy, that would serve them from cache if possible, or forward them to the internal web servers, and send the response back to the user, transparently. Notice that this is an internal operation, not a redirect response.
Although this setup is more complex than the simpler solution of using different subdomains (www.mysite.com for website and portal.mysite.com for application), it comes with certain advantages that are described in the referenced Wikipedia article, such as security and acceleration.
Alternatively you could create separate subdomains as described above, and use a redirect rule to redirect requests for www.mysite.com/portal/x to portal.mysite.com/x. In this case, the user would see the updated URL in their browser, but the old ones would still work.

Resources