Explination

Both the production and development sites are setup to function using subdomain forwarding. This is done to create the illusion of the deposition system existing as part of one integrated stack with the main NP-MRD website (https://np-mrd.org/) when in reality it exists as a different stack.

The subdomain forwarding is setup to forward from a subdomain on np-mrd.org to the “true urls” of our deposition system. The purpose of this is to serve the contents from our stack to this subdomain. This way users will see the subdomain in the url bar in their browser. The subdomain forwarding is setup like such…

prod: https://depositions.np-mrd.org/ -> https://npmrd-deposition-prod.liningtonlab.org/

dev: https://dev-depositions.np-mrd.org/ -> https://dev-npa-articles.liningtonlab.org/

What is worth noting is that, because logging in is achieved via the passing of a url token, it is impossible to login on the true urls of our system because np-mrd.org will always redirect to the forwarded subdomain page.

This means that the forwarded subdomain is the url that we should always share and post publicly. If you try to access our site via the true url and follow a redirect you will be sent to the forwarded subdomain page so it isn’t the end of the world but regardless, it is best to avoid using the true urls whenever possible.

Setup

Because our deployment is done using AWS Copilot there is little that we can do to customize how our domain setup from the copilot configuration alone. As a result, we were forced to setup all functionality relating to subdomain forwarding using the AWS website. This included a handful of different steps to get working correctly….

1. Ensure the Subdomain Directs to Our True Domain

This is not something that we have control over so you must request that this is done by the manager of the np-mrd.org domain (which is not a duty of linington lab). The goal here is to ensure that the subdomain (i.e. https://depositions.np-mrd.org/) “forwards” to the true domain (i.e. https://npmrd-deposition-prod.liningtonlab.org/) They should hopefully be able to handle this issue themselves.

2. Modify The EC2 Load Balancer to Forward Page Content To The NP-MRD Subdomain

Open up the AWS website and go to the EC2 page. From there click on “Load Balancers”. The ones relating to NP-MRD Depositions are…

  • artic-Publi-1280PI7U14PQU (prod)
  • artic-Publi-1JYRNEBE7Z52P (dev)

If you click on the load balancer you will see that there are two ports setup under “Listeners and rules”. These are port 80: for handling HTTP from the internet to our stack and port 443: for handling HTTPS requests to our stack.

The goal here is to ensure that…

  • The HTTP version of the masked subdomain REDIRECTS to the HTTPS version of the masked subdomain
  • The HTTPS version of the masked subdomain FORWARDS to the correct target group to actually server the contents of website.

As a side note: you’ll see that we have a bunch of if conditions that redirect to different target groups. These are all of the different tools live for NP-MRD depositions. This includes correct redirection of requests to our backend (when “/api/back” is part of the path) and frontend websites. In the dev stack this also includes the ner tool and ml tool.

2A. Setting up HTTP to HTTPS Redirecting

Under the “HTTP / port 80” rules you’ll notice I have setup a listener rule called “npmrd_https_forwarding”. The other unnamed/default listeners were automatically generated as part of copilot deployment.

This forwarding must function using the if conditions (defined on the “rule conditions page)…

  • HTTP Host Header is dev-depositions.np-mrd.org, AND
  • Path Pattern is /*

The “Then” actions should then “redirect to the url” of HTTPS site. You can set this up by selecting “URI parts”, Protocol: Port “HTTPS 443” (the port of our HTTPS site) and then setting the status code to “301 - Permanently moved” (“custom host, path, query” can be left unchecked).

This will ensure that if a user now visits “http://depositions.np-mrd.org”, or more importantly “depositions.np-mrd.org” that they are automatically redirected to the https version of the site.

2B. Setting Up Forwarding For The Masking

The next step is to ensure that our site’s content can actually be served to “https://depositions.np-mrd.org” by our load balancer.

2C. Side note: Priority

I have set up both of the previously outlined listener rules with the highest priority of any rule in our system. I don’t think this is particularly important, just make sure this forwarding rule has higher priority than any wildcard rules.

3. Certificates and Route53

Assuming the forwarding is now working properly there is now