We have used Wix.com to develop a new version of our website. Since we are using deep linking on iOS, we need to place a text file in the website root. Turns out Wix doesn't support this currently although they are considering it.
"No problem," we thought. We can just use an nginx reverse proxy to serve up the apple-app-site-association
file and proxy the rest of the traffic to Wix. We set this up with the following nginx config:
upstream wix {
keepalive 100;
server mgertner.wixsite.com:443;
}
server {
listen 80;
server_name getcorkscrew.com;
location / {
proxy_http_version 1.1;
proxy_pass https://wix/corkscrew-copy;
proxy_pass_request_headers on;
}
}
server {
listen 80;
server_name www.getcorkscrew.com;
location / {
proxy_http_version 1.1;
proxy_pass https://mgertner.wixsite.com/corkscrew-copy;
proxy_pass_request_headers on;
}
}
However, when we go to www.getcorkscrew.com, we just get a blank white page back. Clearly the page is being returned by Wix, and the head
contains a bunch of scripts and other stuff, but the body just contains:
<body>
<div id="SITE_CONTAINER"></div>
<div comp="wysiwyg.viewer.components.WixAds" skin="wysiwyg.viewer.skins.wixadsskins.WixAdsWebSkin" id="wixFooter"></div>
<script type="text/javascript">window.NREUM||(NREUM={});NREUM.info={"errorBeacon":"bam.nr-data.net","licenseKey":"c99d7f1ab0","agent":"","beacon":"bam.nr-data.net","applicationTime":9,"applicationID":"1963269,30200700","transactionName":"ZFAHNkNYXUBQVEUKXF0aNgdDT19WRRhVCkBDVBEBWVxB","queueTime":0}
</script>
</body>
It seems that Wix is somehow detecting the use of a proxy and blocking the normal page content. But when we checked this, we are sending over exactly the same headers as the original request.
Any ideas about how Wix knows we are using a proxy and how we can get around this?
Turns out this is specific to how Wix renders the site. They embed the URL of the site in their
index.html
and the site won't render if it is loaded from another URL. I don't think they are blocking this on purpose. To me it just looks like a side effect of how the rendering code was implemented.We fixed this by using an nginx subfilter to change the URL embedded in
index.html
to the one we are proxying from. Now it works fine.