Follow

Choosing your domain structure


The setup and number of domains you will use can vary depending on the complexity of your setup. A typical installation uses somewhere between 1 and 4 domains per environment and/or site. You should decide which of this configurations is appropriate for your needs. The suggested domain structure assumes you'd prefer to use wildcare DNS. See Setting up DNS for an overview of a possible DNS setup. The diagram below shows the setup with all domains.

Content Entry Domain:

This is the domain used to access your Content Management System, be it Drupal, Wordpress or something else.

  • If it often locked down, for example, by IP address, to ensure only the correct users can access the CMS. 
  • It will ideally bypass any caching layers to ensure any editorial change is reflected instantly.
  • If you are using preview versions of your apps pointing to a preview endpoint, this will usually be to this domain.
  • This domain is not public facing. Only your internal editors will use it

We usually prefix this domain with cms. Say, for example, you were running two different magazines on a Drupal multisite, the domains might look like this:

title1.cms.mycorp.com
title2.cms.mycorp.com

Note: The Pugpig Package and Auth Test forms will cause the server to do a CURL to this domain from itself when using the CMS. This means that the server needs to be able to resolve its own name. If it can't due to network configurations, you'll need to add a local hosts entry to the server(s) to fix this. For example:

# Ensure Pugpig can CURL itself
127.0.0.1 cms.title1.mycorp.com

Origin API Domain:

This is the domain that is used to serve the API content to the outside world. In a simple case, you could choose to use the CMS domain to serve the content instead.

  • You should prevent access to the CMS on this domain - for example block access to /admin/ (Drupal) or /wp-admin/ (WordPress)
  • If you're using a cache accelerator such as Varnish, this domain will usually point to that, and forward requests to the CMS
  • If you're using a "frying" CMS (such as Drupal or WordPress) where published content is served from the same system as the editing, then this will point to the same server as cms.
  • If you're using a "baking" CMS (such as Adobe AEM or SDL Tridion) where content is published to different servers, then this will point to the delivery servers.

Example recommended domains would look like this:
title1.api.mycorp.com
title2.api.mycorp.com

Content Delivery Network Domain:

If you are using a CDN, you should use a dedicated domain for it. There are two CDN models - you can either a) serve all content from the CDN or b) serve just the static assets from the CDN. If you use a), then the apps will use the CDN domain as their content OPDS endpoint. If you use b), then the apps will use the API domain as their endpoint, and refer to large assets on the CDN. domain.

The origin server of your CDN would be the api. domain.

See the section on CDN Considerations for details on CDN configuration.

Example recommended domains would look like this:
title1.cdn.mycorp.com
title2.cdn.mycorp.com

Authentication Server Domain

It is possible to use a completely separate server to handle the Authentication and Entitlement generation parts of your system. The main purpose of this domain is to take third party login credentials or vendor app store receipts, and issue credentials that allow access to the content.

If you're using the Drupal or Wordpress connectors, this domain will often point to the same server as the api. domain, although you could choose to run a completely separate instance of Drupal and Wordpress to host the relevant modules. There is no coupling between the content and authentication parts of the architecture.

Most configurations do not have a dedicated auth domain, and instead use the api. domains for the authentication calls.

All authentication calls should happen over HTTPS if security is important to you.

Example recommended domains would look like this:
title1.auth.mycorp.com
title2.auth.mycorp.com

Web Reader Considerations:

If you're using the Pugpig Web Reader, then you will have a public facing domain. In order to avoid cross domain complexity, the web reader is ideally served from the same domain as the content. This is usually either the API domain or, if you're serving all the content via the CDN, then the CDN domain.

Note that the web reader consists of a set a static files that need to be installed somewhere - either on your CMS server or somewhere completely different. The files can all be served statically via a CDN. If you can configure a CDN to have multiple origins, a common configuration is to have the content feed as one origin and the Web Reader as another.

 

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk