Apache Reverse Proxy to IIS - asp.net

CentOS 7 running Apache 2.4.6 is acting as the central front facing web server to the Internet. As such it has a few reverse proxy connections setup. They all point to other LAMPs and work great. However I have one IIS server running one of them .Net/ASP websites that just doesn't want to load properly. Using the config below on the Apache, the IIS website loads all of the html & css stuff.
<VirtualHost *:80>
SeverName example.com
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /extDirectory/ http://internalserver/internalDirectory/
<Location /extDirectory/ >
ProxyPassReverse http://internalserver/internalDirectory/
Order allow,deny
Allow from all
</Location>
</VirtualHost>
However it looks like there is a sessionID mishap per this screenshot while accessing site externally:
Compared to the accessing same site internally:
Apache log and what I can gather from IIS's log aren't showing any errors. The only error I am getting is when using IE's buil;t in developer tools and am seeing the "200 Authorization not found" , even though I am logged in successfully.

I wasn't able to fix this using Apache as the ASP.Net developer came through with a fix to their software. This is their reply and solution:
Enterprise creates authorization tokens that are used to authenticate each request coming to the server. Every AJAX request must have a valid authentication token, or it will be rejected. Part of the token is the end user's IP address. If the IP address in the AJAX request is different than the original login request, then the token validation will fail and the AJAX request will be rejected. Enterprise v6.5.2 determines the end user's IP address by looking for three specific HTTP headers in this order: HTTP_X_CLUSTER_CLIENT_IP, HTTP_X_FORWARDED_FOR, REMOTE_ADDR. We think that the proxy server may be sending a different IP address for the AJAX request, which would then cause the token validation to fail and the AJAX request to be rejected.
Open Enterprise's web.config and near the top ADD this line right underneath the element:
<add key="USER_HOST_ADDRESS" value="127.0.0.1" />
Save and close web.config, then restart IIS.
That is it. Turned out to be an ASP.NET issue rather than an Apache.

Related

Which app is in charge of URL redirection in a WordPress site?

I just wonder which app is in charge of URL redirection in a WordPress site.
In my site, there is a real folder at /downloads/files/. Now I find there are some 404 errors in accessing https://www.datanumen.com/downloads/files/sitemap.xml, so I want to redirect the URL to https://www.datanumen.com/sitemap.xml
I try several methods:
Add the following redirect in .htaccess in the root folder:
Redirect 301 /downloads/files/sitemap.xml https://www.datanumen.com/sitemap.xml
But that does not work.
Install Redirection plugin and setup a redirection from
/downloads/files/sitemap.xml
to
/sitemap.xml
But still not work.
So I am curious that in a WordPress site, when I input a URL, will the URL be processed by WordPress system first(in which method 2 will take effect), or processed by Apache first(in which method 1 will take effect)? Why both methods do not work?
Apache/.htaccess catches the request first. It is Apache that sends the request to WordPress/PHP.
However, looking at the HTTP response in the browser...
cf-cache-status: HIT
server: cloudflare
The 404 response you are seeing is coming from your CDN's cache. The request isn't even reaching your application server in order to process the redirect.
/downloads/files/sitemap.xml
HOWEVER, are these legitimate requests for your sitemap XML file? This seems unlikely. So, I'd question whether these requests need to be redirected in the first place?
Note that /sitemap.xml is itself redirected to /wp-sitemap.xml so /sitemap.xml would not seem to be the correct target anyway.
client sends ip packet to a host and specifies that the data in the ip packet is for a particular port number, apache listens on specific port numbers as do most network applications, if the ip packet is for one of the port numbers apache is listening on the operating system will route the ip packet to apache, apache then can see a request for file i.e. html,pdf,jpeg,etc. apache then retrieves that file,image,etc from the server storage medium i.e. ssd or hdd, if the file contains php code then apache will parse the php itself before serving the file to the client.
hardware for server computer i.e. cpu,gpu,ram,memory
operating system i.e. linux
server app than run on the operating system i.e. apache
php files i.e. wordpress
So basically Apache acts first i.e. the server configuration files then when Apache parses the wordpress php files, the php script is executed secondly.

IIS 7 adding SSL to one site, all other sites responds to https request

I have multiple sites running on my IIS, now for one of the websites (SiteB) we need to support ssl requests. I have enabled it editing bindings for the website, but the problem is when I selected protocol SSL editing bindings HostName field is disabled, being unable to set hostname to respond to https request, this causes that all sites of my IIS if are requested with https:// loads web site of siteB.
For example my bidings are the next
Site A
IP Port HostName
* 80 www.sitea.com
Site B
IP Port Hostname
* 443 www.siteb.com
* 80 www.siteb.com
If I type https://www.siteb.com in my browser it works correctly, but if I type https://www.sitea.com in the browser, siteb webpage is loaded with the hostname of sitea.
How Can I make that only https://www.siteb.com responds to https requests on my IIS?
I have tried with command appcmd too but It't doesnt work.
appcmd set site /site.name:{sitB} /bindings.[protocol='https',bindingInformation='*:443:*'].bindingInformation:*:443:siteB.com
Thanks for your help.
The Root Problem
This unexpected behavior isn't because of IIS so much as it is because of the web encryption protocols.
The two major web encryption protocols are SSL and TLS. Both of these protocols negotiate a secure connection before passing any request information to the server. This means that, on secure requests, servers don't actually learn the hostname until after the secure connection is made.
An extension to TLS and SSL has been created to address this limitation. It's called SNI (Server Name Identification). The problem is that this extension needs to be supported on both the server and client machines. Currently the client browser support is somewhat spotty. See the SNI article for a browser list.
IIS's Handling Of The Problem
It is because of the above mentioned hostname limitation that IIS doesn't allow you to bind hostnames to HTTPS bindings. There is no way for IIS to route HTTPS requests to a particular hostname since it doesn't know the requested hostname when it first begins to negotiate the connection.
Once IIS has negotiated a secure connection with a client and learns that their requested hostname is for a site other than the one with the HTTPS binding (e.g. a request for https://sitea.com) IIS can either return a failure code or try to fail gracefully. IIS chooses the latter and tries to fail gracefully by serving up the site with the HTTPS binding even though the user is requesting a different site.
Solutions/Workarounds
Create a rewrite rule to redirect all HTTPS requests for nonsecure websites to HTTP.
Upgrade to IIS 8 to use the SNI extension. Then ask visitors to upgrade to browsers that suport SNI.
Have your secure site return an error message when it receives a request for a different domain.
Bind by IP address instead of hostname since IIS can route HTTPS requests by IP address
References
Most of my information came from the Wikipedia article on SNI
We run webservers with multiple sites requiring SSL with no problem.
If I understand your problem correctly - you'll need to set up a binding instead of a host name - which won't work. So, for each SSL-enabled site we host, we require a distinct external IP address. Then, enter that IP address as the binding when setting up the site in IIS.

Test HTTP redirect to HTTPS on the live production server

I have a production server with a live website configured to use SSL. It has also been configured to redirect any HTTP URLs to the HTTPS.
I would like to be able to view the website from the server and test the redirect taking place. Instead I get an error message about permissions.
If I type the the HTTP url from a different machine I am able to view the website, i.e. the HTTP url has automatically been converted into an HTTPS url.
The question is how can I test the HTTP redirect from the production server?
You either make the webserver also listen to localhost (127.0.0.1), or you make the test bind to the external IP of the host.

Weird IIS7 http redirection behavior

I have a web server running Windows Server 2008 with IIS7. I have a bunch of websites which are all bound to the same IP address, but with different host header values. Most of the host headers are something like www.sitename.com.
I also have a corresponding website entry for each which listens for the host "sitename.com" and does a redirect to "www.sitename.com" within IIS7 (to cater for non-www requests). Now this is all pretty straight forward, but I've noticed the when setting up the Http Redirection, some wierd things happen:
Firstly, the "redirect" website entries must be pointed at a different physical directory than the site it's trying to redirect to, otherwise the redirection settings get set for both sites at once.
Secondly, sometimes whilst setting up Http Redirection on an individual site, Http Redirection gets set at a server level, and all sites start redirecting to that one URL.
How does this happen? Under what circumstances could setting Http Redirection on an individual site affect all sites? This is scary!!!
You need to point each of the websites to different physical location so that Http Redirection module can make a webconfig file for each of them.

Flex reverse proxy issues

I'm currently working on setting up a reverse proxy for testing a flex-based web application.
The current setup is using mod_proxy (with mod_proxy_http) to reverse proxy to another host. Everything seems to work except for requests made from the flash player, which result in an error message that says "Security error accessing url".
I have a crossdomain.xml set up on the back end system that simply allows everything, using "<allow-access-from domain="*"/>".
The crossdomain.xml is available off of / from both the backend and proxy server.
The odd part is that when I monitor the connection traffic with firebug, the browser is bypassing the proxy and going straight to the backend server to get the crossdomain.xml file.
Does anyone have any suggestions on how I can get the flex behave properly in an environment like this?
I have included my proxy configuration below.
<IfModule mod_proxy.c>
ProxyRequests Off
<Proxy *>
AddDefaultCharset off
Order deny,allow
Allow from all
</Proxy>
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
ProxyVia On
<Location "/">
ProxyPass http://backend:9080/
ProxyPassReverse http://backend:9080/
</Location>
</IfModule>
The problem was actually the result of the endpoints written in the WSDLs that were generated by the web application. They contained the URL of the backend server. I had to turn on the "ProxyPreserveHost" directive to get it to use the proxy's url for the endpoints. That fixed the problem.
The flash player needs to be given the URL to the reverse proxy server, not the flex server.

Resources