Cross-domain Gateway Links

As I mentioned at the end of the Archival Process Part 4 post, most everything worked except for hyperlinks between domains while using a gateway (such as hns.to). To give an idea of how important it is to fix this issue, every single link on the Sites page was broken. If everyone natively resolved Handshake names it wouldn’t be an issue, but this level of adoption is not quite here yet.

Creating a Directory for Global Scripts

To generalize the procedure I’m going to put everything in the apache2.conf file as opposed to the individual virtual hosts. A preliminary step is to create a directory on each domain to hold the scripts. Then the following two directives can be added in the config file:

eric@localhost:/var/www/p101$ sudo mkdir global-scripts
Alias /global-scripts /var/www/p101/global-scripts
ProxyPass /global-scripts !

The Alias directive maps /global-scripts for websites to the directory on the server /var/www/p101/global-scripts. The ProxyPass directive prevents /global-scripts from being accidentally proxied. Without this line going to http://www.arcanum.p101/global-scripts would lead to a 404 page instead of where the scripts are going to be located. Visiting the /global-scripts directory on any domain will show the page on the right (which already has the scripts to be written).

Writing the Scripts

We next need to check if the end user can resolve handshake domains because, if so, nothing needs to be changed. On the contrary, if handshake domains cannot be resolved, every link needs to be rewritten with the gateway domain appended. The most straightforward way to do this is to attempt to load a script from a handshake domain. If the target script cannot be loaded, another script can then be called to rewrite the links. This all must be done in JavaScript because it depends totally on the client (who may be using a gateway) and not on the server (which doesn’t know either way).

The first file to be created is just an empty file to serve as something to be pointed to. I’m going to call it check.js but it doesn’t matter what the name is; it should be empty unless there is something specific you want it to do. The touch command creates an empty file with the given name like so. The .js file extension means that it is a JavaScript file. Sudo is required because we are creating files under the special directory /var.

eric@localhost:/var/www/p101/global-scripts$ sudo touch check.js

The second file is the one that does all of the heavy lifting. I’m going to call it hns-gateway-fix.js and put it in the same directory. Because it shouldn’t be empty I’m going to use the text editor vi to both create the file and enter the code.

eric@localhost:/var/www/p101/global-scripts$ sudo vi hns-gateway-fix.js

This script contains a function to be executed if check.js is not found. The convertToGateway function assumes that the last two domains in the current URL are the gateway (the hns.to in www.arcanum.p101.hns.to) and stores it in the variable gateway, with the other portion going into currentDomain and the Handshake top level domain into tld. The variable tags holds an array of every single HTML <a> tag in the current webpage, the one that stores hyperlinks. A for loop then iterates through each <a> tag and replaces the href (the actual link itself) if it contains the Handshake TLD while keeping the appearance of the link the same.

… becomes …

Including the Scripts on Every Page

With the necessary scripts in place, we can now make them usable on every single page of every single website. In order to do this, each page must include our custom code right before the closing </body> HTML tag. It is important for the scripts to go here because the entire page must be loaded in prior to being modified with JavaScript. Conveniently, pages can only have one </body> so a simple Substitute will insert exactly one copy of what we want. Once more in apache2.conf:

Subsitute "s|</body>|<script src=\"/global-scripts/hns-gateway-fix.js\"></script><script src=\"/global-scripts/check.js\" onerror=\"convertToGateway()\"></script></body>|i"

The first script load uses the relative path /global-scripts/hns-gateway-fix.js. This comes first so that we have access to the function convertToGateway() whether the current user is using a gateway or not. The second script load specifically uses an absolute path /global-scripts/check.js so that it only loads if the client can resolve Handshake names. The onerror clause of this script executes convertToGateway() specifically when the script cannot be loaded, i.e. when the client cannot resolve Handshake names.

… at the bottom of each page becomes (albeit crammed in one line) …

So there you have it – people using a Handshake domain with a gateway can now interact with the site the way it was intended and without all of those broken links. It would be much more preferable if everyone would simply resolve these domains themselves using Fingertip, but that cannot always be expected from new and infrequent users of Handshake domains.

I am so glad that I can finally consolidate all of what I learned into this small tutorial. It took several days of near constant work on this problem to be able to come up with a fix. I went down so many dead ends and Stack Overflow rabbit holes that I nearly gave up, but I arrived at a more complete solution because of it. Anyway I hope this post is at least a tiny bit helpful and makes it easier for those who come after me.

Leave a Comment

Your email address will not be published. Required fields are marked *