Blog
Removing port 443 from urls generated by Sitecore

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.

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.

1<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
2  <sitecore>
3    <sites xdt:Transform="Insert">
4      <site name="website">
5        <patch:attribute name="hostName">www.MySite.com</patch:attribute>
6        <patch:attribute name="rootPath">/sitecore/content/MySite</patch:attribute>
7        <patch:attribute name="scheme">https</patch:attribute>
8        <patch:attribute name="externalPort">80</patch:attribute>
9      </site>     
10    </sites>
11  </sitecore>
12</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:

1<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
2  <sitecore>
3    <linkManager defaultProvider="sitecore">
4      <patch:attribute
5          name="defaultProvider"
6          value="CustomLinkProvider" />
7      <providers>
8        <add name="CustomLinkProvider"
9             type="MySite.Services.CustomLinkProvider, 
10                         MySite"
11                       languageEmbedding="never"
12                       lowercaseUrls="true"
13                       useDisplayName="true"
14                       alwaysIncludeServerUrl="true"
15          />
16      </providers>
17    </linkManager>
18    <mediaLibrary>
19      <mediaProvider>
20        <patch:attribute name="type">
21          MySite.Services.NoSslPortMediaProvider, MySite
22        </patch:attribute>
23      </mediaProvider>
24    </mediaLibrary>
25  </sitecore>
26</configuration>

2. A helper method that removes the SSL port

1namespace MySite
2{
3    /// <summary> 
4    /// Link Helper is used to remove SSL Port 
5    /// </summary> 
6    public static class LinkHelper
7    {
8        /// <summary> 
9        /// This method removes the 443 port number from url 
10        /// </summary> 
11        /// <param name="url">The url string being evaluated</param> 
12        /// <returns>An updated URL minus 443 port number</returns> 
13        public static string RemoveSslPort(string url)
14        {
15            if (string.IsNullOrWhiteSpace(url))
16            {
17                return url;
18            }
19

20            if (url.Contains(":443"))
21            {
22                url = url.Replace(":443", string.Empty);
23            }
24

25            return url;
26        }
27    }
28}

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

1using Sitecore.Data.Items;
2using Sitecore.Links;
3

4namespace MySite
5{
6    /// <summary>Provide links for resources.</summary> 
7    public class CustomLinkProvider : LinkProvider
8    {
9        public override string GetItemUrl(Item item, UrlOptions options)
10        {
11            // Some code which manipulates and exams the item...
12

13            return LinkHelper.RemoveSslPort(base.GetItemUrl(item, options));
14        }
15    }
16}
17

4. The same provider for media

1using Sitecore.Data.Items;
2using Sitecore.Resources.Media;
3

4namespace MySite
5{
6    /// <summary> 
7    /// This method removes SSL port number from Media Item URLs 
8    /// </summary> 
9    public class NoSslPortMediaProvider : MediaProvider
10    {
11        /// <summary> 
12        /// Overrides Url mechanism for Media Items 
13        /// </summary> 
14        /// <param name="item">Sitecore Media Item</param> 
15        /// <param name="options">Sitecore Media Url Options object</param> 
16        /// <returns>Updated Media Item URL minus 443 port</returns> 
17

18        public override string GetMediaUrl(MediaItem item, MediaUrlOptions options)
19        {
20            var mediaUrl = base.GetMediaUrl(item, options);
21            return LinkHelper.RemoveSslPort(mediaUrl);
22        }
23    }
24}

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.

Sitecore: Returning a 404 response on the page requested rather than redirecting to a 404 page

Sitecore: Returning a 404 response on the page requested rather than redirecting to a 404 page

Previously I've blogged about:

but while looking through the posts today, I realised I had never written about how you stop Sitecore from issuing 302 redirects to your 404 page and instead return a 404 on the URL requested with the contents of the 404 page.

While search engines will recognise a 302 response to a 404 as a 404 (in fact they're intelligent enough to work out that a 404 page without a correct response status code is a 404) it's considered SEO best practice for the URL to stay the same and to issue the correct status code.

Creating a NotFoundResolver class

When Sitecore processes a request it will run the httpRequestBegin pipeline, and within that pipeline is a Item Resolver processor that will attempt to find the requested item. If after this the context item is still null then the logic to redirect to the ItemNotFoundUrl will kick in. To stop this happening we can simply add our own process to the pipeline after ItemResolver and set the item.

Our class looks like this:

1using Sitecore;
2using Sitecore.Configuration;
3using Sitecore.Data;
4using Sitecore.Diagnostics;
5using Sitecore.Pipelines.HttpRequest;
6

7namespace Pipelines.HttpRequest
8{
9    public class NotFoundResolver : HttpRequestProcessor
10    {
11        private static readonly string PageNotFoundID = Settings.GetSetting("PageNotFound");
12

13        public override void Process(HttpRequestArgs args)
14        {
15            Assert.ArgumentNotNull(args, nameof(args));
16

17            if ((Context.Item != null) || (Context.Database == null))
18                return;
19

20            if (args.Url.FilePath.StartsWith("/~/"))
21                return;
22

23            var notFoundPage = Context.Database.GetItem(new ID(PageNotFoundID));
24            if (notFoundPage == null)
25                return;
26

27            args.ProcessorItem = notFoundPage;
28            Context.Item = notFoundPage;
29        }
30    }
31}

To add our process to the pipeline we can use a patch file like this:

1<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
2  <sitecore>
3    <pipelines>
4      <httpRequestBegin>
5        <processor
6          patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']"
7          type="LabSitecore.Core.Pipelines.NotFoundResolver, LabSitecore.Core"  />
8      </httpRequestBegin>
9    </pipelines>
10    <settings>
11      <!-- Page Not Found Item Id -->
12      <setting name="PageNotFound" value="ID OF YOUR 404 PAGE" />
13    </settings>
14  </sitecore>
15</configuration>

Notice the setting for the ID of your 404 page to be loaded as the content.

Remember if you do do this make sure you also follow one of the methods to return a 404 status code, otherwise you will have just made every URL a valid 200 response on your site.

Setting up local https with IIS in 10 minutes

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

1choco install mkcert

3. Create a local certificate authority (ca)

1mkcert -install

4. Create a certificate

1mkcert -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

Installing Sitecore 9 when you've installed 9.1

Installing Sitecore 9 when you've installed 9.1

Installing Sitecore 9 was never the easiest of things, particularly when you compare it to how relatively simple Sitecore 8 was. But if you install Sitecore 9.1 on the same machine and then try your trusty Sitecore 9.0 script you may find it's got even harder and there's a bunch of new issues to worry about.

Multiple version of SIF

The first issue your probably going to run into is an error saying a name parameter is missing. Your script hasn't change, but what has changed is the default version of SIF that's now running.

So the first change you need to make is to ensure your running the correct version of SIF. You can do this either by adding the command to your script or running this before calling you install script. It will take effect for the duration of your PowerShell session.

1#Switch to correct vesion of SIF
2Remove-Module -Name SitecoreInstallFramework
3Import-Module -Name SitecoreInstallFramework -RequiredVersion 1.2.1

If you want to check what the active version of SIF is you can do this in a PowerShell window using

1Get-Command -Module SitecoreInstallFramework | Select-Object -Property name, version

Certificates Error - Part 1

Now we're calling the right version of SIF, the next issue I encountered was to do with certs. Specifically I got this error:

1TerminatingError(New-SignedCertificate): "Cannot process argument transformation on parameter 'Signer'. Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Security.Cryptography.X509Certificates.X509Certificate2"."
2Install-SitecoreConfiguration : Cannot process argument transformation on parameter 'Signer'. Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Security.Cryptography.X509Certificates.X509Certificate2".

This is due to the certificate for Sitecore 9.1 that has been installed. You can remove the certificate but then your Sitecore 9.1 install will break instead.

Alternatively add a "RootCertFilename" to the certificate definition:

1# Install client certificate for xconnect
2$certParams = @{
3  Path = "$SCLocation\xconnect-createcert.json"
4  CertificateName = "$prefix.xconnect_client"
5  RootCertFileName = "SIF121Root"
6}
7Install-SitecoreConfiguration @certParams -Verbose

Certificate Error - Part 2

This error looks exactly the same as the error above but you've already added that Root Cert File Name, so what's happening now.

1Install-SitecoreConfiguration : Cannot process argument transformation on parameter 'Signer'. Cannot convert the
2"System.Object[]" value of type "System.Object[]" to type
3"System.Security.Cryptography.X509Certificates.X509Certificate2".
4At C:\resourceFiles9.0\install.ps1:47 char:1
5+ Install-SitecoreConfiguration @certParams -Verbose
6+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
8    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Install-SitecoreConfiguration

The error is saying that it expected to find 1 certificate but found many instead. Each time you run the script the number of thumbprints also keeps going up.

TBH I'm not overly certain what causes this as most of the time you get the one root cert and your done forever more. But somehow you get a second and then get you in a loop of repeatedly deleting certificates only to discover they still exist somewhere. You know it's also not the certificate for the 9.1 install as the certificate has the new name you added to it.

For me the issue was although I had deleted them from my personal certificates, trusted root certificates, and even the c:\certificates folder they were being added to, what I needed to do was run this in PowerShell.

1Get-ChildItem -Path "cert:\LocalMachine\Root" | Where-Object { $_.subject -like "*SIF121Root*" }
2  | Remove-Item

If your wanting to find out what certificates are installed on your machine you can run these

1Get-ChildItem -Path "cert:\LocalMachine\Root" | Format-Table Subject, FriendlyName, Thumbprint
2Get-ChildItem -Path "cert:\LocalMachine\My" | Format-Table Subject, FriendlyName, Thumbprint
3Get-ChildItem -Path "cert:\CurrentUser\My" | Format-Table Subject, FriendlyName, Thumbprint

Make sure your config is actually correct

This one is really just my mistake. Multiple versions of Siteocore have meant rather than just having one "C:\reousrcefiles\" folder on my machine (as per instructions), I now have a few with the version post-fixed to the end. It only becomes apparent that the path in the install.ps1 file is wrong part way through the install process.