Loading...
Applies to versions: Latest
Other versions:

Going live

Recommended reading 

This topic describes some typical actions such as mapping host names in the DNS and restricting edit access, when going live with sites in Optimizely Digital Experience Platform (DXP).

In this topic

Mapping domain hostnames (required)

Environments in DXP are accessed using a set of dxcloud-URLs that are set up and verified according to platform requirements. Examples:

http://appname123inte.dxcloud.episerver.net
http://appname123prod.dxcloud.episerver.net

Before going live, you need to apply and verify the same DNS settings for the domains that you intend to use with your DXP. This includes creating an awverify record used by Azure, and a CDN-verify record to confirm that you own the domain.

Usually these DNS records are modified:

  • CNAME. Creates an alias for a host name.
  • A-record. Maps a host name to an IP address.

The following instructions show how to modify the DNS settings. You can use Microsoft DNS Manager if you host your own name servers, or the web interface of your DNS service provider. Or, contact your DNS service provider if you are unsure how to change these settings.

Modifying the DNS settings

Note: The following steps must be done for each domain with which your application should be associated.

Before going live

  1. Configure your Optimizely CMS to respond to the incoming hostnames you plan to use, such as www.domain.com. Also configure some default URLs like hostname using "*" (preferred), or alternatively:
    appname123.dxcloud.episerver.net
    appname123-slot.dxcloud.episerver.net
    appname123.azurewebsites.net
    appname123-slot.azurewebsites.net

    The appname123-slot.dxcloud.episerver.net address validates the site during deployments.

    To map hostnames and URLs, go to CMS > Admin > Configuration > Manage Sites.

    managesites.png

  2. After you map the hostnames, inform Optimizely about which URLs you will use.
  3. Optimizely sends you an email containing:
    1. Verification information for CDN and Azure (cloudflare-verify and awverify, these are standard TXT DNS records).
    2. The A-record pointer to be used later when going live.
  4. Do the following to verify your ownership of the domain and/or subdomain for the CDN and in Azure:
    1. CDN. Create a record in your DNS using this format:
      cloudflare-verify.DOMAIN.COM IN TXT XXXXXXXXX-XXXXXXXX

      (XXXXXXXXX-XXXXXXXX being the unique numeric value for the TXT record provided by Optimizely).

    2. Azure. Create a record in your DNS using this format:
      awverify.SUBDOMAIN.DOMAIN.com IN TXT appname123.azurewebsites.net

      Example:

      awverify.www.episerver.net IN TXT dxcwebapp.azurewebsites.net

      Note: Verify the settings for Azure and CDN for each domain and/or subdomain to which you want your DXC environment to respond.

  5. When done with the DNS updates, contact Optimizely again to finalize the verification procedure, and have your verified domains added to the production environment.

When going live

To send traffic from your custom URL to the DXP, you need to create CNAME records in your DNS, pointing to the corresponding DXP endpoint.

  1. Update the A-record at domain.com so that it points to the IP number you received in the Optimizely email (see step 3 in the previous procedure).
  2. Add dxcloud.episerver.net to the URL you want to target with CNAME. When this is done, the site is live. Examples:
    www.DOMAIN.com IN CNAME www.DOMAIN.com.dxcloud.episerver.net
    www.customer.com IN CNAME www.customer.com.dxcloud.episerver.net
    beta.client.net IN CNAME beta.client.net.dxcloud.episerver.net
    prod.company.com IN CNAME prod.company.com.dxcloud.episerver.net
    country.charity.org IN CNAME country.charity.org.dxcloud.episerver.net

    Redirecting to secure URLs

    HTTPS is the secure version of HTTP, adding encryption to the communication between the browser and the editing environment. Redirecting URLs in DXP follows industry-standard best practices, letting you redirect from a non-secure www URL to a secure www URL through configuration.  Optimizely recommends using Microsoft best practices; see Enforce HTTPS in ASP.NET Core.

    Require HTTPS
    Optimizely recommends that production ASP.NET Core web apps use:

    • HTTPS Redirection Middleware (UseHttpsRedirection) to redirect HTTP requests to HTTPS.
    • HSTS Middleware (UseHsts) to send HTTP Strict Transport Security Protocol (HSTS) headers to clients.

    The following example shows how you can configure these services.

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Error");
            // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
            app.UseHsts();
        }
    
        app.UseHttpsRedirection();
        app.UseStaticFiles();
    
        app.UseRouting();
    
        app.UseAuthorization();
    
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
    
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    
        services.AddHsts(options =>
        {
            options.Preload = true;
            options.IncludeSubDomains = true;
            options.MaxAge = TimeSpan.FromDays(60);
            options.ExcludedHosts.Add("example.com");
            options.ExcludedHosts.Add("www.example.com");
        });
    
        services.AddHttpsRedirection(options =>
        {
            options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
            options.HttpsPort = 5001;
        });
    }

    Restricting log in access (optional)

    To ensure that editing environment is only accessed from approved locations, you can restrict the login to only apply to specified IP addresses on the allow list. See Restricting environment access.

    Single Page Application considerations

    You should correctly set up usage tracking parameters to ensure that the website traffic volume monitoring is correct. For websites using the Single Page Application (SPA) concept, specifically configure the page view tracking, because pages on these websites will not reload during usage. See Consumption metrics for information about configuring page view tracking for single page applications.

    Related topics

    Do you find this information helpful? Please log in to provide feedback.

    Last updated: Sep 28, 2021

    Recommended reading