Removing port 443 from urls generated by Sitecore

For as long as I’ve been working on Sitecore there has been this really annoying issue where setting the link manager to include server url and running under https will cause urls to be generated with the port number included. e.g. https://www.himynameistim.com:443/ which naturally you don’t actually want.

Aside: This issue was finally fixed in Sitecore 9.1

To overcome this there are a few methods you can take.

Method 1 – Set the Scheme and Port on you site defenition

This is possibly the smallest change you can make as it’s just 2 settings in a config file.

Setting the external port on site node to 80 (yes 80) tricks the link manager code into not appending the port number as it does it for everything other than port 80.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <sitecore>
    <sites xdt:Transform="Insert">
      <site name="website">
        <patch:attribute name="hostName">www.MySite.com</patch:attribute>
        <patch:attribute name="rootPath">/sitecore/content/MySite</patch:attribute>
        <patch:attribute name="scheme">https</patch:attribute>
        <patch:attribute name="externalPort">80</patch:attribute>
      </site>     
    </sites>
  </sitecore>
</configuration>

What I don’t like about this method though, is your setting something to be wrong to get something else to come out right. It’s all a bit wrong.

Method 2 – Write your own link provider

The second method which I have generally done is to write your own provider which strips the port number off the generated URL.

For this you will need:

1. A patch file to add the provider:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <linkManager defaultProvider="sitecore">
      <patch:attribute
          name="defaultProvider"
          value="CustomLinkProvider" />
      <providers>
        <add name="CustomLinkProvider"
             type="MySite.Services.CustomLinkProvider, 
                         MySite"
                       languageEmbedding="never"
                       lowercaseUrls="true"
                       useDisplayName="true"
                       alwaysIncludeServerUrl="true"
          />
      </providers>
    </linkManager>
    <mediaLibrary>
      <mediaProvider>
        <patch:attribute name="type">
          MySite.Services.NoSslPortMediaProvider, MySite
        </patch:attribute>
      </mediaProvider>
    </mediaLibrary>
  </sitecore>
</configuration>

2. A helper method that removes the ssl port

namespace MySite
{
    /// <summary> 
    /// Link Helper is used to remove SSL Port 
    /// </summary> 
    public static class LinkHelper
    {
        /// <summary> 
        /// This method removes the 443 port number from url 
        /// </summary> 
        /// <param name="url">The url string being evaluated</param> 
        /// <returns>An updated URL minus 443 port number</returns> 
        public static string RemoveSslPort(string url)
        {
            if (string.IsNullOrWhiteSpace(url))
            {
                return url;
            }

            if (url.Contains(":443"))
            {
                url = url.Replace(":443", string.Empty);
            }

            return url;
        }
    }
}

3. The custom link provider which first gets the item url the regular way and then strips the ssl port

using Sitecore.Data.Items;
using Sitecore.Links;

namespace MySite
{
    /// <summary>Provide links for resources.</summary> 
    public class CustomLinkProvider : LinkProvider
    {
        public override string GetItemUrl(Item item, UrlOptions options)
        {
            // Some code which manipulates and exams the item...

            return LinkHelper.RemoveSslPort(base.GetItemUrl(item, options));
        }
    }
}

4. The same provider for media

using Sitecore.Data.Items;
using Sitecore.Resources.Media;

namespace MySite
{
    /// <summary> 
    /// This method removes SSL port number from Media Item URLs 
    /// </summary> 
    public class NoSslPortMediaProvider : MediaProvider
    {
        /// <summary> 
        /// Overrides Url mechanism for Media Items 
        /// </summary> 
        /// <param name="item">Sitecore Media Item</param> 
        /// <param name="options">Sitecore Media Url Options object</param> 
        /// <returns>Updated Media Item URL minus 443 port</returns> 

        public override string GetMediaUrl(MediaItem item, MediaUrlOptions options)
        {
            var mediaUrl = base.GetMediaUrl(item, options);
            return LinkHelper.RemoveSslPort(mediaUrl);
        }
    }
}

What I don’t like about this method is it’s messy in the opposite way. The port number is still being added, and we’re just adding code to try and fix it after.

Credit to Sabo413 for the code in this example

Method 3 – Official Sitecore Patch

Given that it’s Sitecore’s bug, it does actually make sense that they fix it. After all people are paying a license fee for support! This simplifies your solution down to 1 extra patch file and a dll. What’s better is as it’s Sitecores code they have the responsibility of fixing it, if it ever breaks something, and you have less custom code in your repo.

You can get the fix here for Sitecore version 8.1 – 9.0.

So this may leave you wondering how did Sitecore fix it? Well having a look inside the dll reveals they wen’t for method 2.

Setting up local https with IIS in 10 minutes

For very good reasons websites now nearly always run under https rather than http. As dev’s though this gives us a complication of either removing any local redirect to https rules and “hoping” things work ok when we get to a server, or setting local IIS up to have an https binding.

Having https setup locally is obviously a lot more favourable and what has traditionally been done is to create a self signed certificate however while this works as far as IIS is concerned, it still leaves an annoying browser warning as the browser will recognise it as un-secure. This can then create additional problems in client side code when certain things will hit the error when calling an api.

mkcert

The solution is to have a certificate added to your trusted root certificates rather than a self signed one. Fortunately there is a tool called mkcert that makes the process a lot simpler to do.

https://github.com/FiloSottile/mkcert#windows

Create a local cert step by step

1. If you haven’t already. Install chocolatey ( https://chocolatey.org/install ). Chocolatey is a package manager for windows which makes it super simple to install applications. The name is inspired from NuGet. i.e. Chocolatey Nuget

2. Install mkcert, to do this from a admin command window run

choco install mkcert

3. Create a local certificate authority (ca)

mkcert -install

4. Create a certificate

mkcert -pkcs12 example.com

Remember to change example.com to the domain you would like to create a certificate for.

5. Rename the .p12 file that was created to .pfx (this is what IIS requires). The certificate will now be created in the folder you have the command window open at.

You can now import the certificate into IIS as normal. When asked for a password this have been set to changeit

Sitecore 9 installation tips

Sitecore 9 released this week and with it comes a whole new installation process. Gone are the days you could just download the web root and restore some dbs or just run the installation gui and enter a db connection string. Sitecore 9 has some fairly fundamental architectural changes with multiple IIS entries and and some windows services to go with it. Server roles are now also being properly configured rather than updating config files to match what it says in an excel doc.

Along with these changes, the installation process has moved to be based on powershell scripts, which on one hand has made things a bit harder, but it also brings great positives that the process can now be customized with scripts that are repeatable without the risk of mistakes.

Here’s my tips for a smooth local installation (production installs are different to a local install).

Tip #1 – Check the Prerequisites and Requirements

It sounds obvious but when presented with a new toy you want to play with it as fast as possible, and with a 49 page document the urge is there to skip to the installation and hope for the best.

Skipping however is likely to result in install failures as the installer relies on modules such as Web Deploy and the right version of SQL Server which were not needed for the version you may already have installed.

Tip #2 – Make sure you have the right versions

You may have SQL and Solr but are they the right version?

SQL Express 2016

Sitecore 9 supports SQL Server 2014 SP2 and SQL Server 2016. Now that SQL Server 2017 is out, actually finding the link for 2016 express has become a challenge, but here it is.

Download SQL Server 2016 Express

Solr 6.6.1

Sirecore 9 supports Solr version 6.6.1. I typically use Bitnami Solr as it’s a lot easier to install than doing Solr on it’s own. Like SQL though the latest version is newer than what Sitecore supports and finding the link to the older one can be a bit of a challenge.

Download Bitnami Solr 6.6.1

Tip #3 – Solr requires SSL

By default Solr does not install with SSL turned on, but without it your install will fail. More specifically it will fail trying to start an xConnect service.

Enabling SSL for Solr

To create a self-signed certificate for Solr we can use the JDK Keytool which if you’ve installed Solr you should already have installed.

Note: These instructions are based on this guide from Apache and this blog post from Jason St-Cyr.

  1. Open command prompt
  2. Change to the Solr ‘etc’ directory
    cd "{SOLR_HOME}\server\etc"
  3. Execute the keygentool command
    "{JAVA_HOME}\bin\keytool.exe" -genkeypair -alias solr-ssl -keyalg RSA -keysize 2048 -keypass secret -storepass secret -validity 9999 -keystore solr-ssl.keystore.jks -ext SAN=DNS:localhost,IP:127.0.0.1 -dname "CN=localhost, OU=Organizational Unit, O=Organization, L=Location, ST=State, C=Country"

    This will generate the keystore with a password of ‘secret’ as valid for localhost and 127.0.0.1. You can add other DNS and IPs as desired, or skip hostname verification.

  4. Convert generated JKS to PKCS12
     "{JAVA_HOME}\bin\keytool.exe" -importkeystore -srckeystore solr-ssl.keystore.jks -destkeystore solr-ssl.keystore.p12 -srcstoretype jks -deststoretype pkcs12
  5. Enter password when prompted. The password ‘secret’ was used in the previous step. Remember to use your password instead if you changed it in the keygen command parameters.
  6. Open Windows Explorer and navigate to the ‘etc’ directory (“{SOLR_HOME}\server\etc”)
  7. Double-click on the generated ‘p12’ file (solr-ssl.keystore.p12 if you used the default parameters from the previous steps)
  8. In the wizard, specify the following values (there will be some extras you can ignore):
    • Store Location: Local Machine
    • File name: Leave as provided
    • Password: secret
    • Certificate Store: Trusted Root Certification Authorities

    Remember to use your password instead if you changed it during the previous steps.

  9. Open the solr.in.cmd file for editing (e.g. {SOLR_HOME}\bin\solr.in.cmd)
  10. Un-comment the SSL settings:
    set SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.jks
    set SOLR_SSL_KEY_STORE_PASSWORD=secret
    set SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.jks
    set SOLR_SSL_TRUST_STORE_PASSWORD=secret
    set SOLR_SSL_NEED_CLIENT_AUTH=false
    set SOLR_SSL_WANT_CLIENT_AUTH=false

    Remember to update passwords and file paths to match to the parameters you specified.

  11. Restart SOLR to pick up the changes.

Tip #4 – Close management studio

I’m not sure if this was a one off thing, but with management studio open my installation failed with a single user access issue.

Tip #5 – Check the logs

The installation script will output logs to the folder it runs in. If your installation fails it will reference a log file. To find out why the installation failed or get some more info go and check the log referenced.

Redirect to https using URL Rewrite

There’s always been reasons for pages to be served using https rather than http, such as login pages, payment screens etc. Now more than ever it’s become advisable to have entire sites running in https. Server speeds have increased to a level where the extra processing involved in encrypting page content is less of a concern, and Google now also gives a boost to a pages page ranking in Google (not necessarily significant, but every little helps).

If all your pages work in https and http you’ll also need to make sure one does a redirect to the other, otherwise rather than getting the tiny page rank boost from Google, you’ll be suffering from having duplicate pages on your site.

Redirecting to https with URL Rewrite

To set up a rule to redirect all pages from is relatively simple, just add the following to your IIS URL Rewrite rules.

<rule name="Redirect to HTTPS" stopProcessing="true">
  <conditions>
    <add input="{HTTPS}" pattern="^OFF$" />
  </conditions>
  <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" />
</rule>

The conditions will ensure any page not on https will be caught and the redirect will do a 301 to the same page but on https.

301 Moved Permanently or 303 See Other

I’ve seen some posts/examples and discussions surrounding if the redirect type should be a 301 or a 303 when you redirect to https.

Personally I would choose 301 Moved Permanently as you want search engines etc to all update and point to the new url. You’ve decided that your url from now on should be https, it’s not a temporary redirection and you want any link ranking to be transfered to the new url.

Excluding some URL’s

There’s every chance you don’t actually want every url to redirect to https. You may have a specific folder that can be accessed on either for compatibility with some other “thing”. This can be accomplished by adding a match rule that is negated. e.g.

<rule name="Redirect to HTTPS" stopProcessing="true">
  <match url="images" negate="true" />
  <conditions>
    <add input="{HTTPS}" pattern="^OFF$" />
  </conditions>
  <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" />
</rule>

In this example any url with the word images in would be excluded from the rewrite rule.