What
This document highlights how to test a production site on the actual domain without switching over the DNS to the XDN.
Why
The main reason to do this is for testing and QA. Some third-party or even some same-site scripts are built to only run on certain domains, the reason for this being two-fold: security and/or data separation. Consider a site that uses subdomains for countries and an analytics set-up that only wants to track a certain country. One way to do that is to make sure the tags only fire on some domains. Or consider a sensitive script that you don’t want an external party to hijack and run the script on a scraped version of the page on another domain (maybe for price scraping). Whatever the reason may be, it is best practice to test all the site’s functionality on the production domain to ensure tags fire correctly and that things that shouldn’t, don’t get blocked.
How
Testing on a computer
It’s pretty straightforward to test on a laptop. On a mac or linux, open your /etc/hosts file with your favorite editor. On a Windows PC it’s located at c:\Windows\System32\Drivers\etc\hosts
It should look something like this:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
# 127.0.0.1:8080 spinning.xdn.moovweb.net
# hidden-river-8652.singaporeair.com.moovapp.com www.singaporeair.com
# Added by Docker Desktop
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section
# ///===================================================== |
# Development Host Entries 0.1.0 |
# (section has been auto-generated) |
# -------------------------------------------------------- |
# |
# These host entries are used for identifying different |
# local websites (levi.com and dockers.com). |
# |
# Possible Hosts ----------------------------------------- |
# |
127.0.0.1 levi.local
127.0.0.1 dockers.local
127.0.0.1 levi-site.com
127.0.0.1 dockers-site.com
127.0.0.1 dev.levi-site.com
127.0.0.1 dev.dockers-site.com
# |
# ======================================================== |
# |
# With these entries in your local hosts file, |
# your browser can now access these URL's: |
# |
# http://levi.local:8000/ |
# http://dockers.local:8000/ |
# http://levi-site.com:8000/ |
# http://dockers-site.com:8000/ |
# http://dev.levi-site.com:8000/ |
# http://dev.dockers-site.com:8000/ |
# |
# =====================================================/// |
# 127.0.0.1:3000 www.parknshop.com
# vineyardvines-vineyard-vines-starter-default.moovweb-edge.io dwdev.vineyardvines.com
# vineyardvines-vineyard-vines-starter-development.moovweb-edge.io dwdev.vineyardvines.com
# 151.101.193.79 clubfurniture.com
# 151.101.193.79 www.clubfurniture.com
# 127.0.0.1 www.clubfurniture.com
# 151.101.209.79 www.vineyardvines.com
This file overrides what a DNS server would return so if you point a domain to another domain or a domain to an IP, you’re telling your device to go to that domain or IP and bypass any DNS server lookup. You’ll need admin access (sudo) to be able to save.
The format is such:
IPAddressOrDomainToBeResolved hostname
so if you consider the last line we’re having www.vineyardvines.com point to the IP 151.101.209.79
In this case, that IP is the IP of the XDN instance for that deployed app.
Tip: You can find your XDN IP address by looking at the DNS configuration in the networking tab for the deployed environment and choosing the top entry.
Alternatively you could also use a similar setup to point to your localhost IP to test your local running instance. That’s what the 127.0.0.1 rows are doing.
Testing on actual devices
Though in most cases desktop browsers with the correct user agent and screen size should be more than enough to test issues in production, if there is a need to test on actual devices, a similar method can be used. In this case, a desktop or laptop will be used as a DNS server.
See here for a guide on how to achieve this using Charles Proxy which has a small license fee. It uses an iOS device as an example but the same steps should result in the same outcome on android device.
One thing to note is that you may need to have the computer connected via ethernet or USB rather than the WiFi which you’ll be sharing your DNS modified network as.